GHSA-jvvf-x445-j334: Medium severity npm/fast-uri vulnerability
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.
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
Until upgrading, 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.
Event History
Frequently Asked Questions
Which application flows are exposed to this issue?
Applications are exposed when they accept an untrusted mailto URI, evaluate recipients or other fields from the parsed result, and then serialize the URI before handing it to a mail client or outbound sending path. A decision based only on parse().to can miss values that become active after serialization and reparsing.
What does an attacker need to provide to exploit this behavior?
The attacker needs to supply a mailto URI containing percent-encoded reserved field names, such as %74o, %73ubject, or %62ody. These names are not recognized as reserved during the initial parse but are decoded and emitted as to, subject, or body during serialization.
How can we mitigate the issue if an upgrade is not immediately possible?
Percent-decode mailto field names before comparing them with reserved names. Validation must account for encoded forms of to, subject, and body rather than checking only the raw field names.
How can we identify potentially affected inputs or detections?
Inspect the serialized mailto URI, or reparse it after serialization, rather than relying only on the initial parsed recipient list or raw-input checks for an extra to= field. Raw scanners may not see the injected reserved field because it materializes only when fast-uri serializes the value.
What version resolves the issue?
Upgrade fast-uri to version 4.1.5.