Safeguard
Application Security•

CWE-58 Windows 8.3 Filename Path Equivalence Explained

Windows can give a long file name a short 8.3 twin. If your block list knows only the long one, CWE-58 is the gap. Causes and fixes.

Safeguard Security Team
5 min read

Windows has a habit left over from the DOS days. A file called quarterly-report.docx may also answer to a short alias such as QUARTE~1.DOC. CWE-58 is what happens when a protection mechanism restricts the long name and does not restrict the equivalent short 8.3 name.

MITRE puts it plainly: the product has a mechanism that restricts access to a long filename on a Windows operating system, but does not properly restrict access to the equivalent short name. The record lists Windows among the platforms, together with not language specific and not technology specific.

It is one branch of the path equivalence family under CWE-41, which covers one object with several names and a check that knows only some of them.

How it happens

The alias is generated by the file system. The developer does not create it, which is why it gets forgotten. A rule that blocks web.config or secret-plans.docx by name will not match the 8.3 alias, but the file system opens the same file for both.

The record shows the effects:

  • Multiple web servers allowed restriction bypass using 8.3 names instead of long names (CVE-1999-0012).
  • Source code disclosure using an 8.3 file name (CVE-2001-0795).
  • A multi factor vulnerability in which a product generated temporary filenames using long names that became predictable in 8.3 format (CVE-2005-0471).

The third entry shows a different angle. The short form of a long name is not random. It is derived from the original, so if a product relies on long names to be hard to guess, the short alias may reduce the guessing space considerably.

# Vulnerable: block list keyed on the long name
BLOCKED = {"secret-plans.docx", "web.config"}
def can_serve(name):
    return name.lower() not in BLOCKED

# can_serve("SECRET~1.DOC") -> True, and Windows opens the same file

What an attacker gains

MITRE lists reading and modifying files and directories, covering confidentiality and integrity. In the record, that meant bypassing restrictions and reading source code of files that should not have been served. Predictable temporary names can open the door to guessing attacks on files that were meant to be unguessable.

How to find it

The record lists no detection technique. These checks work:

  1. On a Windows host, list short names with dir /x to see which aliases exist for the files you protect.
  2. Request a protected file by its 8.3 alias in a test environment, and compare the result with the long name.
  3. Review code for block lists and name based rules that apply to Windows paths.
  4. Check whether 8.3 name generation is on for the volume holding sensitive content. Generation is a volume setting that an administrator can inspect and change, and the Microsoft documentation for fsutil 8dot3name explains the options.
  5. Look at how temporary file names are produced. If they are built from long names, check how their short forms look.

How to fix it

  1. Do not protect by name alone. Resolve the path to its canonical, long form before applying any rule. On Windows, APIs that return the full long path name do this, and many frameworks expose it through their canonical path function.
  2. Use an allowlist. Serve only files that sit in a directory meant for serving, and keep sensitive files elsewhere. A file that was never in the web root cannot be reached through an alias.
  3. Enforce permissions in the file system itself, so that every name for a file is subject to the same access control list.
  4. Consider disabling 8.3 name creation on volumes where it is not needed, after confirming that no old software depends on it. This is a system change, so test it first.
  5. For temporary files, use the operating system's secure temp file functions that produce unpredictable names.
// Compare canonical (long) paths, not the raw string
Path root = Paths.get("C:\\inetpub\\site").toRealPath();
Path requested = root.resolve(userPath).toRealPath();   // expands 8.3 aliases
if (!requested.startsWith(root) || isBlocked(requested)) {
    throw new SecurityException();
}

toRealPath returns the actual path as the file system reports it, so aliases resolve to the long name before the block list is consulted. Behavior details can vary, so test on your own Windows version.

If a web server or product you run was affected by one of these bugs, the answer is to update it. A free check of your dependency list is available in the browser at gold.safeguard.sh/scan, with no login and up to 100 dependencies.

Quick check

What is an 8.3 filename?

A short alias, up to eight characters plus a three character extension, that Windows can generate for a file with a long name. Both names open the same file.

Why is a block list on long names not enough?

The alias is a different string for the same file, so a rule that matches only the long name never fires when the short name is used.

What did CVE-2005-0471 add to the picture?

Per the record, a product generated temporary filenames from long names, and the short forms became predictable. Name based secrecy is weak when an alias is derived from the name.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.