ueberauth Guardian EUVD-2026-51916

Exploitation requires two co-present conditions: (1) the target application must explicitly opt into Guardian.Permissions.AtomEncoding via use Guardian.Permissions, encoding: Guardian.Permissions.AtomEncoding - a non-default, code-level configuration choice absent from standard Guardian installations; and (2) externally controlled input (JWT permission scope claims, HTTP request body fields, or any other attacker-influenced data) must flow into Guardian.Permissions.encode/3 without prior validation against the known permission set. The default Guardian.Permissions.BitwiseEncoding is completely unaffected. Based on the PR:N metric in the CVSS 4.0 vector, no authentication is required; any endpoint processing incoming tokens and routing them through encode/3 is exploitable by unauthenticated callers. The primary limiting factor is the non-default encoder configuration, which substantially narrows the exposed population to applications that deliberately opted in to AtomEncoding.

The vendor-assigned CVSS 4.0 score of 6.9 with AT:P (Attack Requirements: Present) correctly reflects the non-default configuration prerequisite. However, the provided vector's AV:L (Local) appears inconsistent with the described attack surface - JWT claims and HTTP request bodies are network-delivered inputs, suggesting AV:N is the more accurate attack vector; this metric discrepancy should be verified with the vendor. AT:P appropriately captures the opt-in AtomEncoding configuration constraint. No EPSS score or CISA KEV listing is present in the available data, so exploitation probability cannot be quantified; however, the attack is conceptually trivial to automate once the attack surface is understood. Real-world priority is moderate-to-high for the affected subset: the vast majority of Guardian deployments use BitwiseEncoding and are entirely unexposed, significantly narrowing the vulnerable population. For applications that did opt into AtomEncoding and accept external permission scopes, this is a high-priority, availability-critical issue with no authentication barrier, no user-interaction requirement, and a broad blast radius because a BEAM crash terminates all co-resident applications simultaneously.

An unauthenticated attacker targets a Phoenix application endpoint that processes incoming JWTs with permission scope claims. The attacker submits a continuous stream of requests, each JWT carrying a unique, previously unseen scope string. Because the application uses AtomEncoding, every distinct string permanently consumes one BEAM atom slot; after roughly one million unique submissions - achievable with a trivial script within minutes on a reasonable network - the atom table overflows, the BEAM raises system_limit, and the entire node crashes, taking down all co-hosted applications.