Which versions of Elixir Tesla are affected by CVE-2026-48597?

The Elixir Tesla HTTP client library (versions 1.3.0-1.18.2) contains a denial-of-service vulnerability that can completely crash application servers if they use specific adapter configurations and…. A patch is available.

Is there a public PoC exploit available for CVE-2026-48597?

Yes, a public proof-of-concept exploit is available for CVE-2026-48597. Prioritise patching immediately. EPSS: 0.0%.

How to fix or mitigate CVE-2026-48597?

Within 24 hours: Identify all systems using Elixir Tesla library versions 1.3.0-1.18.2 and determine if they use the Mint adapter configuration. Within 7 days: Apply vendor patch by upgrading Tesla to the patched version per vendor advisory. Within 30 days: Verify patched version deployment and implement controls restricting URL inputs to trusted, pre-defined values.

Elixir Tesla CVE-2026-48597

Q: What is the CVSS score of CVE-2026-48597?

CVE-2026-48597 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-34013 HIGH

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-06-02 EEF

GHSA-h74c-q9j7-mpcm

Denial Of Service Tesla

8.2

CVSS 4.0 · Vendor: EEF

Severity by source

Vendor (EEF) PRIMARY

8.2 HIGH

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from Vendor (EEF) · only source for this CVE.

CVSS VectorVendor: EEF

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jun 02, 2026 - 20:26 vuln.today

Analysis Generated

Jun 02, 2026 - 20:26 vuln.today

CVSS changed

Jun 02, 2026 - 20:22 NVD

8.2 (HIGH)

DescriptionCVE.org

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.

AnalysisAI

Denial of service in the Elixir Tesla HTTP client (versions 1.3.0 through 1.18.2) when using the Tesla.Adapter.Mint adapter allows remote attackers to crash the entire BEAM VM by exhausting the atom table. Each request whose URL scheme is attacker-controlled mints a fresh, never-garbage-collected atom via String.to_atom/1, and after roughly 1,048,576 such requests the VM terminates. No public exploit identified at time of analysis, but the upstream fix and a regression test that asserts no atoms are minted for unknown schemes are both publicly visible on GitHub.

Technical ContextAI

Tesla is a widely used HTTP client library for Elixir that supports multiple pluggable adapters; the affected code path is in Tesla.Adapter.Mint.open_conn/2, which wraps the Mint low-level HTTP library. The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling) realized via an Erlang/BEAM-specific quirk: atoms created with String.to_atom/1 are permanent for the life of the VM and the global atom table is capped at approximately 1,048,576 entries by default (controlled by the +t emulator flag). The pre-patch code called String.to_atom(uri.scheme) on every outgoing request with no allow-list, so any caller able to influence the scheme portion of a URI passed to Tesla could mint arbitrary new atoms. The fix introduces a private parse_scheme/1 function that pattern-matches only the literal strings "http" and "https" to the existing atoms :http and :https, returning {:error, :unsupported_scheme} otherwise. Affected CPE is cpe:2.3:a:elixir-tesla:tesla:*.

RemediationAI

Vendor-released patch: Tesla 1.18.3, which replaces the unrestricted String.to_atom(uri.scheme) call with an allow-list parse_scheme/1 helper that maps only "http" and "https" to existing atoms and returns {:error, :unsupported_scheme} for everything else (patch commit https://github.com/elixir-tesla/tesla/commit/4699c3cb3e2fd6078f99f45f11cf7466aeedbf0e); upgrade the tesla dependency in mix.exs to ~> 1.18.3 and redeploy. If immediate upgrade is not possible, the most effective workarounds are switching the adapter to one that is not affected (for example Tesla.Adapter.Hackney or Tesla.Adapter.Finch), validating and allow-listing URL schemes before passing user-influenced URLs to Tesla, and disabling Tesla.Middleware.FollowRedirects on pipelines that contact untrusted hosts so that malicious Location headers cannot smuggle in arbitrary schemes. As a defence-in-depth measure operators can raise the BEAM atom limit via the +t emulator flag, which delays but does not prevent exhaustion and increases memory consumption, so this should be paired with one of the above fixes rather than used alone.