Description

fast-uri is a dependency-free RFC 3986 URI parser for Node.js, used by Fastify and ajv, that added a mailto scheme parser in version 4.1.3. In versions 4.1.3 and 4.1.4, the mailto parser compares each query field name to the reserved names to, subject, and body while the name is still percent-encoded, and decodes it only when storing it as a generic header, so a percent-encoded spelling of a reserved field name is not recognized as that field at parse time but is re-emitted as the literal field name when the parsed URI is serialized. An application that validates, logs, or displays the recipient list from the first parse and then serializes the URI and sends it can silently gain an attacker-chosen recipient, and the subject and body fields can be smuggled across the same roundtrip. The issue is fixed in fast-uri 4.1.5, and users should upgrade to 4.1.5 or later. As a workaround, do not act on a mailto URI that fast-uri has re-serialized without first decoding and re-validating its recipient, subject, and body fields.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.8",
  "pubDate": "2026-09-15T11:17:12.453Z",
  "pubdate": "2026-09-15T11:17:12.453Z",
  "executiveSummary": "The fast-uri library is susceptible to a query parameter smuggling vulnerability within its mailto scheme parser, specifically affecting versions 4.1.3 and 4.1.4.\nThis flaw arises from improper handling of percent-encoded characters during the validation of reserved query fields such as 'to', 'subject', and 'body'.\nAn attacker can bypass security filters by using percent-encoded variants of these reserved keys, which are ignored by the parser but subsequently normalized into functional parameters during URI re-serialization.\nThis behavior facilitates parameter smuggling, where an attacker can inject or overwrite sensitive mailto headers, potentially redirecting communications or injecting malicious content into emails.\nThe vulnerability poses significant risks to applications that perform round-trip URI processing—where a URI is validated, logged, or displayed, then serialized and transmitted to an end-user or secondary system.\nExploitation requires no authentication, and the attack vector is limited only by the ability of the attacker to influence the URI input processed by the vulnerable application.",
  "technicalDetails": "The vulnerability originates in the mailto scheme parser logic within fast-uri versions 4.1.3 and 4.1.4. The component performs a security check on query field names to identify reserved parameters ('to', 'subject', 'body') that dictate mail metadata.\nThe root cause is a discrepancy in the order of operations between validation and storage: the parser compares the query field name against the reserved list while the string remains in a percent-encoded state. Consequently, if a field name is provided as an encoded string (e.g., '%74o' for 'to'), the parser fails to recognize it as a reserved field.\nHowever, the parser subsequently decodes these fields when storing them as generic headers. When the application triggers a re-serialization of the URI object, the library emits the decoded, normalized parameter names.\nThis discrepancy leads to a bypass of the security validation logic. An attacker can supply a malicious URI containing encoded reserved keys that bypasses internal validation filters, but which manifests as active 'to', 'subject', or 'body' parameters upon serialization.\nThe attack flow follows these steps: 1) The attacker constructs a URI containing percent-encoded keys that represent sensitive fields. 2) The application parses the URI; because the keys are encoded, the library treats them as arbitrary, non-restricted headers, passing initial validation checks. 3) The application stores, logs, or processes these headers. 4) The application serializes the URI to send to a mail client or downstream service. During this phase, the previously encoded keys are decoded into their literal form (e.g., 'to'). 5) The downstream mail handler receives a URI containing attacker-injected fields that were intended to be prohibited, resulting in successful parameter smuggling.\nThis vulnerability is particularly critical for applications that rely on fast-uri for sanitizing URIs before passing them to internal infrastructure or client-side interfaces. The post-exploitation impact includes the silent modification of email recipients, subject line manipulation, and the potential for cross-site scripting or phishing attacks through smuggled body content."
}