CVE-2026-48597 in tesla
Summary
by MITRE • 06/03/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 06/04/2026
The vulnerability described represents a critical resource allocation flaw in the elixir-tesla tesla library that manifests as a denial of service condition through atom table exhaustion. This issue specifically impacts the Tesla.Adapter.Mint module where the open_conn/2 function processes URL schemes by converting them to BEAM atoms using String.to_atom(uri.scheme) without any validation or sanitization measures. The fundamental problem lies in the immutable nature of BEAM atoms which remain resident in memory until the entire virtual machine terminates, creating a persistent resource leak that can be exploited by malicious actors. The vulnerability is particularly dangerous because it operates at the core of the HTTP client implementation where every request processing cycle can potentially introduce new permanent atoms into the system's atom table.
The technical execution of this vulnerability requires an attacker to control or influence the URL scheme of outgoing requests, which can be achieved through multiple attack vectors including application-level URL forwarding mechanisms such as webhooks, proxy configurations, or server-side redirects that return Location headers. When Tesla.Middleware.FollowRedirects is enabled in the request pipeline, the system automatically follows redirects and processes the scheme of each redirected URL, creating a continuous stream of atom allocations. The attack is particularly effective because the atom table has a finite size limit of approximately 1,048,576 entries by default, and each malicious request consumes one entry permanently. This creates a straightforward path to system failure where an attacker can systematically exhaust the atom table through repeated requests with varying scheme strings, leading to immediate VM crashes and complete application downtime.
This vulnerability directly maps to CWE-772 which describes insufficient resource management where a resource is not properly limited or controlled, and aligns with ATT&CK technique T1499.004 which covers network denial of service attacks through resource exhaustion. The impact extends beyond simple service disruption to encompass complete application failure and potential data loss, as the VM crash typically results in the termination of all running processes within that environment. The vulnerability affects versions of the tesla library from 1.3.0 through 1.18.2, representing a significant window of exposure where applications using this library were vulnerable to this specific form of resource exhaustion attack. The flaw demonstrates poor adherence to secure coding practices regarding resource management and input validation, as the system fails to implement basic bounds checking or sanitization of user-controllable data before processing it into permanent system resources.
The recommended mitigation strategy involves implementing input validation and sanitization for URL schemes before atom conversion, specifically by establishing a whitelist of allowed schemes or by implementing proper bounds checking on atom table usage. The fix should modify the Tesla.Adapter.Mint.open_conn/2 function to validate that incoming scheme strings conform to expected patterns before invoking String.to_atom, or alternatively implement a mechanism to monitor and limit atom table growth. Additionally, applications should consider implementing rate limiting or request throttling mechanisms to prevent rapid consumption of atom table entries. The most effective long-term solution involves replacing direct String.to_atom calls with safer alternatives such as using atoms from a predefined set or implementing proper resource accounting to prevent unbounded growth of system resources. Organizations should also conduct thorough code reviews to identify similar patterns in their codebase where direct atom conversion occurs without proper validation, as this vulnerability represents a common anti-pattern in BEAM-based systems that can lead to similar resource exhaustion conditions.