CVE-2026-65633: Ash Authentication JWT purpose validation bypass in bearer token authentication

CVE-2026-65633 · Severity: info · CVSS 7.5 · Published 2026-08-25

Ash Authentication, a library used to handle user login and authentication in web applications, fails to validate that short-lived, single-purpose login tokens (issued during WebAuthn sign-in or password-based login flows) are only used for their intended purpose. An attacker who obtains a leaked or intercepted sign-in token can use it directly as a general authentication credential to impersonate the target user, completely bypassing the library's one-time-use and automatic token revocation protections.

Quick answers

Is CVE-2026-65633 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-65633 being exploited in the wild.
How severe is CVE-2026-65633?
Informational severity, with a CVSS score of 7.5, published 25 August 2026.
Which products and versions are affected?
Ash Team AshAuthentication 3.10.5 to 4.14.1, 5.0.0-rc.0 to 5.0.0-rc.12.
Is there a fix for CVE-2026-65633?
No fixed version is recorded yet. Check the vendor's advisory in the references below. If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.
How is CVE-2026-65633 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-65633?
Check whether anything you run is named in the advisory. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The vulnerability is an improper authentication / token validation bypass in the AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 function. The bearer-token verification path checks the JWT signature and rejects tokens with an act claim, but fails to validate that the token's purpose claim equals "user" at the bearer boundary. When a resource is configured with the default require_token_presence_for_authentication?: false, the downstream validate_token/3 helper returns success without consulting the token resource, so no purpose validation occurs. This allows any valid, non-expired JWT issued for a narrow purpose (notably the purpose: sign_in token from WebAuthn or password sign-in flows) to be accepted directly as a general bearer credential and resolve to a full authenticated user session. The vulnerability requires the host application to wire up retrieve_from_bearer/3 on a reachable route and use either WebAuthn (which always issues sign-in tokens) or the Password strategy with sign_in_tokens_enabled?: true. Applications using require_token_presence_for_authentication?: true or session-based authentication are unaffected. Patches are available in versions 4.14.2 and 5.0.0-rc.13 onwards.

Affected products

  • Ash Team AshAuthentication 3.10.5 to 4.14.1, 5.0.0-rc.0 to 5.0.0-rc.12

Timeline

  • 2026-08-25: disclosed

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.