CVE-2026-32688
Atom Table Exhaustion DoS in plug_cowboy via HTTP/2 Scheme
Publication date: 2026-04-27
Last updated on: 2026-04-27
Assigner: EEF
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| elixir-plug | plug_cowboy | From 2.0.0 (inc) to 2.8.1 (exc) |
Helpful Resources
Exploitability
| 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-32688 is a high-severity denial-of-service vulnerability in the Elixir library plug_cowboy, specifically in the Plug.Cowboy.Conn.conn/1 function.
The vulnerability occurs because the function converts the client-supplied HTTP/2 :scheme pseudo-header value directly into an atom using String.to_atom/1 without validation.
Each unique :scheme value creates a permanent entry in the Erlang VM's atom table, which has a fixed size and does not support garbage collection.
An attacker can exploit this by sending many HTTP/2 requests with unique :scheme values, exhausting the atom table and causing the Erlang VM to crash with a system_limit error, resulting in a denial of service.
This issue does not affect HTTP/1.1 connections because the scheme is derived from the listener type rather than client input.
The vulnerability affects plug_cowboy versions from 2.0.0 up to but not including 2.8.1.
How can this vulnerability impact me? :
This vulnerability can cause a remote denial of service by crashing the entire Erlang VM running plug_cowboy.
An unauthenticated attacker can exploit it remotely by sending crafted HTTP/2 requests with unique :scheme values to exhaust the atom table.
The impact is a loss of availability, as the Erlang VM aborts and the node goes down, potentially causing service outages.
There is no impact on confidentiality or integrity.
Systems exposing HTTP/2 endpoints directly without a proxy are vulnerable; if a proxy translates HTTP/2 to HTTP/1.1 internally, the risk is mitigated.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusual or excessive HTTP/2 requests with unique :scheme pseudo-header values that cause atom table exhaustion in the Erlang VM. Signs include the Erlang VM aborting with a system_limit error and the node crashing.
Since the vulnerability involves HTTP/2 requests with varying :scheme values, network monitoring tools or logs can be inspected for many unique :scheme headers in HTTP/2 traffic to the Plug.Cowboy HTTPS listener.
Specific commands are not provided in the resources, but general approaches include:
- Using packet capture tools (e.g., tcpdump or Wireshark) to filter HTTP/2 traffic and analyze :scheme pseudo-header values.
- Checking Erlang VM logs for system_limit errors or crashes indicating atom table exhaustion.
- Monitoring application logs for repeated crashes or denial of service symptoms related to Plug.Cowboy.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading plug_cowboy to version 2.8.1 or later, where the vulnerability has been fixed by explicitly mapping scheme strings to atoms instead of dynamically creating atoms.
If upgrading immediately is not possible, a recommended workaround is to disable HTTP/2 on the Plug.Cowboy HTTPS listener by setting the cowboy option protocol_options to %{protocols: [:http]}, which restricts the listener to HTTP/1.1 and avoids the vulnerable code path.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability causes a denial-of-service (DoS) condition by exhausting the Erlang VM's atom table, leading to a crash of the entire node. The primary impact is on system availability.
There is no indication from the provided information that this vulnerability affects confidentiality or integrity of data.
Since common standards and regulations like GDPR and HIPAA emphasize the protection of personal data confidentiality, integrity, and availability, this vulnerability impacts the availability aspect.
A denial-of-service event could lead to non-compliance with availability requirements in these regulations, potentially causing service outages that affect users' access to data or services.
However, there is no direct mention of data breach or unauthorized data access, so the vulnerability does not directly compromise data privacy or security controls required by such standards.