CVE-2026-48594: Decompression Bomb Denial of Service in Elixir Tesla HTTP Client

Tesla is an extensible HTTP client library for the Elixir programming language, commonly used to make API calls and process external requests. To simplify content handling, Tesla provides plug-in middlewares such as Tesla.Middleware.DecompressResponse and Tesla.Middleware.Compression to automatically inflate compressed responses. These middlewares analyze headers such as Content-Encoding and transparently decompress payloads encoded via gzip or deflate.

The vulnerability, designated as CVE-2026-48594, resides within the eager and unconstrained nature of this decompression mechanism. When an Elixir application utilizes these middlewares to fetch remote assets, the client exposes a network-facing attack surface. If the destination server is malicious or compromised, it can return carefully designed, highly compressed payloads that cause immediate resource exhaustion.

This security flaw belongs to the class of Improper Handling of Highly Compressed Data, also known as a decompression bomb or a ZIP bomb (CWE-409). The primary impact is a severe Denial of Service (DoS) of the Erlang Runtime System (BEAM) due to uncontrolled heap memory allocation. Because the BEAM VM handles multiple concurrent processes within a shared OS process memory space, a major allocation spike can terminate the entire virtual machine instance.

The fundamental flaw in Tesla versions prior to 1.18.3 is the absence of an upper bound on decompressed binary sizes combined with the support for recursive decompression of nested encodings. During the execution of the response pipeline, the middleware parses the content-encoding header into an array of codecs. It then iterates recursively over this list, sequentially running decompression passes on the cumulative intermediate output binaries.

The pre-patched implementation of decompress_body/2 utilized one-shot Erlang :zlib API functions, specifically :zlib.gunzip/1 and :zlib.unzip/1. These functions inflate the entirety of the compressed payload directly into process memory without executing incremental checks or streaming chunks. Consequently, there is no opportunity for the calling process to halt decompression if the output exceeds safety thresholds.

By stacking multiple codecs in the header, such as Content-Encoding: gzip, gzip, an attacker forces the middleware into a nested decompression loop. This design flaw converts linear input growth into exponential memory consumption ($O(N^K)$), where $K$ is the number of codec layers. A single 500-byte wire payload can expand to several gigabytes of raw binary data within three iterations, immediately depleting the allocated memory of the active process.

The vulnerability is best understood by contrasting the pre-patch logic in lib/tesla/middleware/compression.ex with the remediation logic introduced in version 1.18.3. In the vulnerable version, recursive passes were performed directly on the binary body with no state tracking of length limits.

# Vulnerable Implementation (Pre-1.18.3)
defp decompress_body([gzip | rest], body) when gzip in ["gzip", "x-gzip"] do
  # One-shot expansion of the entire body without limit checks
  decompress_body(rest, :zlib.gunzip(body))
end
 
defp decompress_body(["deflate" | rest], body) do
  decompress_body(rest, :zlib.unzip(body))
end

The fix commit 340f75b5d191dc747ef7ac6365bd002d1cd55a9d introduces a streaming decompression wrapper around Erlang's :zlib library. It uses :zlib.safeInflate/2 in a recursive loop (drain_inflate/4) to parse chunks. This function tracks cumulative byte lengths and matches them against a user-configured :max_body_size constraint.

# Patched Implementation (1.18.3+)
defp inflate(body, window_bits, max_body_size) do
  z = :zlib.open()
  try do
    :zlib.inflateInit(z, window_bits)
    result = start_inflate(z, body, max_body_size)
    :zlib.inflateEnd(z)
    result
  catch
    :error, :data_error ->
      reraise Error, [reason: {:zlib, :data_error}], __STACKTRACE__
  after
    :zlib.close(z)
  end
end
 
defp start_inflate(z, body, max_body_size) do
  case :zlib.safeInflate(z, body) do
    {:finished, output} ->
      size = IO.iodata_length(output)
      ensure_within_limit!(size, max_body_size)
      IO.iodata_to_binary(output)
    {:continue, output} ->
      size = IO.iodata_length(output)
      ensure_within_limit!(size, max_body_size)
      drain_inflate(z, max_body_size, size, [output])
  end
end

Additionally, the patch implements strict verification of the parsed Content-Encoding headers. It limits the total number of recognized codecs to a maximum of one. If count_known_codecs(codecs) returns a value greater than 1, the pipeline raises a :multiple_codecs error and terminates, blocking stacked decompression attacks entirely.

An attacker can weaponize this vulnerability against any Elixir application that issues HTTP client requests to external, user-controlled targets. Typical scenarios include applications implementing SSRF-susceptible features such as webhook deliveries, link preview generation, scrape requests, or proxying mechanisms. The prerequisite is that the active Tesla pipeline must include the Tesla.Middleware.DecompressResponse or Tesla.Middleware.Compression plugs.

The attack flow is represented in the diagram below:

To construct the payload, the attacker compiles a file consisting of repeating byte sequences, such as a large block of null bytes (0x00). This file is compressed with aggressive options to achieve maximum density. The attacker then wraps this compressed file in a second layer of gzip compression, producing a tiny, nested decompression payload (e.g., 500 bytes on disk, expanding to several gigabytes).

The malicious server is configured to deliver this payload alongside a custom Content-Encoding: gzip, gzip header. When the Elixir client initiates the connection and receives the headers, the decompression middleware parses the stacked values. As the middleware executes consecutive passes of :zlib.gunzip/1 on the BEAM heap, the process consumes all available physical memory, forcing the operating system to invoke the Out-Of-Memory (OOM) killer to terminate the Elixir application.

The impact of exploiting CVE-2026-48594 is categorized as a High Availability compromise. While the vulnerability does not directly permit Remote Code Execution (RCE) or Information Disclosure, the resulting Denial of Service is highly disruptive. Because the BEAM VM executes multi-tenant workflows or distributed node architectures within a single OS-level process, an OOM crash of the primary VM shuts down all sibling services and concurrent processes.

The CVSS v4.0 score of 8.2 reflects a high availability impact coupled with a low attack complexity. Because no authentication or user interaction is required, an automated script can systematically trigger the crash by registering malicious webhooks or entering hostile URLs. This predictability makes the bug an appealing target for malicious actors seeking to disrupt critical infrastructure.

Furthermore, if the application is deployed within an auto-scaling container environment, such as Kubernetes, recurring crashes can lead to a CrashLoopBackOff state. The repeated cycle of containers crashing, restarting, fetching the same payload, and crashing again can cascade upstream. This pattern drains container orchestration resources and incurs massive infrastructure expenses.

Remediation of this vulnerability requires upgrading the tesla library to version 1.18.3 or higher. This update introduces the necessary runtime protections and deprecates unsafe one-shot decompression behaviors. During the build phase, developers must ensure that the outdated versions are removed from the lockfile.

# Safe Configuration Example
defmodule SecureClient do
  use Tesla
 
  # Configured with a strict maximum decompressed body size
  plug Tesla.Middleware.DecompressResponse, max_body_size: 10_485_760 # 10 MB limit
end

If upgrading immediately is not feasible, several defensive workarounds can be implemented. Developers can remove the DecompressResponse or Compression middlewares from active client pipelines and handle decompression manually with size-constrained stream decoders. Alternatively, network-level ingress firewalls can be configured to block or normalize HTTP response headers containing multiple Content-Encoding declarations.