CVE-2026-48594 Overview
CVE-2026-48594 is a denial-of-service vulnerability in the elixir-tesla HTTP client library affecting versions from 0.6.0 before 1.18.3. The flaw resides in Tesla.Middleware.DecompressResponse and Tesla.Middleware.Compression, which decompress HTTP response bodies eagerly without any output size limit. A malicious or compromised server can return a small compressed payload that expands into gigabytes of memory on the Erlang BEAM VM. The recursive handling of multiple content-encoding tokens compounds the amplification exponentially. This issue is classified as [CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)].
Critical Impact
A few hundred bytes of crafted gzip data can exhaust BEAM heap memory, crashing or freezing any Elixir process making outbound Tesla HTTP calls.
Affected Products
- elixir-tesla tesla library versions 0.6.0 through 1.18.2
- Elixir applications using Tesla.Middleware.DecompressResponse
- Elixir applications using Tesla.Middleware.Compression
Discovery Timeline
- 2026-06-02 - CVE-2026-48594 published to NVD
- 2026-06-03 - Last updated in NVD database
Technical Details for CVE-2026-48594
Vulnerability Analysis
The vulnerability lives in lib/tesla/middleware/compression.ex. The decompress_body/2 function passes the entire HTTP response body to :zlib.gunzip/1 or :zlib.unzip/1 with no cap on the decompressed output size. Tesla performs this decompression eagerly in memory on the BEAM heap of the calling process.
A second design flaw multiplies the impact. The compression_algorithms/1 helper splits the content-encoding header on commas and decompress_body/2 recurses once per token. A server returning content-encoding: gzip, gzip, gzip, gzip triggers four sequential decompression passes on the same payload.
Each gzip layer can expand its input roughly 1000x. Four stacked layers therefore yield amplification on the order of 10^12, turning a few hundred bytes on the wire into gigabytes of heap allocation. The calling process exhausts memory and either crashes or freezes the BEAM scheduler.
Root Cause
The root cause is missing output-size validation in the decompression path combined with unbounded recursion over attacker-controlled content-encoding tokens. Tesla trusts the remote server to declare a sane encoding and never enforces a maximum decompressed length before allocating BEAM memory.
Attack Vector
An attacker controlling or impersonating an HTTP server contacted by a Tesla client returns a small gzip-bombed payload and a stacked content-encoding header. No authentication or user interaction is required. SSRF primitives, redirect chains, and outbound API integrations that fetch attacker-influenced URLs all expand the reachable attack surface.
No public proof-of-concept exploit code is available. Refer to the GitHub Security Advisory GHSA-mc85-72gr-vm9f and the patch commit for technical details of the fix.
Detection Methods for CVE-2026-48594
Indicators of Compromise
- HTTP responses containing repeated tokens in the content-encoding header, such as gzip, gzip, gzip
- Sudden BEAM VM memory spikes correlated with outbound HTTP requests from Tesla-based clients
- Erlang process crashes with system_limit or out-of-memory errors immediately after an HTTP response is received
- Unusually small compressed response bodies that produce disproportionately large decoded payloads
Detection Strategies
- Inspect outbound HTTP traffic at egress proxies for response headers advertising multiple compression algorithms in a single content-encoding value.
- Audit application dependencies for tesla versions earlier than 1.18.3 using mix deps or SBOM tooling.
- Add telemetry around Tesla middleware execution to record response body size before and after decompression.
Monitoring Recommendations
- Alert on BEAM memory/total metrics exceeding baseline thresholds during HTTP client operations.
- Track process restart counts in supervised Tesla client workers to surface repeated crash patterns.
- Log and review any HTTP response with a content-encoding header containing commas for downstream Elixir services.
How to Mitigate CVE-2026-48594
Immediate Actions Required
- Upgrade tesla to version 1.18.3 or later in mix.exs and redeploy all affected Elixir services.
- Inventory every internal service using Tesla and confirm whether Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression is in the pipeline.
- Restrict outbound HTTP destinations for services that cannot be patched immediately.
Patch Information
The fix is committed in the elixir-tesla repository and released in tesla 1.18.3. Review the GitHub commit changelog and the CNA advisory at cna.erlef.org for full remediation details. The OSV entry EEF-CVE-2026-48594 provides machine-readable affected-version data.
Workarounds
- Remove Tesla.Middleware.DecompressResponse and Tesla.Middleware.Compression from middleware pipelines if upgrading is not immediately possible.
- Place a reverse proxy or egress filter in front of Tesla clients to strip multi-token content-encoding headers and reject responses exceeding a fixed size.
- Wrap Tesla calls in isolated supervised processes with strict memory limits so a decompression bomb terminates only the worker, not the host node.
# Configuration example: pin a safe tesla version in mix.exs
# {:tesla, "~> 1.18.3"}
mix deps.update tesla
mix deps.get
mix deps.compile tesla
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


