CVE-2026-48597: Denial of Service via Atom Table Exhaustion in Elixir Tesla Client (Mint Adapter)

CVE-2026-48597 is a high-severity Denial of Service (DoS) vulnerability in the Elixir HTTP client library Tesla, specifically when utilizing the Mint adapter backend (Tesla.Adapter.Mint). This vulnerability allows unauthenticated, remote attackers to trigger an unrecoverable system shutdown of the host application by exhausting the global Erlang Virtual Machine (BEAM) atom table. This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling.

In Elixir and Erlang architectures, the BEAM Virtual Machine executes application logic inside isolated green processes. While the VM is highly resilient to localized crashes, certain shared resources are global and bounded. One such resource is the atom table, which registers unique constant values used for configuration, pattern matching, and internal naming. Because the table is bounded and entries cannot be reclaimed, any capability that permits untrusted input to generate unique atoms exposes the entire system to a fatal crash.

The attack surface is exposed whenever an Elixir application accepts untrusted input to influence outbound HTTP requests, or when automatic redirect processing is enabled within the HTTP client pipeline. An attacker can systematically generate requests with unique URI schemes, forcing the client to dynamically register new atoms. When the total atom count exceeds the physical limit of the virtual machine, the BEAM process crashes instantly, causing complete loss of system availability.

The root cause of CVE-2026-48597 is the unsafe conversion of dynamically supplied URL schemes into Erlang atoms within the Tesla.Adapter.Mint component. In the BEAM Virtual Machine, an atom is a literal constant whose name is mapped to an internal integer index in a global table. This design facilitates rapid term comparison and minimizes memory footprints during execution. However, to maintain high-performance lookups, the BEAM VM does not subject the atom table to garbage collection, meaning any allocated atom remains in memory until the VM process terminates.

Because allocated atoms are permanent, the virtual machine enforces a default hard ceiling of 1,048,576 entries in the global atom table to protect system memory. If an application programmatically creates atoms at runtime based on external inputs, it allows an attacker to continuously increment this count. When the limit is breached, the virtual machine is incapable of allocating further constants and terminates immediately with a system_limit runtime crash. This crash is unrecoverable from within the Elixir application itself, as the entire VM host process exits.

In vulnerable versions of Tesla (v1.3.0 through v1.18.2), the Mint adapter parsed incoming request URLs and dynamically converted the parsed scheme string directly into an atom via String.to_atom/1. This was executed during the connection phase within Tesla.Adapter.Mint.open_conn/2 to satisfy the requirements of the underlying Mint.HTTP.connect/4 library, which expects an atom representing the protocol. Because the adapter did not validate the scheme against an allow-list prior to conversion, any unique scheme string in the URI resulted in the registration of a new global atom.

An analysis of the vulnerable source code in lib/tesla/adapter/mint.ex reveals the exact location of the dynamic atom allocation. In vulnerable versions, the open_conn/2 function accepted a parsed URI struct and passed the raw scheme string directly to String.to_atom/1 inside the call to HTTP.connect/4:

defp open_conn(uri, opts) do
  # ... option configuration ...
  opts = Map.put_new(opts, :mode, :passive)
 
  with {:ok, conn} <-
         HTTP.connect(String.to_atom(uri.scheme), uri.host, uri.port, Enum.into(opts, [])) do
    {:ok, conn, Map.put(opts, :close_conn, true)}
  end
end

In the code block above, uri.scheme is a raw string derived from the target URL. Because String.to_atom/1 compiles any arbitrary binary sequence into a brand new atom on the fly, this line represents a massive vulnerability when handling external inputs. If an attacker passes randomscheme123://example.com, the VM dynamically instantiates the atom :"randomscheme123".

The official patch resolved this issue by removing the call to String.to_atom/1 entirely and replacing it with strict pattern-matching that only permits known, safe schemes (http and https). This pattern matching maps the safe string literals to static, pre-existing atoms during compilation, ensuring that no runtime allocation can occur for unexpected scheme strings:

# Patched implementation in lib/tesla/adapter/mint.ex
defp open_conn(uri, opts) do
  with {:ok, scheme} <- parse_scheme(uri.scheme) do
    # ... configuration processing using safe scheme ...
    opts = Map.put_new(opts, :mode, :passive)
 
    with {:ok, conn} <-
           HTTP.connect(scheme, uri.host, uri.port, Enum.into(opts, [])) do
      {:ok, conn, Map.put(opts, :close_conn, true)}
    end
  end
end
 
defp parse_scheme("http"), do: {:ok, :http}
defp parse_scheme("https"), do: {:ok, :https}
defp parse_scheme(_), do: {:error, :unsupported_scheme}

By routing the scheme string through parse_scheme/1, any scheme that is not explicitly defined as a hardcoded literal triggers an immediate {:error, :unsupported_scheme} response. This halts the connection attempt before invoking the adapter, completely preventing the allocation of untrusted strings into the global atom table.

Exploitation of CVE-2026-48597 requires that an attacker find a mechanism to pass arbitrary URLs to a Tesla HTTP client configured to use the Mint adapter. There are two primary avenues through which this can be achieved in production deployments: direct application-level input and HTTP redirection loops.

In the first vector, application-level inputs (such as webhook registration endpoints, URL preview generators, or document importers) allow users to supply a complete URL for the backend to query. An attacker can write an automation script that repeatedly calls these endpoints with uniquely generated schemes in the URL structure. For example, the attacker might send a series of POST requests with payloads like { "url": "scheme1://target" }, { "url": "scheme2://target" }, and so on, forcing the backend to allocate a new atom for every request.

In the second, more insidious vector, the attacker targets systems that have configured Tesla.Middleware.FollowRedirects in their request pipelines. When this middleware is active, Tesla automatically issues new requests to any URL specified in the Location header returned by remote servers. An attacker can host a lightweight malicious web server and direct the victim's application to send a single request to it. The malicious server then responds with an HTTP redirect status (such as 302 Found) and a custom Location header containing a randomized scheme, such as atk-983210://attacker.domain/. Tesla automatically parses this header and hands the redirect URL to the Mint adapter, which converts the custom scheme into a permanent atom.

This sequence of events is highly repeatable. Because there is no throttling or scheme validation within the redirect processor, a single script can cycle through hundreds of thousands of HTTP redirects over a short period. Once the threshold is crossed, the BEAM VM crashes instantly, causing a total Denial of Service.

The security impact of CVE-2026-48597 is classified as a complete loss of availability for the affected system, resulting in a CVSS v4.0 score of 8.2 (High). Because the BEAM VM operates as a unified OS process, the exhaustion of the global atom table does not merely terminate the current HTTP request or isolate the failure to a single supervision tree. Instead, the virtual machine terminates immediately, killing all concurrent operations, database connection pools, background workers, and web routing processes.

This vulnerability is particularly severe because the recovery mechanism for a system_limit crash requires a complete restart of the application container or virtual machine. If the application is not run under an external process manager (such as Systemd, Kubernetes, or Docker with a restart policy), the system will remain offline indefinitely. Even with an automatic restart mechanism, an attacker can continue to send malicious requests to exhaust the atom table immediately upon startup, creating a persistent, infinite loop of system crashes.

Furthermore, the attack requires absolutely zero authentication or privileges (PR:N) and minimal complexity (AC:L). There is no requirement for user interaction (UI:N), meaning the entire attack can be fully automated by external actors. The CVSS vector string 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 highlights that while there is no impact on confidentiality or integrity, the threat to availability is absolute.

The definitive remediation for CVE-2026-48597 is upgrading the tesla library to version 1.18.3 or later. This release incorporates the pattern-matching check in the Mint adapter that prevents dynamic atom allocation. Organizations using Elixir should update their mix.exs configuration file and run the dependency solver to apply the fix:

# mix.exs
defp deps do
  [
    {:tesla, "~> 1.18.3"}
  ]
end

If upgrading immediately is not feasible due to release cycles or legacy dependencies, temporary workarounds must be applied to prevent exploitation. The most effective workaround is to wrap all outbound HTTP calls in a validation layer that parses target URLs before passing them to the client. This validation step must explicitly reject any URL that does not begin with an approved, static scheme string:

defmodule SafeHttpClient do
  def request(method, url, body, headers, opts) do
    case URI.parse(url) do
      %URI{scheme: scheme} when scheme in ["http", "https"] ->
        Tesla.request(method: method, url: url, body: body, headers: headers, opts: opts)
      _ ->
        {:error, :unsupported_scheme}
    end
  end
end

Additionally, operations teams should monitor the BEAM VM atom usage using telemetry metrics. The atom table count can be queried at runtime via :erlang.system_info(:atom_count). Setting up alerts in monitoring systems like Prometheus when the atom count exceeds 80% of the maximum limit (:erlang.system_info(:atom_limit)) will provide early warning of an ongoing atom exhaustion attack before a catastrophic VM crash occurs.