{"version":"2.1.280","anchor":"read-file-windows-path-spoofing-check-now-reports-specific-s","canonical_anchor":"read-file-windows-path-spoofing-check-now-reports-specific-s","heading":"read_file Windows path-spoofing check now reports specific spelling categories","tier":"notice","area":"Elsewhere","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/read-file-windows-path-spoofing-check-now-reports-specific-s","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### read_file Windows path-spoofing check now reports specific spelling categories\n\nThe Windows path-spoofing check run before reading files now names which trick it caught instead of a generic reason\n\n**What**\n\nBefore `read_file` touches the filesystem, it runs a check for suspicious Windows-style path spellings meant to spoof or bypass path checks. This check used to return one generic rejection reason; it now distinguishes seven specific tricks, each with its own message: NT device namespace, a colon appearing past the drive-letter position, tilde+digit short names, device-path prefixes, trailing dot or whitespace, DOS device-name suffixes, dot-run segments, and UNC\/WebDAV-like forms.\n\nThe same change applies to permission checking for reading files under a trusted network directory: it now reports a `suspicious_windows_spelling` reason carrying the specific variant that triggered it, instead of one generic reason code.\n\n**Why**\n\nKnowing exactly which spelling trick tripped the check makes it much easier to understand why a file path was blocked, whether that's confirming a real security concern or diagnosing a false positive.\n\n- Area: Elsewhere\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}