{"containers":{"cna":{"affected":[{"collectionURL":"https://repo.hex.pm","cpes":["cpe:2.3:a:ueberauth:guardian:*:*:*:*:*:*:*:*"],"defaultStatus":"unaffected","modules":["'Elixir.Guardian'"],"packageName":"guardian","packageURL":"pkg:hex/guardian","product":"guardian","programFiles":["lib/guardian.ex"],"programRoutines":[{"name":"'Elixir.Guardian':revoke/3"}],"repo":"https://github.com/ueberauth/guardian","vendor":"ueberauth","versions":[{"lessThan":"2.4.1","status":"affected","version":"1.0.0","versionType":"semver"}]},{"collectionURL":"https://github.com","cpes":["cpe:2.3:a:ueberauth:guardian:*:*:*:*:*:*:*:*"],"defaultStatus":"unaffected","modules":["'Elixir.Guardian'"],"packageName":"ueberauth/guardian","packageURL":"pkg:github/ueberauth/guardian","product":"guardian","programFiles":["lib/guardian.ex"],"programRoutines":[{"name":"'Elixir.Guardian':revoke/3"}],"repo":"https://github.com/ueberauth/guardian","vendor":"ueberauth","versions":[{"lessThan":"2bd7a8c29770d423d855c0a4965caa6c3e486901","status":"affected","version":"d65227145f72b290106c06cecbe42728fbf05fe2","versionType":"git"}]}],"configurations":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<p>The application must route a caller-supplied token into <tt>Guardian.revoke/3</tt> (for example a logout or session-revocation endpoint) and use a token module whose <tt>revoke</tt> / <tt>on_revoke</tt> callback mutates state keyed by the token claims (a whitelist that deletes by <tt>jti</tt> or a blacklist that inserts by <tt>jti</tt>, such as a GuardianDb-style store). With the default no-op <tt>on_revoke</tt> callback, no session state is changed and the issue is not exploitable.</p>"}],"value":"The application must route a caller-supplied token into Guardian.revoke/3 (for example a logout or session-revocation endpoint) and use a token module whose revoke / on_revoke callback mutates state keyed by the token claims (a whitelist that deletes by jti or a blacklist that inserts by jti, such as a GuardianDb-style store). With the default no-op on_revoke callback, no session state is changed and the issue is not exploitable."}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:a:ueberauth:guardian:*:*:*:*:*:*:*:*","versionEndExcluding":"2.4.1","versionStartIncluding":"1.0.0","vulnerable":true}],"negate":false,"operator":"OR"}]}],"credits":[{"lang":"en","type":"finder","value":"Peter Ullrich"},{"lang":"en","type":"remediation developer","value":"Yordis Prieto"},{"lang":"en","type":"analyst","value":"Jonatan Männchen / EEF"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<p>Improper Verification of Cryptographic Signature in ueberauth guardian allows an unauthenticated attacker to revoke a victim's session with a forged token.</p><p><tt>Guardian.revoke/3</tt> in <tt>lib/guardian.ex</tt> decodes the supplied token with <tt>peek/1</tt>, 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 <tt>revoke</tt> callback and the implementation's <tt>on_revoke</tt> callback, a state-mutating sink. The sibling operations <tt>refresh/2</tt> and <tt>exchange/4</tt> both call <tt>decode_and_verify</tt> first, so the signature is checked before anything acts on the claims; <tt>revoke/3</tt> is the only state-mutating path that acts on claims without verifying the signature.</p><p>An attacker who knows or guesses a victim's identifying claim values (<tt>jti</tt>, <tt>sub</tt>) 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 <tt>Guardian.revoke/3</tt> (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.</p><p>This issue affects guardian: from 1.0.0 before 2.4.1.</p>"}],"value":"Improper Verification of Cryptographic Signature in ueberauth guardian allows an unauthenticated attacker to revoke a victim's session with a forged token.\n\nGuardian.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.\n\nAn 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.\n\nThis issue affects guardian: from 1.0.0 before 2.4.1."}],"impacts":[{"capecId":"CAPEC-475","descriptions":[{"lang":"en","value":"CAPEC-475 Signature Spoofing by Improper Validation"}]}],"metrics":[{"cvssV4_0":{"attackComplexity":"LOW","attackRequirements":"PRESENT","attackVector":"NETWORK","baseScore":8.2,"baseSeverity":"HIGH","privilegesRequired":"NONE","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","vectorString":"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","version":"4.0","vulnAvailabilityImpact":"HIGH","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-347","description":"CWE-347 Improper Verification of Cryptographic Signature","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-08-01T18:46:05.234Z","orgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","shortName":"EEF"},"references":[{"tags":["vendor-advisory","related"],"url":"https://github.com/ueberauth/guardian/security/advisories/GHSA-7975-hp3r-5qhv"},{"tags":["related"],"url":"https://cna.erlef.org/cves/CVE-2026-55735.html"},{"tags":["related"],"url":"https://osv.dev/vulnerability/EEF-CVE-2026-55735"},{"tags":["patch"],"url":"https://github.com/ueberauth/guardian/commit/2bd7a8c29770d423d855c0a4965caa6c3e486901"}],"source":{"discovery":"EXTERNAL"},"title":"Guardian.revoke/3 acts on unverified token claims, allowing forged-token session revocation","workarounds":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<p>Verify the token before revoking it: call <tt>decode_and_verify</tt> (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 <tt>Guardian.revoke/3</tt>. Reject tokens with an invalid signature at the application boundary.</p>"}],"value":"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."}],"x_generator":{"engine":"cvelib 1.8.0"}}},"cveMetadata":{"assignerOrgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","assignerShortName":"EEF","cveId":"CVE-2026-55735","datePublished":"2026-08-01T18:46:05.234Z","dateReserved":"2026-06-17T10:44:34.365Z","dateUpdated":"2026-08-01T18:46:05.234Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"}