Description

h3 versions before 1.15.9 contain a path traversal vulnerability in the serveStatic utility. A double-decoding flaw allows a request path containing double-encoded dot sequences (e.g. %252e%252e) to be decoded to %2e%2e, which survives resolveDotSegments() because that function only checks for literal '.' characters. When the resulting asset ID is resolved by URL-based backends (CDN, S3, object storage), %2e%2e is interpreted as '..' per RFC 3986, enabling path traversal to read arbitrary files from the backend.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-06T12:17:15.900Z",
  "pubdate": "2026-09-06T12:17:15.900Z",
  "executiveSummary": "The h3 library, specifically the serveStatic utility, is affected by a path traversal vulnerability originating from a double-decoding flaw. This vulnerability allows an unauthenticated remote attacker to bypass path validation mechanisms and access arbitrary files stored on backend systems such as CDNs, S3 buckets, or object storage services.\nThe root cause resides in the inadequate sanitization of user-supplied input where double-encoded dot sequences are processed. Because the application fails to normalize these sequences before path resolution, the backend infrastructure interprets the malicious input as directory traversal sequences (../).\nThis vulnerability poses a significant risk to data confidentiality, as it enables unauthorized read access to sensitive assets or configuration files. Successful exploitation does not require prior authentication and can be executed via standard HTTP requests. Organizations utilizing h3 versions prior to 1.15.9 are at risk and should prioritize upgrading to a secure version to mitigate potential exfiltration of backend-hosted resources.",
  "technicalDetails": "The vulnerability exists within the serveStatic utility of the h3 library, affecting all versions prior to 1.15.9. The flaw is rooted in an improper handling of URI encoding during the input normalization process. When serveStatic processes a request path, it fails to account for double-encoded characters, specifically the sequence '%252e%252e'.\nThe attack flow initiates when an attacker crafts a malicious request path containing double-encoded dot sequences. The application performs an initial decoding step, converting '%252e%252e' into '%2e%2e'. Following this, the application invokes the resolveDotSegments() function to sanitize the path and prevent traversal. However, resolveDotSegments() is designed to only detect literal dot characters ('.'). Because the input now contains encoded dots rather than literal dots, the function fails to identify the malicious payload and allows it to pass through validation.\nThe exploitation succeeds because of how downstream URL-based backends, such as S3, CDNs, or various object storage services, interpret the resulting URI. According to RFC 3986, these backend systems perform their own URI decoding. When the backend receives the '%2e%2e' string, it decodes this sequence back into the traversal sequence '..'. This effectively bypasses the application-level security checks and forces the backend to interpret the path as a directory traversal request.\nBy manipulating the request in this manner, an attacker can escape the intended root directory of the serveStatic utility. This allows the attacker to read arbitrary files or objects hosted on the backend storage system that were not intended to be publicly accessible. The attack requires no authentication or special privileges, as the vulnerability is triggered through the standard processing logic of the server's static asset handler. The impact is primarily the unauthorized disclosure of sensitive information, potentially including proprietary code, environment configuration files, or private user data stored on the infrastructure backend.\nPost-exploitation, an attacker can systematically probe the file structure of the backend storage to identify and retrieve sensitive assets, potentially mapping the entire accessible file system from the perspective of the server's backend service account."
}