CVE-2026-86818: fast-uri vulnerable to mailto header injection via percent-encoded field-name desynchronization
Impact
fast-uri's mailto scheme parser compares each query field name to the reserved names (to, subject, body) while the name is still percent-encoded, and only percent-decodes it when storing it as a generic header. On serialize, the decoded name is re-emitted, so a field name such as %74o (percent-encoded to) is not recognized as a recipient at parse time (parse().to shows only the legitimate recipient) but materializes as a literal to= field after serialize(), and reparsing then treats it as a recipient. The same technique smuggles subject and body through %73ubject and %62ody.
An application that parses an untrusted mailto URI, makes a display, allowlist, or logging decision on parse().to, then re-serializes the result and passes the serialized string to a mail client or an outbound send path can gain an attacker-chosen recipient, subject, or body that was not visible when the recipient list was checked. A scanner inspecting the raw input for an extra to= sees nothing, because the injected field appears only after fast-uri serializes.
Patches
Upgrade to fast-uri 4.1.5.
Workarounds
Percent-decode and compare mailto field names case-insensitively before trusting parse().to, or re-check the recipient list on the serialized output rather than only on the initial parse, until upgrading.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/fast-urito a version that resolves this vulnerability.Fixed in 4.1.5 - Upgrade
Upgrade
fast-urito a version that resolves this vulnerability.Fixed in 4.1.5 - Compensating control
Before acting on a mailto URI that fast-uri has re-serialized, percent-decode and compare field names case-insensitively, then re-validate the recipient, subject, and body fields; alternatively, re-check the recipient list on the serialized output rather than relying only on the initial parse.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using fast-uri 4.1.3 or 4.1.4 are exposed when they process attacker-controlled mailto URIs and later act on a URI after fast-uri has serialized it. Risk is especially relevant if the application validates, logs, or displays recipients from an initial parse before sending the re-serialized URI.
What does an attacker need to exploit this?
An attacker needs to supply a crafted mailto URI containing percent-encoded spellings of reserved query field names. This can cause recipient, subject, or body values to be interpreted differently after a parse-and-serialize roundtrip.
What should be done if upgrading is not immediately possible?
Do not act on a mailto URI re-serialized by fast-uri unless its recipient, subject, and body fields have first been decoded and re-validated. This prevents relying on the initial parse result when making sending decisions.
How can I determine whether my application is affected?
Check whether the deployed fast-uri version is 4.1.3 or 4.1.4 and whether the application accepts or handles mailto URIs. Then identify flows that parse a mailto URI, inspect or validate fields, serialize it, and use the serialized result to send email.