ueberauth Guardian EUVD-2026-51917

Exploitation requires that the target application passes a permissions map containing at least one key with an integer value to encode_permissions!/1 or encode_permissions_into_claims!/2, and that the keys of that map are at least partially controlled by the attacker. The critical enabling condition is the integer-value code path in do_encode_permissions!/2: only keys whose values are integers bypass the existing validation and proceed directly to String.to_atom/1 without an allowlist check. Applications that exclusively pass statically constructed, server-side permission maps with atom or string keys from a known set are not exploitable, because those keys would already exist in the atom table. What limits exploitation: the application must be using the Guardian.Permissions mixin and must have an externally reachable code path that feeds attacker-influenced keys with integer values into encode_permissions!/1; the CVSS 4.0 AT:P metric reflects this prerequisite. The CVSS 4.0 PR:N indicates no authentication is required at the Guardian level once the endpoint is reachable, but the endpoint itself may have its own authentication controls depending on the application.

The provided CVSS 4.0 base score of 6.9 with vector AV:L/AC:L/AT:P/PR:N/UI:N reflects a moderate-severity finding, but the AV:L (local) designation warrants scrutiny: the CVE description explicitly cites a network-accessible path ('a permissions map read from a request body and passed into token issuance via encode_permissions_into_claims!/2'), which would normally map to AV:N. The AT:P (attack requirements present) metric correctly captures the prerequisite that the application must pass externally influenced data to encode_permissions!/1 - not all Guardian deployments will do this. The practical risk therefore depends heavily on whether a given application exposes an endpoint that feeds user-controlled keys into token issuance. Where such an endpoint exists, the attack is straightforward and automatable: any number of unique string keys per request permanently consumes atom slots, and approximately one million unique requests suffice to crash a default-configured BEAM node. The impact is catastrophic for availability (VA:H, SA:H) because the BEAM process model means a single crashed VM takes down every service, GenServer, or Supervisor tree running on that node. No EPSS score is provided; no KEV listing exists. The low attack complexity once the prerequisite is met, the zero-privilege requirement, and the catastrophic blast radius make this a genuine priority for applications that pass user-supplied permission maps into Guardian token issuance, despite the moderate aggregate CVSS score.

An attacker identifies a Phoenix or Plug endpoint that reads a permissions map from the JSON request body and passes it directly into Guardian.encode_permissions_into_claims!/2 during token issuance. The attacker sends a high volume of POST requests, each containing a permissions map with hundreds of previously unseen string keys as the permission-set names. Each unique key causes Guardian to call String.to_atom/1, permanently consuming one BEAM atom-table slot. After roughly one million total unique keys have been submitted - achievable in minutes from a fast client - the BEAM node's atom table is exhausted, the VM crashes with an atom limit error, and the entire application including any background workers, schedulers, and co-hosted services becomes unavailable.