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.
"}],"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":"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.
"}],"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":"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.
"}],"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"},"nvd":{"publishedDate":"2026-08-01 19:16:42","lastModifiedDate":"2026-08-01 19:16:42","problem_types":["CWE-347","CWE-347 CWE-347 Improper Verification of Cryptographic Signature"],"metrics":{"cvssMetricV40":[{"source":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","type":"Secondary","cvssData":{"version":"4.0","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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","baseScore":8.2,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"PRESENT","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"55735","Ordinal":"1","Title":"Guardian.revoke/3 acts on unverified token claims, allowing forg","CVE":"CVE-2026-55735","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"55735","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"Guardian.revoke/3 acts on unverified token claims, allowing forg"}]}}}