CVE-2026-7120

What it actually does

CVE-2026-7120 is an authorization bypass in @fastify/static versions up to and including 10.1.1. The package evaluates the allowedPath callback before canonicalizing the request pathname by resolving dot segments such as ../ or ./ and collapsing duplicate path separators. If an application relies on allowedPath to deny specific paths under the configured static root, an unauthenticated remote attacker can request an equivalent non-canonical URL that passes the callback check but resolves to a file that should have been denied. The issue does not, by itself, permit traversal outside the configured static root; the impact is unauthorized disclosure of files inside the static root that the application intended to block.

Why it matters to the business

Applications using @fastify/static with path-based allowedPath restrictions may unintentionally expose internal, private, or sensitive static files to anyone who can reach the affected HTTP endpoint. Business consequences can include leakage of documents, configuration-like assets, source maps, unpublished content, or other files stored under the static root but expected to be access-controlled. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV or associated with ransomware, but exploitation is simple over the network and requires no authentication, so internet-facing services using this feature should be upgraded promptly.

How an attack unfolds

An attacker first identifies a Fastify application serving files through @fastify/static and probes for static routes. They then infer or discover files that are likely present inside the static root but blocked by application logic, such as admin-only assets, private documents, hidden directories, source maps, or files denied by an allowedPath callback. Instead of requesting the denied canonical pathname directly, the attacker sends semantically equivalent paths containing dot segments, repeated slashes, encoded separators, or other non-canonical path forms. Because vulnerable versions check allowedPath before normalizing the pathname used for file resolution, the malicious request can satisfy the callback while resolving to the originally denied file. If successful, the server returns the file contents in the HTTP response. The attack remains constrained to the configured static root unless another vulnerability is present.

How to fix it

Upgrade @fastify/static to version 10.1.2 or later. The advisory identifies versions up to and including 10.1.1 as affected and 10.1.2 as patched. Because no per-package fixed_versions array was provided beyond the description, validate the installed package directly through the JavaScript package manager lockfile and dependency tree. Rebuild and redeploy applications after upgrading, including container images and serverless bundles that vendor node_modules. As a defense-in-depth measure, avoid relying solely on URL string comparisons for authorization decisions; normalize and canonicalize paths before applying allow/deny logic, and keep sensitive files out of the static root whenever possible. If immediate upgrade is not possible, add upstream middleware or reverse-proxy rules that reject non-canonical static-file requests containing dot segments or duplicate path separators, and review allowedPath callbacks for assumptions about raw request paths.

How to confirm the fix worked

Confirm that deployed applications use @fastify/static 10.1.2 or later by checking package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, and runtime dependency output such as npm ls @fastify/static. Verify that rebuilt artifacts and containers no longer include @fastify/static versions 10.1.1 or earlier. Functionally test the fix by creating or identifying a file under the configured static root that allowedPath is intended to deny, confirming that the canonical denied URL is blocked, and then attempting equivalent non-canonical forms with ./, ../ within-root normalization, and repeated slashes; all should be denied or normalized before authorization. Also validate that reverse proxies and application routers do not reintroduce inconsistent normalization behavior before requests reach Fastify.

Typical attack path

1. Identify an application endpoint serving static files through Fastify/@fastify/static.
2. Probe for path filtering behavior by requesting known or guessed restricted static paths.
3. Craft equivalent non-canonical URLs using dot segments, duplicate separators, or related pathname normalization tricks.
4. Send unauthenticated HTTP GET or HEAD requests to the static file route.
5. Rely on the vulnerable order of operations where allowedPath is evaluated before pathname normalization.
6. Receive files from inside the configured static root that should have been denied by allowedPath restrictions.
7. Use disclosed content for reconnaissance, data theft, or to support follow-on attacks.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs, reverse proxy logs, CDN/WAF logs, and application logs for unauthenticated requests to static-file routes containing non-canonical path patterns. Focus on requests with dot segments, duplicate separators, encoded dot or slash characters, and requests that returned HTTP 200, 206, or large response bodies for files that should have been denied. Compare requested URLs with normalized path equivalents and identify cases where the normalized path maps to a file covered by allowedPath deny logic. Investigate successful responses for sensitive extensions such as .map, .json, .env-like names, backups, archives, internal documents, or unpublished assets under the static root. If logs include response size or cache status, look for repeated probing followed by successful downloads. No public threat actors or KEV exploitation are currently associated with this CVE in the provided data, so detection should emphasize behavioral path-normalization bypass patterns rather than actor-specific indicators.

• ../
• /./
• //
• %2e%2e
• %2e/
• .%2f
• %2f%2e%2e%2f
• %252e%252e
• GET /static/
• HEAD /static/

What your security team should do

• Inventory all Node.js/Fastify applications that use @fastify/static, especially internet-facing services.
• Prioritize upgrade to @fastify/static 10.1.2 or later for applications that use the allowedPath option or store non-public files under the static root.
• Search dependency manifests, lockfiles, SBOMs, and container images for @fastify/static versions up to and including 10.1.1.
• Review static roots and remove private, internal, unpublished, or sensitive files that should not be web-accessible.
• Add temporary controls to reject suspicious non-canonical static-file paths containing dot segments or repeated slashes where upgrade cannot be completed immediately.
• Review access logs for historical requests using path normalization bypass patterns against static routes.
• Add regression tests that verify denied static files remain denied when requested through equivalent non-canonical pathnames.