CVE-2026-48597
Received Received - Intake
Denial of Service via Atom Table Exhaustion in Tesla

Publication date: 2026-06-02

Last updated on: 2026-06-02

Assigner: EEF

Description
Allocation of Resources Without Limits or Throttling vulnerability in elixir-tesla tesla allows denial of service via atom table exhaustion in Tesla.Adapter.Mint. Tesla.Adapter.Mint.open_conn/2 converts the URL scheme of every outgoing request to a BEAM atom via String.to_atom(uri.scheme) with no allow-list validation. BEAM atoms are never garbage-collected and the atom table is bounded (approximately 1,048,576 entries by default). An attacker who can influence the URL of a Tesla request β€” either via an application-level URL-forwarding feature (webhook, proxy, importer) or via a Location header returned by a server when Tesla.Middleware.FollowRedirects is in the pipeline β€” can mint one fresh permanent atom per request by varying the scheme string. After enough requests the atom table fills and the VM crashes, taking down the entire application. This issue affects tesla: from 1.3.0 before 1.18.3.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-02
Last Modified
2026-06-02
Generated
2026-06-03
AI Q&A
2026-06-02
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
elixir-tesla tesla to 1.18.3 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-770 The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-48597 is a vulnerability in the elixir-tesla library, specifically in the Tesla.Adapter.Mint module, that allows denial of service via atom table exhaustion.

The vulnerability occurs because the function Tesla.Adapter.Mint.open_conn/2 converts the URL scheme of every outgoing request into a BEAM atom using String.to_atom(uri.scheme) without validating the scheme against an allow-list.

Since BEAM atoms are permanent and never garbage-collected, and the atom table has a fixed size (about 1,048,576 entries), an attacker who can influence the URL scheme can cause the creation of many new atoms.

By sending requests with varying URL schemes, the attacker can exhaust the atom table, causing the Erlang VM to crash and taking down the entire application.

This can be exploited if the attacker can influence the URL of a Tesla request, for example through application-level URL-forwarding features like webhooks, proxies, importers, or via Location headers when Tesla.Middleware.FollowRedirects is used.


How can this vulnerability impact me? :

This vulnerability can lead to a denial of service (DoS) condition by crashing the Erlang VM that runs the application using the Tesla library.

An attacker can cause the application to become unavailable by exhausting the atom table through repeated requests with varying URL schemes.

The crash of the VM means the entire application stops functioning, potentially causing downtime and loss of service.

Exploitation requires no authentication or special privileges, only the ability to send crafted requests to the application's HTTP endpoints.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves exhaustion of the BEAM atom table caused by untrusted URL schemes being converted to atoms without validation. Detection involves monitoring for unusual or excessive creation of atoms or crashes of the Erlang VM due to atom table exhaustion.

You can detect potential exploitation by observing application logs for repeated crashes or errors related to atom table limits. Additionally, monitoring network traffic for requests with unusual or varying URL schemes that could trigger atom creation is recommended.

Specific commands are not provided in the available resources, but general approaches include:

  • Checking Erlang VM logs for atom table exhaustion errors.
  • Using telemetry or monitoring tools to track the number of atoms in use (e.g., via :erlang.system_info(:atom_count) in an Erlang shell).
  • Inspecting network traffic for requests with unusual URL schemes that could be used to create new atoms.

What immediate steps should I take to mitigate this vulnerability?

The primary mitigation step is to upgrade the Tesla library to version 1.18.3 or later, where the vulnerability has been fixed by validating URL schemes before converting them to atoms.

Until the upgrade can be applied, consider the following immediate actions:

  • Disable or restrict features that allow untrusted input to influence URL schemes in Tesla requests, such as URL-forwarding features (webhooks, proxies, importers) or middleware like Tesla.Middleware.FollowRedirects.
  • Implement input validation or sanitization on URLs before they reach Tesla to prevent arbitrary scheme strings.
  • Monitor application behavior for signs of atom table exhaustion and be prepared to restart the VM if necessary.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart