CVE-2026-48594: Elixir Tesla HTTP Client DoS Vulnerability

CVE-2026-48594 is a denial of service vulnerability in Elixir Tesla HTTP client caused by improper decompression of HTTP responses. Attackers can craft compression bombs to exhaust memory. This article covers technical details, affected versions from 0.6.0 to 1.18.2, impact analysis, and mitigation strategies.

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.

bash

# 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