CVE-2026-55735

CVE-2026-55735 is an improper signature-verification flaw (CWE-347) in Guardian, the ueberauth JWT authentication library for Elixir/Phoenix: Guardian.revoke/3 in lib/guardian.ex decodes the caller-supplied token with peek/1, which only base64-decodes the JWT header and payload without checking the signature, and passes the unverified claims straight to the token module's revoke and on_revoke callbacks, which mutate state. Unlike the sibling operations refresh/2 and exchange/4, which call decode_and_verify first, revoke/3 is the only state-mutating path that acts on claims without verifying the signature. An unauthenticated attacker who knows or guesses a victim's identifying claim values (jti, sub) can forge a JWT carrying those claims, sign it with any key, and submit it to any endpoint that feeds caller-supplied tokens into Guardian.revoke/3 (the standard logout/session-revocation pattern), causing a state-mutating token store such as a GuardianDb-style whitelist/blacklist to delete or blacklist the victim's legitimate session. The attacker gains an unauthenticated denial of that victim's session (forced eviction) without ever needing the signing secret; confidentiality and integrity are unaffected, consistent with the CVSS 4.0 score of 8.2 (high) with high availability impact only. Applications running Guardian versions from 1.0.0 before 2.4.1 are affected, and practically only those that expose endpoints funneling caller-supplied tokens into revoke/3 and use a stateful token store keyed on claims; no in-the-wild exploitation is currently known (not in CISA KEV), EPSS puts the 30-day exploitation probability at 0.3% (27th percentile), and one public reference (the GitHub security advisory GHSA-7975-hp3r-5qhv) is available.

What to do: Upgrade guardian to 2.4.1 or later. Until upgraded, audit any endpoint that passes caller-supplied tokens into Guardian.revoke/3 (typically logout/revoke routes), verify token signatures before revocation (e.g., run Guardian's decode_and_verify on the token first) or restrict those endpoints to authenticated callers. Prioritize applications using a state-mutating token store (GuardianDb-style whitelist/blacklist), since stateless configurations have no stored session state for the attacker to evict.