CVE-2026-80218: Sign-in token minted for one resource accepted by another in AshAuthentication
Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker holding a sign-in token for one authenticated resource to be signed in as a user of a different resource.
AshAuthentication.Strategy.Password.SignInWithTokenPreparation.extractprimarykeysfromsubject/2 parses the JWT sub claim (for example user?id=1) with URI.parse/1 and keeps only its query string, discarding the path segment that names the subject the token was issued for. Nothing else restores that binding: AshAuthentication.Jwt.verify/3 checks the signature, exp, nbf, jti and the library-version claims, the purpose check only requires signin, and the remaining comparison is over primary-key field names, which are identical across resources. The WebAuthn sign-in and remember-me preparations carry copies of the same helper and drop the path in the same way. The magic link sign-in path pins the subject name against the resource and is not affected.
This issue affects ashauthentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 4.15.0 - Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.14
Event History
Frequently Asked Questions
Which authentication flows are affected?
The password sign-in-with-token flow, WebAuthn sign-in preparation, and remember-me preparation are affected because they use helpers that discard the JWT subject path. Magic-link sign-in is not affected because it pins the subject name to the resource.
What must an attacker have to exploit this issue?
An attacker must hold a valid sign-in token issued for one authenticated resource and use it against a different resource whose primary-key field names match. The token still has to pass signature, expiration, not-before, jti, library-version, and sign_in-purpose checks.
Are all configured resources interchangeable?
No. The described cross-resource acceptance depends on the resources having identical primary-key field names, because that is the remaining resource-related comparison after the JWT subject path is discarded.
Which versions need remediation?
Affected versions are ash_authentication 3.10.5 through versions before 4.15.0, and 5.0.0-rc.0 through versions before 5.0.0-rc.14. Upgrading to 4.15.0 or later in the 4.x line, or 5.0.0-rc.14 or later in the 5.0.0 release-candidate line, addresses the affected ranges.