CVE-2026-55735 is a high severity signature verification flaw in ueberauth Guardian, the Elixir authentication library. Guardian.revoke/3 acts on token claims without checking the signature, so a forged token can evict a victim's session. Versions from 1.0.0 before 2.4.1 are affected. Upgrade to 2.4.1.
What's affected
- Product: ueberauth guardian (Hex package
guardian). - Affected: from 1.0.0 up to, but not including, 2.4.1.
- Fixed: 2.4.1, according to the record and the Erlang Ecosystem Foundation CNA entry.
- Exposure depends on your code: only applications that pass a caller-supplied token to
Guardian.revoke/3, which is the usual logout pattern, can be abused.
How to check if you're exposed
Check which Guardian version your application locks.
grep -A2 '"guardian"' mix.lock
mix deps | grep -A3 guardian
Then search your code for calls to Guardian.revoke, and for wrappers around it such as a logout controller action. If the token reaches revoke/3 straight from a request header or body, the endpoint is reachable by anyone who can send a request.
The advisory also notes that a token store matters. When the token module changes state keyed by the claims, for example removing an entry from a whitelist or adding one to a blacklist, the legitimate session is the one that gets removed.
What to do now
- Upgrade Guardian to 2.4.1 or later and run your test suite, paying attention to logout and token revocation tests.
- If you cannot upgrade today, apply the workaround from the CNA entry: verify the token before revoking it, by calling
decode_and_verify(or an equivalent) first and only revoking when it succeeds. - Review other places where your code decodes tokens with
peek, since that function reads claims without verifying the signature. - Make session identifiers hard to guess. The attack needs the victim's
jtiandsubvalues, so predictable identifiers make it easier. - Run the free in-browser dependency scan on your lockfile or manifest to see every affected package in one pass.
Why it matters
The weakness is CWE-347 (Improper Verification of Cryptographic Signature). Guardian.revoke/3 read the token with peek/1, which only base64 decodes the header and payload. The sibling operations refresh/2 and exchange/4 call decode_and_verify first, so revoke/3 was the one state changing path that trusted claims it had not verified.
The impact is limited to availability of a user's session. The attacker does not need the signing secret and does not read data, but can sign out other users on demand if they know or guess identifying claim values. The record scores it 7.5 (High). The Erlang Ecosystem Foundation CNA page lists it as 8.2 (High), so the two sources disagree on the number while agreeing on the severity band. The record does not mark it as exploited in the wild.
Try it yourself
An inventory of your dependencies is the fastest way to learn whether Guardian is in your tree at all, and at which version.
Click through it at your own pace, or open it full screen.
Quick check
Does the attacker need the signing secret?
No. The record says the attacker never needs the signing secret. The forged token only has to carry the victim's identifying claims, because revoke/3 did not verify the signature.
Sources
- Erlang Ecosystem Foundation CNA entry
- Fix commit in ueberauth/guardian
- GitHub advisory GHSA-7975-hp3r-5qhv
Last reviewed: 18 October 2026.
