CVE-2026-55735: Ueberauth Guardian DOS Vulnerability

CVE-2026-55735 Overview

CVE-2026-55735 is an improper cryptographic signature verification flaw [CWE-347] in the ueberauth/guardian authentication library for Elixir. The Guardian.revoke/3 function in lib/guardian.ex decodes tokens using peek/1, which base64-decodes the JWT header and payload without verifying the signature. An unauthenticated attacker can forge a JWT with a victim's jti and sub claims, sign it with any key, and submit it to any endpoint that funnels the token into Guardian.revoke/3. The result is an unauthenticated session-revocation denial of service against arbitrary users. The issue affects guardian from version 1.0.0 before 2.4.1.

Critical Impact
Attackers can revoke a victim's active session using a forged, unsigned JWT — no credentials, secrets, or prior authentication required.

Affected Products

ueberauth guardian>= 1.0.0
ueberauth guardian< 2.4.1
Elixir applications integrating GuardianDb-style whitelist or blacklist stores

Discovery Timeline

2026-08-01 - CVE-2026-55735 published to NVD
2026-08-06 - Last updated in NVD database

Technical Details for CVE-2026-55735

Vulnerability Analysis

The vulnerability lives in Guardian.revoke/3 inside lib/guardian.ex. Unlike the sibling operations refresh/2 and exchange/4, which both call decode_and_verify before acting on claims, revoke/3 calls peek/1. That helper only base64-decodes the JWT header and payload and performs no cryptographic verification. The unverified claims are then forwarded directly to the configured token module's revoke callback and to the implementation's on_revoke callback, which mutates state. This makes revoke/3 the only state-mutating path in Guardian that acts on unverified claims.

Root Cause

The root cause is missing signature verification in a state-mutating code path [CWE-347]. peek/1 was intended for read-only inspection of token contents but was used as the parsing primitive for revocation. Because the revocation implementation trusts identifying claims such as jti and sub to key into a whitelist or blacklist store, any caller who can supply those claim values can direct the mutation at another user's session.

Attack Vector

An attacker who knows or guesses a victim's jti and sub claim values crafts a JWT containing those claims and signs it with an arbitrary key. The attacker submits the forged token to any endpoint that forwards caller-supplied tokens into Guardian.revoke/3, typically the application's logout or session-revocation route. When the token module deletes the entry from a whitelist or inserts the entry into a blacklist (for example, a GuardianDb-backed store), the victim's legitimate session is evicted. The attacker never needs the signing secret.

text

@doc """
Revoke a token.

The token's signature is verified before any revocation callback is invoked,
so a token with an invalid signature is rejected and cannot be used to revoke
another session. Claim validation (such as expiry) is intentionally skipped so
that already expired tokens remain revocable.

Note: This is entirely dependent on the token module and callbacks.

### Lifecycle
"""

Source: ueberauth/guardian commit 2bd7a8c. The patch changes the revocation flow to verify the token's signature before invoking any revocation callback, while intentionally skipping claim validation such as expiry so already-expired tokens remain revocable.

Detection Methods for CVE-2026-55735

Indicators of Compromise

Unexpected logout or session-invalidation events for users who did not initiate a logout.
Successful requests to the application's logout or /revoke endpoint from IP addresses or user agents that do not match the victim's active session.
Entries in a GuardianDb-style whitelist being deleted, or blacklist entries being inserted, without a preceding authenticated request from the token owner.

Detection Strategies

Instrument the on_revoke callback to log the caller IP, request headers, and full claims of every token that reaches revocation, then alert on mismatches between the claim sub and the authenticated session identity.
Compare the JWT signature validity at the application layer against revocation events, and flag any revocation triggered by a token whose signature does not chain to a configured Guardian secret.
Correlate spikes in revocation events per user across short time windows to identify targeted session-eviction attempts.

Monitoring Recommendations

Forward Guardian revocation logs and web-tier access logs for logout and revoke endpoints to a centralized logging pipeline.
Alert on high rates of revocation events from a single source IP targeting distinct sub values.
Monitor GuardianDb store mutations and treat unauthenticated or signature-invalid revocations as high-severity events until patched.

How to Mitigate CVE-2026-55735

Immediate Actions Required

Upgrade guardian to version 2.4.1 or later in every Elixir application that exposes a logout or session-revocation endpoint.
Audit application code for any custom handler that funnels caller-supplied tokens into Guardian.revoke/3 and confirm the upgraded library is in use before redeploying.
Review recent revocation activity for suspicious patterns and consider forcing reauthentication for impacted users.

Patch Information

The fix is delivered in ueberauth/guardian commit 2bd7a8c29770d423d855c0a4965caa6c3e486901 and documented in GitHub Security Advisory GHSA-7975-hp3r-5qhv. The patch verifies the JWT signature before invoking the token module's revoke and on_revoke callbacks, while intentionally skipping claim validation such as expiry so already-expired tokens remain revocable. Fixed version: 2.4.1.

Workarounds

If immediate upgrade is not possible, wrap the revocation endpoint in a handler that calls Guardian.decode_and_verify/3 on the supplied token before passing it to Guardian.revoke/3, and reject requests whose signature fails to verify.
Restrict the logout or revocation endpoint to authenticated sessions and require the revoked token's sub to match the authenticated user's identity.
Rate-limit revocation attempts per source IP and per target sub to reduce mass session-eviction risk while the upgrade is scheduled.

bash

# Update the guardian dependency in mix.exs
# {:guardian, "~> 2.4.1"}
mix deps.update guardian
mix deps.get
mix compile