GHSA-qrm9-f75w-hg4c
Ash Authentication has flawed token revocation checking logic in actions generated by `mix ash_authentication.install`
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
ash_authenticationReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Applications which have been bootstrapped by the new igniter installer (since AshAuthentication v4.1.0) and who have used the magic link strategy, password resets, confirmation, or are manually revoking tokens are affected by revoked tokens being allowed to verify as valid. If you did not use the new installer, then you are absolutely not affected.
Additionally, unless you have implemented any kind of custom token revocation feature in your application (in which case even cursory testing would have uncovered this issue), then you will not be significantly affected.
The impact here for users is as follows:
- For users using the magic link strategy, magic link tokens are reusable until they expire instead of being immediately revoked. By default magic link tokens are valid for 10 minutes.
- For users of password resets in the password strategy, password reset tokens are reusable until they expire instead of being immediately revoked. By default password reset tokens are valid for 3 days.
- For users of the confirmation add-on, confirmation tokens are reusable until they expire instead of being immediately revoked. By default password reset tokens are valid for 3 days.
Patches
The flaw is patched in version 4.4.9. Additionally a compile time warning is shown to users with remediation instructions if they upgrade. 4.4.9 ships with an upgrader, so if you use mix igniter.upgrade ash_authentication the necessary patch will be applied for you. Otherwise you can run the upgrader manually as described in the error message
Example
[warning] Warning while compiling Tunez.Accounts.Token:
The `:jti` and `:token` options to the `:revoked?` action must allow nil values and it must return a `:boolean`.
This was an error in our igniter installer previous to version 4.4.9, which allowed revoked tokens to be reused.
To fix this, run the following command in your shell:
mix ash_authentication.upgrade 4.4.8 4.4.9
Or:
- remove `allow_nil?: false` from these action arguments, and
- ensure that the action returns `:boolean`.
like so:
action :revoked?, :boolean do
description "Returns true if a revocation token is found for the provided token"
argument :token, :string, sensitive?: true
argument :jti, :string, sensitive?: true
run AshAuthentication.TokenResource.IsRevoked
end
Workarounds
Delete the generated :revoked? generic action in your token resource This will cause it to use the one internal to AshAuthentication which has always been correct. Alternatively, manually make the changes described above.
References
See the #ash_authentication channel on the Ash Discord.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | ash_authentication | ≥ 4.1.0&&< 4.4.9 | 4.4.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ash_authentication. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update ash_authentication to 4.4.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qrm9-f75w-hg4c is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-qrm9-f75w-hg4c is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-qrm9-f75w-hg4c. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-qrm9-f75w-hg4c in your dependencies?
O3 detects GHSA-qrm9-f75w-hg4c across Hex dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.