GHSA-wr4h-v87w-p3r7

What it actually does

The vulnerability is a path traversal flaw in h3's serveStatic functionality. Requests containing percent-encoded dot-segment sequences can bypass path normalization checks and cause the static file handler to resolve paths outside the intended static content directory. A successful exploit allows an unauthenticated remote requester, where serveStatic is exposed, to read arbitrary files accessible to the application process. The impact is confidentiality-focused; it does not directly provide code execution or file modification, but disclosure of configuration files, source code, credentials, tokens, or environment-specific secrets may enable follow-on compromise.

Why it matters to the business

Applications using vulnerable h3 versions to serve static files may unintentionally expose sensitive server-side files to anyone who can reach the affected endpoint. This can lead to credential theft, leakage of application source or configuration, exposure of cloud/API secrets, and potential downstream compromise of databases, storage, or third-party services. The CVSS score is moderate and there is no known KEV listing or mature public exploitation indicated in the provided data, but internet-facing static file routes should still be prioritized because file disclosure bugs are easy to probe at scale and can create high business impact if secrets are exposed.

How an attack unfolds

An attacker first identifies an application using h3's serveStatic behavior, typically by probing static asset routes exposed over HTTP. They then craft HTTP requests containing percent-encoded representations of dot segments, such as encoded '../' path components, to confuse the static file path resolution logic. Because the vulnerable implementation fails to properly reject or canonicalize these encoded traversal sequences before resolving the file path, the request can escape the configured public/static directory. The attacker then iterates over common sensitive file locations and application paths, attempting to retrieve files such as environment variable files, package metadata, server configuration, source files, private keys, or deployment secrets. Any recovered secrets can be used for follow-on access to application infrastructure, cloud services, databases, or CI/CD systems.

How to fix it

Upgrade h3 to a fixed version: use h3 1.15.6 or later for the 1.x line, or h3 2.0.1-rc.15 or later for the 2.x release candidate line. Rebuild and redeploy all applications that bundle h3 directly or transitively through frameworks or tooling. If immediate upgrade is not possible, disable serveStatic for untrusted/public routes, place a reverse proxy or web application firewall rule in front of affected endpoints to block percent-encoded traversal patterns, and ensure the application process runs with least-privilege file permissions so sensitive files are not readable by the web service user. Avoid placing secrets, private keys, source repositories, or deployment files under paths readable by the application process. Rotate any secrets that may have been exposed if logs show suspicious traversal attempts or successful file reads.

How to confirm the fix worked

Confirm dependency versions using package manager tooling such as npm ls h3, pnpm why h3, yarn why h3, or software composition analysis results, and verify deployed artifacts contain h3 1.15.6 or later, or 2.0.1-rc.15 or later. Test exposed static routes with benign encoded traversal probes and confirm the application returns 400/403/404 and does not return file contents from outside the intended static directory. Review build lockfiles and container images to ensure no vulnerable h3 copy remains in production bundles. Validate that reverse proxy, CDN, and WAF layers do not decode and forward dangerous traversal sequences in a way that bypasses application controls.

Typical attack path

1. Identify an internet-accessible application or API using h3 with static file serving enabled.
2. Find or guess routes backed by serveStatic, such as public asset, upload, documentation, or static content paths.
3. Send crafted HTTP GET requests containing percent-encoded dot-segment traversal sequences to attempt to escape the static root directory.
4. Target high-value readable files such as .env, package.json, configuration files, source code, SSH keys, service account files, or deployment metadata.
5. Use any exposed credentials, tokens, or internal configuration details for further intrusion, privilege escalation, or lateral movement.

How to detect it

Review web server, reverse proxy, CDN, WAF, and application access logs for requests to static file routes containing encoded traversal sequences. Focus on percent-encoded dot characters and slash or backslash variants, double-encoding, and mixed encoded/plain traversal patterns. Prioritize events where the response status was 200, 206, or another successful response, especially when the requested path appears to target secrets, configuration, source files, keys, package metadata, or operating system files. Investigate repeated probing across many filenames from a single source IP or user agent, and look for follow-on authentication attempts, cloud API use, database logins, or source repository access using credentials that may have been exposed. Because no specific threat actor or KEV exploitation is indicated in the provided data, detection should center on generic path traversal activity against h3-backed static routes and any signs of sensitive file disclosure.

• %2e%2e%2f
• %2e%2e/
• ..%2f
• %2e%2e%5c
• ..%5c
• %252e%252e%252f
• %252e%252e/
• %2e%2e%2f.env
• %2e%2e/.env
• ..%2f.env
• %2e%2e%2fpackage.json
• %2e%2e%2fpackage-lock.json
• %2e%2e%2fpnpm-lock.yaml
• %2e%2e%2fyarn.lock
• %2e%2e%2fserver.js
• %2e%2e%2fapp.js
• %2e%2e%2fconfig.json
• %2e%2e%2fconfig.js
• %2e%2e%2f.ssh%2fid_rsa
• %2e%2e%2fetc%2fpasswd
• %2e%2e%2fproc%2fself%2fenviron

What your security team should do

• Inventory all applications and services that depend on h3, including transitive dependencies in Node.js applications and frameworks.
• Prioritize patching internet-facing applications that expose static file serving or user-accessible file paths.
• Upgrade to h3 1.15.6 or later, or h3 2.0.1-rc.15 or later, and redeploy affected services.
• Search HTTP access logs for encoded traversal attempts and investigate any requests that returned HTTP 200 responses or unusually large file responses.
• Rotate application, cloud, database, and third-party secrets if evidence suggests sensitive files such as .env, configuration files, or key material were accessed.
• Add WAF or reverse proxy detections for percent-encoded dot-segment traversal attempts as compensating control, but do not rely on filtering as a substitute for upgrading.
• Harden service runtime permissions so the application process cannot read sensitive files outside the intended static content directory.