Approved changes feed: RSS · Atom

cpe:2.3:a:wojtekmach:req:*:*:*:*:*:*:*:*

part: a version: * update: *

VendorWojtekmach (d8f5f0bb-49ef-5116-9cae-1fe9973a7f42)
ProductReq (abf1436f-fcc8-5edc-a837-051fce037fa2)
Edition*
Language*
Software edition*
Target software*
Target hardware*
Other*

Notes

Imported from gcve-enriched-dumps CVE data

PURL mappings

PURLSourceLast updated
pkg:github/wojtekmach/req purl2cpe 2026-09-09 08:33:50.043047

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
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
Reference links
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
Reference links
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 JSON directly

Open this panel to browse, search, copy or download the JSON record.