Approved changes feed: RSS · Atom
cpe:2.3:a:wojtekmach:req:*:*:*:*:*:*:*:*part: a version: * update: *
| Vendor | Wojtekmach (d8f5f0bb-49ef-5116-9cae-1fe9973a7f42) |
|---|---|
| Product | Req (abf1436f-fcc8-5edc-a837-051fce037fa2) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
Notes
Imported from gcve-enriched-dumps CVE data
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
pkg:github/wojtekmach/req |
purl2cpe | 2026-09-09 08:33:50.043047 |
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-49756 |
vulnerable | 2026-07-29 00:57:45.520432 |
Multipart form-data header injection in Req via unescaped name/filename/content_type
Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in wojtekmach Req allows multipart parameter smuggling via attacker-influenced part metadata.
Req.Utils.encode_form_part/2 in lib/req/utils.ex builds the per-part headers by interpolating the caller-supplied name, filename, and content_type values directly into the content-disposition and content-type lines with no escaping or CRLF stripping. A value containing ", \r, or \n closes the surrounding quoted value and starts a new header line; an additional \r\n--<boundary> terminates the current part and prepends a smuggled part of the attacker's choosing.
This is reachable through every supported way of supplying a part. It is particularly easy when value is a %File.Stream{}, because filename then defaults to Path.basename(stream.path) and POSIX filenames may legitimately contain \r and \n. Any application that forwards user-controlled filenames (or field names / MIME types) through Req.post/2 with form_multipart: lets an attacker inject arbitrary headers into the outgoing multipart body or smuggle additional fields and parts into the request the victim service sends downstream.
This issue affects req: from 0.5.3 before 0.6.0.
Published: 2026-06-08T15:20:24.035Z
Updated: 2026-06-08T16:34:58.505Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-49755 |
vulnerable | 2026-07-29 00:57:45.520161 |
Decompression bomb DoS in Req via auto-decoded archive and compressed response bodies
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in wojtekmach Req allows attacker-controlled HTTP servers to exhaust memory in a Req client via decompression-bomb response bodies.
Req's default response pipeline includes Req.Steps.decode_body/1 and Req.Steps.decompress_body/1 in lib/req/steps.ex. decode_body/1 dispatches on the server-supplied content-type (or URL extension) and calls :zip.extract(body, [:memory]) for application/zip, :erl_tar.extract({:binary, body}, [:memory]) for application/x-tar, and :erl_tar.extract({:binary, body}, [:memory, :compressed]) for application/gzip / .tgz. Each returns the full decompressed archive contents as a [{name, bytes}] list in memory, with no per-entry or total size cap. decompress_body/1 walks the content-encoding header and chains :zlib/:brotli/:ezstd decoders, so a response advertising content-encoding: gzip, gzip, gzip inflates through multiple layers without bound.
Both steps are enabled by default, no caller opt-in is required, and the attacker controls the content-type and content-encoding headers on their own server (or on any host reached via Req's automatic redirect following). A sub-megabyte response can expand to multiple gigabytes on the victim, crashing the BEAM process.
This issue affects req: from 0.1.0 before 0.6.1.
Published: 2026-06-08T15:20:57.415Z
Updated: 2026-06-08T17:14:08.858Z |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.
Inspect record JSON
Open this panel to browse, search, copy or download the JSON record.