CVE-2026-90982 in fastify-static
Summary
by MITRE • 09/17/2026
@fastify/static is a Fastify plugin that serves static files from a configured root directory. In versions before 10.1.4, on a case-insensitive filesystem such as Windows or the default macOS volume, a route guard or allowedPath restriction can be bypassed by altering the letter case of a path segment. The route matcher is case-sensitive while the filesystem is not, so a request that changes the case of a protected segment does not match the guarded route and falls through to the static handler, yet the filesystem resolves it to the same protected file. As a result, an unauthenticated request can read a file that a route guard or allowedPath was configured to protect. The issue does not affect case-sensitive filesystems and is not a directory traversal, since nothing is served from outside the configured root. The issue is fixed in @fastify/static 10.1.4, which validates the requested path against its actual on-disk spelling and rejects case-aliased paths before authorization. As a workaround, serve static files from a case-sensitive filesystem, or ensure route guards and allowedPath rules account for every letter-case variant of the protected paths.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability in @fastify/static versions prior to 10.1.4 represents a significant access control bypass rooted in the discrepancy between case-sensitive URL routing logic and case-insensitive file system resolution mechanisms. This issue specifically impacts deployments operating on Windows or default macOS volumes, which utilize case-insensitive file systems by design. In these environments, the underlying operating system treats paths with differing letter cases as identical references to the same physical file. However, the Fastify framework's route matching engine operates in a strictly case-sensitive manner when evaluating defined routes and applying guards such as allowedPath restrictions or authentication middleware. This architectural mismatch creates an attack vector where an adversary can manipulate the casing of path segments within a request URL to evade security controls that were intended to restrict access to specific resources.
When a malicious actor constructs a request with altered letter case for a protected file segment, the Fastify router fails to recognize this request as matching the guarded route definition because it performs exact string comparison against the configured patterns. Consequently, the request does not trigger the associated authentication or authorization checks and instead falls through to the static file serving handler. Despite bypassing these logical security barriers at the application layer, the underlying file system successfully resolves the case-altered path to the intended protected file due to its inherent case-insensitivity. This results in an unauthorized disclosure of sensitive data, allowing unauthenticated users to read files that were explicitly configured to be inaccessible through standard route guards or allowedPath configurations.
This vulnerability is distinct from directory traversal attacks because it does not involve escaping the designated root directory via path manipulation characters such as dot-dot-slash sequences. The attacker remains confined within the boundaries of the static file serving root, but exploits the semantic equivalence of case variants to bypass logical access controls rather than physical file system constraints. From a classification perspective, this flaw aligns with CWE-284 Improper Access Control and CWE-157 Preference for Untrusted Inputs in Path Resolution. It also maps to MITRE ATT&CK techniques related to privilege escalation or unauthorized data access through misconfigured security policies, specifically illustrating how environmental assumptions can undermine application-level security controls.
The resolution implemented in version 10.1.4 addresses this issue by introducing a normalization step that validates the requested path against its actual on-disk spelling before authorization checks are applied. By resolving the canonical file system path and comparing it with protected paths using case-insensitive logic, the framework ensures that any attempt to bypass guards via letter-case manipulation is detected and rejected. This approach effectively closes the gap between application-level routing decisions and physical file system behavior, ensuring consistent security enforcement regardless of the underlying operating system's case sensitivity settings.
For organizations unable to immediately upgrade to the patched version, several mitigation strategies are recommended. The most robust workaround involves deploying static files on a case-sensitive file system, such as ext4 or XFS on Linux, which eliminates the ambiguity in path resolution entirely. Alternatively, developers can modify their route guards and allowedPath configurations to explicitly account for every possible letter-case variant of protected paths, although this approach is labor-intensive and prone to human error if new files are added frequently. Ensuring that security policies are validated against normalized file system representations remains critical for maintaining integrity in cross-platform deployments where case sensitivity varies by operating environment.