GitHub Advisoryadvisory · Hex
GHSA-655f-mp8p-96gv Req vulnerable to unbounded archive/compression extraction triggered by response content-type
HIGH
Official page ↗
- Aliases
- CVE-2026-49755
- Ecosystem
- Hex
- Packages
- req
- Severity
- High
- CVSS vector
- CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
- Weaknesses
- CWE-409
- Reviewed
- 2026-07-29
Affected packages
• Hex req: >= 0.1.0, < 0.6.1 → fixed in 0.6.1
Description
Summary
Req's default response pipeline auto-decodes archive and compressed bodies based on the server-supplied `content-type` (or URL extension) and materialises the full decompressed contents in memory with no size cap. An attacker who controls (or can redirect a victim into) an HTTP endpoint reached by `Req.get!/1` can return a tiny "decompression bomb" that expands to many gigabytes on the client and exhausts the BEAM's memory.
Details
1. Archive auto-decoding. `Req.Steps.decode_body/1` in `lib/req/steps.ex` dispatches on the response `content-type` (or URL extension) and calls Erlang's archive libraries with `:memory`, returning a `[{name, bytes}]` list of every entry fully decompressed in RAM: `application/zip` → `:zip.extract(body, [:memory])`, `application/x-tar` → `:erl_tar.extract({:binary, body}, [:memory])`, `application/gzip` / `.tgz` → `:erl_tar.extract({:binary, body}, [:memory, :compressed])`. No byte cap is enforced before decoding and no per-entry size limit is passed to `:zip` / `:erl_tar`.
2. content-encoding chaining. `Req.Steps.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.
3. Default-on, attacker-chosen decoder. Both steps are part of Req's default pipeline. The caller does not need to opt in, and the attacker chooses which decoder fires by setting `content-type` and `content-encoding` on their own server (or on any host reached via Req's automatic redirect following).
PoC
1. Run an HTTP server that responds 200 with `content-type: application/zip` and a body that is a zip archive whose single entry is ~400 MB of zero bytes (compressed wire payload: a few hundred KB).
2. From the victim process, call `Req.get!(url)` against that server (no special options, no opt-in to archive decoding).
3. `decode_body/1` dispatches on `content-type`, invokes `:zip.extract(body, [:memory])`, and the response body becomes `[{~c"bomb.bin", >}]`. A sub-MB request produces hundreds of MB resident memory; layering gzip on the `content-encoding` path or increasing entry size scales arbitrarily.
Impact
Memory-exhaustion denial of service against any Elixir application that uses Req with its default step pipeline to fetch URLs influenced by an untrusted party, including webhook senders, link previews, OAuth/OIDC discovery clients, package mirrors, image proxies, and any `Req.get!/1` call that may follow redirects to attacker-controlled hosts. No authentication is required; a single response can crash the BEAM and take down unrelated workloads on the same VM.
Related
Alias · CVE (1)
- CVE-2026-49755 Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in wojtekmach Req allows attacker-controlled HTTP servers to… vulnerability
Weakness · CWE (1)
- CWE-409 Improper Handling of Highly Compressed Data (Data Amplification) weakness
References
- https://github.com/wojtekmach/req/security/advisories/GHSA-655f-mp8p-96gv web
- https://nvd.nist.gov/vuln/detail/CVE-2026-49755 advisory
- https://github.com/wojtekmach/req/commit/84977e5b1a83f26e749d55ad06e3625464af4e8d web
- https://cna.erlef.org/cves/CVE-2026-49755.html web
- https://github.com/wojtekmach/req package
- https://osv.dev/vulnerability/EEF-CVE-2026-49755 web