CVE-2026-55735 in guardian
Summary
by MITRE • 08/01/2026
Improper Verification of Cryptographic Signature in ueberauth guardian allows an unauthenticated attacker to revoke a victim's session with a forged token.
Guardian.revoke/3 in lib/guardian.ex decodes the supplied token with peek/1, which performs no signature verification (it only base64-decodes the JWT header and payload). The resulting unverified claims are forwarded directly to the configured token module's revoke callback and the implementation's on_revoke callback, a state-mutating sink. The sibling operations refresh/2 and exchange/4 both call decode_and_verify first, so the signature is checked before anything acts on the claims; revoke/3 is the only state-mutating path that acts on claims without verifying the signature.
An attacker who knows or guesses a victim's identifying claim values (jti, sub) can forge a JWT carrying those claims, sign it with an arbitrary key, and submit it to any endpoint that funnels a caller-supplied token into Guardian.revoke/3 (the standard logout / session-revocation pattern). When the token module mutates state keyed by the claims (whitelist deletion or blacklist insertion, for example a GuardianDb-style store), the victim's legitimate session is evicted. This is an unauthenticated session-revocation denial of service; the attacker never needs the signing secret.
This issue affects guardian: from 1.0.0 before 2.4.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/01/2026
The vulnerability described represents a critical cryptographic signature verification flaw in the ueberauth guardian authentication library that enables unauthorized session revocation attacks. This weakness specifically resides in the Guardian.revoke/3 function within lib/guardian.ex where the token decoding process bypasses essential signature validation checks. The implementation utilizes peek/1 to decode JWT tokens without performing any cryptographic signature verification, which creates a fundamental security gap that directly violates established cryptographic best practices and standards such as those outlined in CWE-327 for weak cryptography.
The technical execution of this vulnerability exploits the asymmetric behavior between different token operations within the guardian library. While refresh/2 and exchange/4 functions properly validate signatures through decode_and_verify before processing claims, the revoke/3 function operates as a state-mutating sink that accepts unverified claims directly. This design inconsistency creates an attack surface where malicious actors can construct forged JWT tokens containing legitimate identifying claim values such as jti (token identifier) and sub (subject), but signed with arbitrary private keys that are never verified against public keys or secrets. The resulting unverified claims are then passed to token module callbacks that perform state modifications, effectively allowing attackers to manipulate session state without authentication.
The operational impact of this vulnerability manifests as an authenticated session-revocation denial of service attack where attackers can forcibly terminate legitimate user sessions by submitting forged tokens containing victim's identifying information. This attack pattern represents a sophisticated form of session hijacking or session termination that does not require knowledge of the actual signing secrets, making it particularly dangerous because attackers can exploit this weakness even when they cannot directly access the system's cryptographic keys. The vulnerability affects all versions of guardian from 1.0.0 through 2.4.0, creating a widespread exposure across numerous applications relying on this authentication framework.
Security implications extend beyond simple denial of service to encompass potential privilege escalation and authorization bypass scenarios, particularly in systems where session state manipulation can affect access control decisions. The ATT&CK framework categorizes this as a credential exposure and privilege escalation technique, where attackers exploit trust relationships between components to modify system state without proper authorization. Organizations using guardian versions within the affected range face significant risk of unauthorized session termination, which can disrupt legitimate user workflows and potentially create opportunities for more sophisticated attacks if session management is tightly coupled with access control decisions. Mitigation strategies should focus on immediate library version upgrades to 2.4.1 or later, implementation of signature verification checks in custom token modules, and consideration of additional authentication layers that do not rely solely on token state manipulation for session control.
This vulnerability demonstrates the critical importance of cryptographic consistency across all API endpoints within security libraries and highlights how a single missing verification step can create significant operational security risks. The issue fundamentally undermines the security model of the guardian library by creating an unauthenticated path to state modification, where attackers can effectively impersonate legitimate users in terms of session management operations without possessing legitimate credentials or access to cryptographic keys.