EUVD-2026-54531
GHSA-cvf2-gh5f-v69p
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/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
Network-accessible with no authentication or complexity barrier; impact is availability-only with no scope change, as the crash is self-contained to the affected application node.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
3DescriptionCVE.org
Allocation of Resources Without Limits or Throttling vulnerability in DivvyPayHQ absinthe_federation allows an unauthenticated remote attacker to abort the Erlang VM via crafted _entities representation keys.
Every key of every object in the representations argument of the federation-mandated _entities field is converted with String.to_atom/1 by convert_key/2 in lib/absinthe/federation/schema/entities_field.ex. representations is typed as the open-ended _Any scalar, so its keys bypass schema coercion and the attacker names them freely. Atoms are never garbage collected and the BEAM atom table is hard-capped (about 1,048,576 entries by default), so one request carrying tens of thousands of unique keys creates that many permanent atoms and a handful of such requests exhausts the table and aborts the node. The impact is confined to availability: no data is read or altered, and recovery requires restarting the application.
This issue affects absinthe_federation: from 0.1.0 before 0.9.3.
AnalysisAI
Unauthenticated remote denial-of-service in absinthe_federation 0.1.0-0.9.2 allows an attacker to permanently exhaust the BEAM (Erlang VM) atom table and crash the application node by sending crafted GraphQL _entities queries with large numbers of unique representation keys. The convert_key/2 function in entities_field.ex unconditionally calls String.to_atom/1 on all client-supplied keys, bypassing schema coercion through the open-ended _Any scalar; since BEAM atoms are never garbage collected and the atom table is hard-capped at approximately 1,048,576 entries, a handful of requests carrying tens of thousands of unique keys exhausts the table and aborts the node. No public exploit code or CISA KEV listing exists at time of analysis, but the attack mechanism is well-understood in the Erlang ecosystem and trivially automatable.
Technical ContextAI
absinthe_federation is an Elixir library extending the Absinthe GraphQL framework to implement Apollo Federation's _entities field. The root cause is in lib/absinthe/federation/schema/entities_field.ex where convert_key/2 applies String.to_atom/1 to every key in the representations argument. Because representations is typed as the _Any scalar - an open-ended JSON-like value - its keys bypass Absinthe's schema coercion and field validation, allowing arbitrary client-controlled strings to reach the atom converter. In the BEAM (Erlang/OTP virtual machine), atoms are immutable global identifiers stored in a process-wide atom table that is never garbage collected; the default hard cap is 1,048,576 entries, configurable only at VM startup via the +t flag. CWE-770 (Allocation of Resources Without Limits or Throttling) captures the root cause precisely: there is no guard, rate limit, or allow-list applied before conversion. CPE cpe:2.3:a:divvypayhq:absinthe_federation identifies the affected package across all versions from 0.1.0 onward.
RemediationAI
Upgrade to absinthe_federation 0.9.3, which is the vendor-released patch for this issue. The fix replaces String.to_atom/1 with String.to_existing_atom/1 wrapped in a rescue ArgumentError block in convert_key/2: only atoms already resident in the BEAM atom table at compile time (i.e., valid schema field names) are produced, and unknown client-supplied keys pass through as strings rather than being converted. The patch commit is at https://github.com/DivvyPayHQ/absinthe_federation/commit/c3838cda2a7f65c4893291668c223b0d6acf4516 and the advisory at https://github.com/DivvyPayHQ/absinthe_federation/security/advisories/GHSA-55hv-mwvr-phf3. If immediate upgrade is not feasible, deploy a WAF or API gateway in front of the GraphQL endpoint to enforce request payload size limits and per-client request rate limits, which significantly raises the cost of atom table exhaustion but does not eliminate the root cause and should be treated as a temporary measure only. Raising the BEAM atom table limit via the +t VM flag (e.g., +t 2097152) similarly delays exhaustion but does not fix the vulnerability. Disabling the _entities field would fully remediate the issue at the cost of breaking Apollo Federation functionality entirely.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today