CVE-2026-78223
mediumpriority · track · 0EPSS 0.004 · 38 %ileUSEPSS · scored 2026-10-27
Improper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource. AshAuthentication.TokenResource.RevokeTokenChange.change/3 reads the :token argument and decodes it with AshAuthentication.Jwt.peek/1, which delegates to Joken.peek_claims/1 and performs no signature check, unlike Jwt.verify/4. The jti, exp and sub claims it returns are written straight onto the revocation record, guarded only by byte_size(token) > 0. Because expires_at derives from the attacker-chosen exp, a forged copy of a genuine token that keeps the real jti but backdates exp yields a revocation row that is already expired: expunge_expired removes it and the genuine token passes revoked? again. Arbitrary jti and sub values can be inserted the same way. This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · low–medium · 2.7–6.9
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (2)
Products and version ranges known to be affected.
advisories (1)
Vendor and ecosystem advisories describing this.
- EEF-CVE-2026-78223Token revocation record built from unverified JWT claims in AshAuthentication2026-09-17vendor · osvUS
## Summary Improper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource. `AshAuthentication.TokenResource.RevokeTokenChange.change/3` reads the `:token` argument and decodes it with `AshAuthentication.Jwt.peek/1`, which delegates to `Joken.peek_claims/1` and performs no signature check, unlike `Jwt.verify/4`. The `jti`, `exp` and `sub` claims it returns are written straight onto the revocation record, guarded only by `byte_size(token) > 0`. Because `expires_at` derives from the attacker-chosen `exp`, a forged copy of a genuine token that keeps the real `jti` but backdates `exp` yields a revocation row that is already expired: `expunge_expired` removes it and the genuine token passes `revoked?` again. Arbitrary `jti` and `sub` values can be inserted the same way. This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
also known as (1)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (6) nvd
External citations — patches, advisories, analysis.
- https://cna.erlef.org/cves/CVE-2026-78223.html
- https://github.com/team-alembic/ash_authentication/commit/344cebb12faf68e648d3283394073ba0c0f78459
- https://github.com/team-alembic/ash_authentication/commit/a939dde9b917c072cdf10c4b0913a9886a4b0231
- https://github.com/team-alembic/ash_authentication/commit/eb86353fe5a547c5ff5fd9af0e2c212518c31c9b
- https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-mfwg-5cpf-px58
- https://osv.dev/vulnerability/EEF-CVE-2026-78223
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan