Submission File: ES2609-707f9982-new-improper-handling-filesystem-name-equivalence-semantics-security-controls.txt
ID: ES2609-707f9982
SUBMISSION DATE: 2026-09-14 05:30:04
NAME: Improper Handling of Filesystem Name-Equivalence Semantics in Security Controls
DESCRIPTION:
The product applies a security control to files or directories using rules
for comparing names that are incompatible with the target filesystem's
lookup rules. This disagreement can cause the control to overlook another
name for a protected resource or to treat a different resource as
authorized.
Some filesystems resolve distinct Unicode spellings to the same directory
entry. These spellings may be canonically equivalent, such as composed and
decomposed representations of the same text, or equivalent under the
filesystem's case-insensitive comparison rules. The filesystem may also
preserve the spelling used to create the entry while accepting equivalent
spellings during lookup. A control that compares names byte for byte may
therefore distinguish names that refer to the same resource.
Applying normalization before validation does not necessarily resolve the
problem. The control may use incomplete case mappings, combine
normalization and case mapping incorrectly, or rely on Unicode character
data whose relevant mappings differ from those used by the filesystem. The
control may also make names compare equal even though the filesystem
resolves them to separate resources. Compatibility normalization, for
example, can introduce equivalences that the filesystem does not recognize.
Both kinds of mismatch can occur in the same implementation.
The consequences depend on the control. Missed equivalence may allow access
to a file or directory covered by a deny rule, include excluded content in
a generated or published artifact, or assign different synchronization keys
to operations on the same resource. Those operations may then run
concurrently despite a requirement to serialize them. Excess equivalence
may cause an allow rule to grant access to an unintended resource. The
resulting access remains subject to the privileges of the process
performing the operation.
This weakness concerns developers and designers who enforce permissions,
exclusions, collision checks, or synchronization in application code and
then rely on the filesystem to resolve the names involved. A control that
works as intended on one filesystem may fail on another with different
lookup rules, even when every operation is checked. A difference in
comparison behavior alone is not sufficient to establish the weakness. It
must cause the control to violate an intended security property.
The mismatch can occur with well-formed Unicode names and does not require
visual deception, malformed encodings, or a change in a name's binding
between check and use. A race condition is not required, although incorrect
synchronization keys can contribute to race-condition vulnerabilities.
Submission File: ES2609-707f9982-new-improper-handling-filesystem-name-equivalence-semantics-security-controls.txt
ID: ES2609-707f9982
SUBMISSION DATE: 2026-09-14 05:30:04
NAME: Improper Handling of Filesystem Name-Equivalence Semantics in Security Controls
DESCRIPTION:
The product applies a security control to files or directories using rules
for comparing names that are incompatible with the target filesystem's
lookup rules. This disagreement can cause the control to overlook another
name for a protected resource or to treat a different resource as
authorized.
Some filesystems resolve distinct Unicode spellings to the same directory
entry. These spellings may be canonically equivalent, such as composed and
decomposed representations of the same text, or equivalent under the
filesystem's case-insensitive comparison rules. The filesystem may also
preserve the spelling used to create the entry while accepting equivalent
spellings during lookup. A control that compares names byte for byte may
therefore distinguish names that refer to the same resource.
Applying normalization before validation does not necessarily resolve the
problem. The control may use incomplete case mappings, combine
normalization and case mapping incorrectly, or rely on Unicode character
data whose relevant mappings differ from those used by the filesystem. The
control may also make names compare equal even though the filesystem
resolves them to separate resources. Compatibility normalization, for
example, can introduce equivalences that the filesystem does not recognize.
Both kinds of mismatch can occur in the same implementation.
The consequences depend on the control. Missed equivalence may allow access
to a file or directory covered by a deny rule, include excluded content in
a generated or published artifact, or assign different synchronization keys
to operations on the same resource. Those operations may then run
concurrently despite a requirement to serialize them. Excess equivalence
may cause an allow rule to grant access to an unintended resource. The
resulting access remains subject to the privileges of the process
performing the operation.
This weakness concerns developers and designers who enforce permissions,
exclusions, collision checks, or synchronization in application code and
then rely on the filesystem to resolve the names involved. A control that
works as intended on one filesystem may fail on another with different
lookup rules, even when every operation is checked. A difference in
comparison behavior alone is not sufficient to establish the weakness. It
must cause the control to violate an intended security property.
The mismatch can occur with well-formed Unicode names and does not require
visual deception, malformed encodings, or a change in a name's binding
between check and use. A race condition is not required, although incorrect
synchronization keys can contribute to race-condition vulnerabilities.