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.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| ueberauth | guardian | unaffected |
|
||||||
| ueberauth | guardian | unaffected |
|
No data.
No data.
No data available yet.
Vendor Workaround
Verify the token before revoking it: call decode_and_verify (or a verify-without-expiry variant, so already-expired tokens remain revocable) on the caller-supplied token and pass only tokens whose signature validates into Guardian.revoke/3. Reject tokens with an invalid signature at the application boundary.
Tracking
Sign in to view the affected projects.
No advisories yet.
Sat, 01 Aug 2026 19:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Guardian.revoke/3 acts on unverified token claims, allowing forged-token session revocation | |
| First Time appeared |
Ueberauth
Ueberauth guardian |
|
| Weaknesses | CWE-347 | |
| CPEs | cpe:2.3:a:ueberauth:guardian:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Ueberauth
Ueberauth guardian |
|
| References |
| |
| Metrics |
cvssV4_0
|
MITRE
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-08-01T18:46:05.234Z
Reserved: 2026-06-17T10:44:34.365Z
Link: CVE-2026-55735
Vulnrichment
No data.
NVD
No data.
Redhat
No data.
OpenCVE Enrichment
No data.
-
CWE-347
Improper Verification of Cryptographic Signature