GHSA-PX9F-WHJ3-246M
Vulnerability from github – Published: 2026-07-29 15:29 – Updated: 2026-07-29 15:29Summary
Req's multipart form encoder interpolates the per-part name, filename, and content_type directly into the part headers without escaping. An attacker who can influence any of those values can inject CRLF-separated header lines, smuggle additional form fields, or prepend a whole extra part into the request the victim service sends downstream.
Details
Req.Utils.encode_form_part/2 in lib/req/utils.ex builds the per-part header iodata by concatenating the three caller-supplied strings verbatim into content-disposition: form-data; name="<name>"; filename="<filename>" and content-type: <content_type>. There is no CRLF stripping, no quote escaping, and no validation. A value containing "\r\n closes the surrounding quoted value and starts a new header line; an additional \r\n--<boundary> terminates the current part and lets the attacker prepend a smuggled part.
The flaw is reachable through every supported way of supplying a part. It is especially easy to hit when value is a %File.Stream{}, because filename then defaults to Path.basename(stream.path) and POSIX filenames may legitimately contain \r and \n. RFC 7578 / WHATWG form-data requires percent-encoding ", CR, and LF in these fields; the fix adopts that behavior.
PoC
- Construct a malicious
filenamesuch asharmless.txt"\r\nX-Smuggled: marker\r\nContent-Disposition: form-data; name="pwned. - Call
Req.post!(url, form_multipart: [upload: {"benign body", filename: <malicious>, content_type: "text/plain"}]). - The emitted multipart body contains a real
X-Smuggled:header line and an extraContent-Dispositionforname="pwned", alongside Req's legitimate headers.
Impact
HTTP request smuggling / multipart parameter smuggling in the HTTP client. Any application using Req to send form_multipart requests where any of name, filename, or content_type can be influenced by an untrusted source is affected, most commonly upload proxies and re-uploaders that derive filename from Path.basename/1 on a user-controlled path.
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "req"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.3"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49756"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T15:29:14Z",
"nvd_published_at": "2026-06-08T16:16:44Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nReq\u0027s multipart form encoder interpolates the per-part `name`, `filename`, and `content_type` directly into the part headers without escaping. An attacker who can influence any of those values can inject CRLF-separated header lines, smuggle additional form fields, or prepend a whole extra part into the request the victim service sends downstream.\n\n### Details\n\n`Req.Utils.encode_form_part/2` in `lib/req/utils.ex` builds the per-part header iodata by concatenating the three caller-supplied strings verbatim into `content-disposition: form-data; name=\"\u003cname\u003e\"; filename=\"\u003cfilename\u003e\"` and `content-type: \u003ccontent_type\u003e`. There is no CRLF stripping, no quote escaping, and no validation. A value containing `\"\\r\\n` closes the surrounding quoted value and starts a new header line; an additional `\\r\\n--\u003cboundary\u003e` terminates the current part and lets the attacker prepend a smuggled part.\n\nThe flaw is reachable through every supported way of supplying a part. It is especially easy to hit when `value` is a `%File.Stream{}`, because `filename` then defaults to `Path.basename(stream.path)` and POSIX filenames may legitimately contain `\\r` and `\\n`. RFC 7578 / WHATWG form-data requires percent-encoding `\"`, CR, and LF in these fields; the fix adopts that behavior.\n\n### PoC\n\n1. Construct a malicious `filename` such as `harmless.txt\"\\r\\nX-Smuggled: marker\\r\\nContent-Disposition: form-data; name=\"pwned`.\n2. Call `Req.post!(url, form_multipart: [upload: {\"benign body\", filename: \u003cmalicious\u003e, content_type: \"text/plain\"}])`.\n3. The emitted multipart body contains a real `X-Smuggled:` header line and an extra `Content-Disposition` for `name=\"pwned\"`, alongside Req\u0027s legitimate headers.\n\n### Impact\n\nHTTP request smuggling / multipart parameter smuggling in the HTTP client. Any application using Req to send `form_multipart` requests where any of `name`, `filename`, or `content_type` can be influenced by an untrusted source is affected, most commonly upload proxies and re-uploaders that derive `filename` from `Path.basename/1` on a user-controlled path.",
"id": "GHSA-px9f-whj3-246m",
"modified": "2026-07-29T15:29:15Z",
"published": "2026-07-29T15:29:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wojtekmach/req/security/advisories/GHSA-px9f-whj3-246m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49756"
},
{
"type": "WEB",
"url": "https://github.com/wojtekmach/req/commit/74506ff2c5addf74df85d79dc726e9b2e264a8ba"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-49756.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/wojtekmach/req"
},
{
"type": "WEB",
"url": "https://github.com/wojtekmach/req/releases/tag/v0.6.0"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-49756"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Req vulnerable to multipart form-data header injection via unescaped name/filename/content_type"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.