{"id":"CVE-2026-49755","aliases":["EEF-CVE-2026-49755","EUVD-2026-35098","GHSA-655f-mp8p-96gv"],"status":"published","title":"Decompression bomb DoS in Req via auto-decoded archive and compressed response bodies","description":"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.\n\nReq'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.\n\nBoth 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.\n\nThis issue affects req: from 0.1.0 before 0.6.1.","severity":{"version":"4.0","score":8.2,"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","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00596,"percentile":0.48924,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-409"],"published":"2026-06-08T15:20:57Z","modified":"2026-11-11T10:31:04Z","fixes":[{"ecosystem":"Hex","package":"req","fixed_in":["0.6.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Hex","package":"req","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.1.0"},{"fixed":"0.6.1"}]}]},{"source":"osv","ecosystem":"Hex","package":"req","ranges":[{"type":"SEMVER","events":[{"introduced":"0.1.0"},{"fixed":"0.6.1"}]}],"versions":["0.1.0","0.1.1","0.1.2","0.2.0","0.2.1","0.2.2","0.3.0","0.3.1","0.3.10","0.3.11","0.3.12","0.3.2","0.3.3","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.3.9","0.4.0","0.4.1","0.4.10","0.4.11","0.4.12","0.4.13","0.4.14","0.4.2","0.4.3","0.4.4","0.4.5","0.4.6","0.4.7","0.4.8","0.4.9","0.5.0","0.5.1","0.5.10","0.5.11","0.5.12","0.5.13","0.5.14","0.5.15","0.5.16","0.5.17","0.5.18","0.5.2","0.5.3","0.5.4","0.5.5","0.5.6","0.5.7","0.5.8","0.5.9","0.6.0"]},{"source":"osv","ecosystem":"Hex","package":"req","ranges":[{"type":"SEMVER","events":[{"introduced":"0.1.0"},{"fixed":"0.6.1"}]}],"versions":["0.1.0","0.1.1","0.1.2","0.2.0","0.2.1","0.2.2","0.3.0","0.3.1","0.3.10","0.3.11","0.3.12","0.3.2","0.3.3","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.3.9","0.4.0","0.4.1","0.4.10","0.4.11","0.4.12","0.4.13","0.4.14","0.4.2","0.4.3","0.4.4","0.4.5","0.4.6","0.4.7","0.4.8","0.4.9","0.5.0","0.5.1","0.5.10","0.5.11","0.5.12","0.5.13","0.5.14","0.5.15","0.5.16","0.5.17","0.5.18","0.5.2","0.5.3","0.5.4","0.5.5","0.5.6","0.5.7","0.5.8","0.5.9","0.6.0"]}],"products":[{"vendor":"wojtekmach","product":"req"}],"references":[{"url":"https://github.com/wojtekmach/req/security/advisories/GHSA-655f-mp8p-96gv","tags":["vendor-advisory","related","exploit","Vendor Advisory","Exploit","Patch","advisory","web"]},{"url":"https://cna.erlef.org/cves/CVE-2026-49755.html","tags":["related","Third Party Advisory","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-49755","tags":["related","Third Party Advisory","Patch","Mitigation","web"]},{"url":"https://github.com/wojtekmach/req/commit/84977e5b1a83f26e749d55ad06e3625464af4e8d","tags":["patch","Patch","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-49755","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-655f-mp8p-96gv"},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/49xxx/CVE-2026-49755.json","tags":["advisory"]},{"url":"https://github.com/wojtekmach/req","tags":["package"]},{"url":"https://github.com/wojtekmach/req.git","tags":["package"]},{"url":"https://hex.pm/packages/req","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-49755","title":"Decompression bomb DoS in Req via auto-decoded archive and compressed response bodies","description":"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.\n\nReq'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.\n\nBoth 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.\n\nThis issue affects req: from 0.1.0 before 0.6.1.","status":"published","published":"2026-06-08T15:20:57.415Z","modified":"2026-06-08T17:14:08.858Z","cvss":[{"version":"4.0","score":8.2,"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","level":"high","assessor":"cna"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T13:35:10.963527Z"}],"euvd":[{"id":"EUVD-2026-35098","description":"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.\n\nReq'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.\n\nBoth 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.\n\nThis issue affects req: from 0.1.0 before 0.6.1.","status":"published","published":"2026-06-08T15:20:57Z","modified":"2026-06-08T17:14:08Z","cvss":[{"version":"4.0","score":8.2,"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","level":"high"}],"updated_at":"2026-11-02T18:20:48.834104Z"}],"ghsa":[{"id":"GHSA-655f-mp8p-96gv","title":"Req vulnerable to unbounded archive/compression extraction triggered by response content-type","description":"### Summary\n\nReq'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.\n\n### Details\n\n**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`.\n\n**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.\n\n**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).\n\n### PoC\n\n1. 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).\n2. From the victim process, call `Req.get!(url)` against that server (no special options, no opt-in to archive decoding).\n3. `decode_body/1` dispatches on `content-type`, invokes `:zip.extract(body, [:memory])`, and the response body becomes `[{~c\"bomb.bin\", \u003c\u003c400 MB of zero bytes\u003e\u003e}]`. A sub-MB request produces hundreds of MB resident memory; layering gzip on the `content-encoding` path or increasing entry size scales arbitrarily.\n\n### Impact\n\nMemory-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.","status":"published","published":"2026-07-29T15:23:16Z","modified":"2026-07-29T15:23:18Z","cvss":[{"version":"4.0","score":8.2,"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","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T14:40:54.767849Z"}],"nvd":[{"id":"CVE-2026-49755","description":"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.\n\nReq'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.\n\nBoth 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.\n\nThis issue affects req: from 0.1.0 before 0.6.1.","status":"published","published":"2026-06-08T16:16:43.86Z","modified":"2026-08-18T15:46:34.387Z","cvss":[{"version":"4.0","score":8.2,"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T14:12:22.73178Z"}],"osv":[{"id":"CVE-2026-49755","title":"Decompression bomb DoS in Req via auto-decoded archive and compressed response bodies","description":"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.\n\nReq'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.\n\nBoth 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.\n\nThis issue affects req: from 0.1.0 before 0.6.1.","status":"published","published":"2026-06-08T15:20:57.415Z","modified":"2026-11-11T10:31:04.959764024Z","cvss":[{"version":"4.0","score":8.2,"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","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-11T11:06:47.461458Z"},{"id":"EEF-CVE-2026-49755","title":"Decompression bomb DoS in Req via auto-decoded archive and compressed response bodies","description":"## Summary\n\nImproper 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.\n\nReq'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.\n\nBoth 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.\n\nThis issue affects req: from 0.1.0 before 0.6.1.\n\n## Workarounds\n\nDisable Req's automatic body decoding on requests that fetch attacker-influenced URLs by passing decode\\_body: false to Req.new/1 / Req.get!/1. To also skip the content-encoding decompression pipeline, pass raw: true. Both options leave the response body as the raw on-the-wire bytes, so the caller can size-check before any decompression.","status":"published","published":"2026-06-08T15:20:57.415Z","modified":"2026-09-08T03:30:07.662662279Z","cvss":[{"version":"4.0","score":8.2,"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","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T15:46:33.520522Z"},{"id":"GHSA-655f-mp8p-96gv","title":"Req vulnerable to unbounded archive/compression extraction triggered by response content-type","description":"### Summary\n\nReq'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.\n\n### Details\n\n**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`.\n\n**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.\n\n**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).\n\n### PoC\n\n1. 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).\n2. From the victim process, call `Req.get!(url)` against that server (no special options, no opt-in to archive decoding).\n3. `decode_body/1` dispatches on `content-type`, invokes `:zip.extract(body, [:memory])`, and the response body becomes `[{~c\"bomb.bin\", \u003c\u003c400 MB of zero bytes\u003e\u003e}]`. A sub-MB request produces hundreds of MB resident memory; layering gzip on the `content-encoding` path or increasing entry size scales arbitrarily.\n\n### Impact\n\nMemory-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.","status":"published","published":"2026-07-29T15:23:16Z","modified":"2026-07-29T15:30:39.580689426Z","cvss":[{"version":"4.0","score":8.2,"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","level":"high"}],"cwes":["CWE-409"],"updated_at":"2026-11-02T15:46:39.266402Z"}]}}