ueberauth Guardian EUVD-2026-51914

Exploitation requires three concurrent conditions: (1) the application runs Guardian 1.0.0-2.4.0 with a persistent, claim-keyed token store - any token module whose revoke callback mutates state keyed by jti or sub, such as GuardianDb; (2) the application exposes an endpoint that accepts a caller-supplied token and passes it to Guardian.revoke/3, which is the standard logout/session-revocation pattern; and (3) the attacker can determine the victim's JWT sub (user identifier) or jti (token identifier) - through enumeration, prior token exposure, or public profile data. Applications that do not persist revocation state (stateless JWT validation only) are not vulnerable because the revoke callback has no durable side effect to exploit. No authentication is required; exploitation is entirely unauthenticated and does not grant access to the victim's account - the impact is limited to forced session termination.

The CVSS 4.0 base score of 8.2 with vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H correctly characterizes this as a high-availability-impact, network-accessible flaw requiring no privileges or user interaction. The AT:P (partial attack requirements) modifier acknowledges a real prerequisite: the attacker must know or enumerate the victim's JWT claim values (sub, jti); jti is typically a UUID and is difficult to guess without prior token exposure, while sub is often a user ID or email that may be enumerable from public surfaces. Impact is strictly limited to availability - forcible session expiry - with no confidentiality or integrity compromise; the attacker cannot impersonate the victim or read session content. No CISA KEV listing exists and no public POC code has been identified, meaning exploitation remains theoretical at this time. However, the attack is mechanically trivial for any attacker who has obtained claim values through prior reconnaissance, intercepted JWTs, or enumerable sub values. Organizations using GuardianDb or equivalent persistent stores should treat this as an urgent upgrade given the complete lack of required privileges.

An attacker who knows or infers a target user's JWT sub claim (for example, by knowing their account email or user ID from a public profile or prior data exposure) constructs a forged JWT payload containing that sub and an arbitrary jti, signs it with a self-generated key, and submits it to the application's standard logout endpoint. The endpoint calls Guardian.revoke/3 with the forged token; peek/1 extracts the attacker-controlled claims without signature verification, and those claims are forwarded to the GuardianDb revocation callback, which deletes the victim's active session record. On their next authenticated request the victim receives an authorization error and is forced to re-authenticate, constituting a repeatable, targeted session-eviction denial-of-service.