CVE-2026-6414

What it actually does

@fastify/static 8.0.0 through 9.1.0 decodes percent-encoded path separators such as %2F before resolving files on disk, while Fastify routing logic treats those encoded separators as ordinary literal characters. This parsing mismatch can let a request avoid route-level middleware, authentication, authorization, or guard logic that was intended to protect a static-file path, while still resolving to the protected filesystem resource. The primary impact is unauthorized read access to files exposed through the static-file handler; integrity and availability are not directly affected by the flaw.

Why it matters to the business

Applications using affected @fastify/static versions may unintentionally expose files that operators believed were protected by route-based access controls. If sensitive documents, private assets, configuration-derived content, user-uploaded files, or internal artifacts are served behind those guards, an unauthenticated remote attacker may be able to retrieve them. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV or associated with ransomware, but the consequence can still be serious where static routes protect confidential content. Because the package is part of a common Node.js web framework ecosystem, exposure may exist in both first-party applications and downstream services that embed Fastify-based static serving.

How an attack unfolds

An attacker first identifies a Fastify application that serves files using @fastify/static and relies on route-based middleware or guards to restrict access to specific static paths. They then compare how the application responds to normal protected paths versus paths containing percent-encoded separators. Instead of requesting a protected path with a literal slash, the attacker encodes one or more separators as %2F or %2f. Fastify's router may fail to match the protected route or guard because it treats the encoded separator as a literal character, but @fastify/static later decodes the value and resolves it as a filesystem path separator. If the resolved file exists under the static root, the server may return the file without applying the intended authorization logic. Successful exploitation is usually visible as HTTP requests for static content containing encoded slash sequences, followed by successful 200 responses or unusually large file downloads from paths that should require authentication.

How to fix it

Upgrade @fastify/static to version 9.1.1 or later. The vulnerable range is 8.0.0 through 9.1.0. There are no reliable application-level workarounds stated for this issue because the bug is caused by inconsistent URL path handling between routing and static-file resolution. After upgrading, rebuild and redeploy affected Node.js services, refresh lockfiles such as package-lock.json, yarn.lock, or pnpm-lock.yaml, and verify that all deployed images or serverless artifacts contain the fixed dependency. If immediate upgrade is not possible, reduce exposure by removing sensitive files from static roots, disabling unauthenticated access to affected static routes at an upstream reverse proxy or WAF, and blocking requests containing encoded path separators to protected static-file URL prefixes until the dependency can be updated.

How to confirm the fix worked

Confirm dependency versions by inspecting package manifests, lockfiles, software composition analysis results, container images, and deployed runtime artifacts for @fastify/static versions 8.0.0 through 9.1.0. The fixed version is @fastify/static 9.1.1 or later. Functionally validate the fix by testing a protected static path with both normal separators and encoded separators such as %2F and %2f; both forms should consistently trigger the same authentication or authorization control and must not return protected content to an unauthenticated requester. Review HTTP access logs before and after remediation for encoded slash requests to static-file paths and confirm that upgraded services reject or properly authorize them.

Typical attack path

1. Discover a Fastify application serving static files, often by fingerprinting headers, routes, asset paths, or JavaScript application behavior.
2. Identify static paths that appear protected by authentication, authorization middleware, or route guards.
3. Send baseline requests to protected static paths using normal slash-separated URLs and observe denial, redirect, or authentication-required responses.
4. Craft equivalent URLs where one or more path separators are encoded as %2F or %2f.
5. Submit the encoded requests without valid authentication or authorization.
6. If the router guard is bypassed and @fastify/static resolves the decoded path, retrieve protected files from the static root.
7. Automate enumeration of likely filenames or directories using encoded path separators and collect any accessible sensitive content.

How to detect it

Review web server, reverse-proxy, CDN, WAF, and application access logs for requests to Fastify static-file routes containing percent-encoded path separators, especially %2F or %2f. Focus on unauthenticated requests, requests lacking expected session cookies or authorization headers, and responses with HTTP 200 or 206 where the equivalent normal path should have produced 401, 403, or a login redirect. Compare encoded-separator requests against authentication logs to identify successful file retrieval without a corresponding login event. Look for bursts of encoded-path enumeration, repeated 404-to-200 probing, or downloads of sensitive extensions such as .json, .env, .csv, .pdf, .zip, .bak, .key, .pem, or user-uploaded content. In application logs, correlate suspicious requests with static-file handler activity and response byte counts. For forensics, preserve raw access logs because some logging layers normalize URLs and may hide the encoded separator; prefer logs that record the original request target or raw URI.

• %2F
• %2f
• GET /%2F
• GET /%2f
• POST /%2F
• POST /%2f
• %252F
• %252f
• "GET *%2F* HTTP/1.1" 200
• "GET *%2f* HTTP/1.1" 200
• "GET *%2F* HTTP/2" 200
• "GET *%2f* HTTP/2" 200
• "GET *%2F* HTTP/1.1" 206
• "GET *%2f* HTTP/1.1" 206
• "GET *%2F*.env
• "GET *%2f*.env
• "GET *%2F*.pem
• "GET *%2f*.pem
• "GET *%2F*.key
• "GET *%2f*.key
• "GET *%2F*.bak
• "GET *%2f*.bak
• "GET *%2F*.zip
• "GET *%2f*.zip
• "GET *%2F*.json
• "GET *%2f*.json

What your security team should do

• Inventory all Node.js/Fastify services and identify uses of @fastify/static, including transitive or vendored deployments in containers and serverless packages.
• Prioritize upgrades for internet-facing applications and any service where static routes protect private files, customer content, reports, exports, uploads, or administrative assets.
• Upgrade @fastify/static to 9.1.1 or later and redeploy all affected services; ensure lockfiles and container layers are rebuilt rather than reusing vulnerable cached dependencies.
• Add temporary WAF, reverse-proxy, or application gateway rules to reject encoded slash sequences in protected static-file URL prefixes while upgrades are being rolled out.
• Search historical access logs for requests containing %2F or %2f in static-file paths, especially those that returned HTTP 200, 206, or large response sizes without an authenticated session.
• Confirm that sensitive files are not stored inside publicly served static roots unless access control is enforced independently of Fastify route matching.
• Add regression tests for protected static routes using encoded path separators to prevent future parser-mismatch authorization bypasses.