---
id: CVE-2026-49755
aliases:
  - GHSA-655f-mp8p-96gv
title: >-
  Req vulnerable to unbounded archive/compression extraction triggered by
  response content-type
summary: >-
  Req vulnerable to unbounded archive/compression extraction triggered by
  response content-type
severity: high
cwe:
  - CWE-409
vendor: req
product: req
ecosystem: erlang
affected:
  - 'req >= 0.1.0, < 0.6.1'
patched:
  - req 0.6.1
published: '2026-07-29'
updated: '2026-07-29'
source: GHSA
sourceUrl: 'https://github.com/advisories/GHSA-655f-mp8p-96gv'
references:
  - url: 'https://github.com/wojtekmach/req/security/advisories/GHSA-655f-mp8p-96gv'
  - url: 'https://nvd.nist.gov/vuln/detail/CVE-2026-49755'
  - url: >-
      https://github.com/wojtekmach/req/commit/84977e5b1a83f26e749d55ad06e3625464af4e8d
  - url: 'https://cna.erlef.org/cves/CVE-2026-49755.html'
  - url: 'https://osv.dev/vulnerability/EEF-CVE-2026-49755'
  - url: 'https://github.com/advisories/GHSA-655f-mp8p-96gv'
tags:
  - ghsa
  - erlang
epss: 0.007
epssPercentile: 0.51058
ingestedAt: '2026-07-29T15:48:25.906Z'
---

## Overview

### 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", <<400 MB of zero bytes>>}]`. 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.

## Affected packages

- `req >= 0.1.0, < 0.6.1`

## Remediation

Upgrade to a patched release:

- `req 0.6.1`