NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
💧 Hex
Not in CISA KEV

Ash Authentication has flawed token revocation checking logic in actions generated by `mix ash_authentication.install`GHSA-qrm9-f75w-hg4c

Fix: team-alembic/ash_authentication@2dee552

GHSA-qrm9-f75w-hg4c is a Improper Privilege Management vulnerability in ash_authentication. A fix is available for ash_authentication — see the affected versions and patch details below.

Also known asCVE-2025-25202
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-qrm9-f75w-hg4c.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs24th percentile — riskier than 24% of all scored CVEsHighest risk
0.00%0.27%0.54%0.81%0.2%0.3%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
💧ash_authentication

Real-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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
💧Hexash_authentication≥ 4.1.0&&< 4.4.94.4.9mix deps.update ash_authentication

Affected Products

1 product · 1 configurations
Application
ash authenticationalembic
≥ 4.1.0 && < 4.4.9
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ash_authentication, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. 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.

  3. Workarounds

    Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.

Frequently Asked Questions

### 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 he
O3 Security · Impact-Aware SCA

Is GHSA-qrm9-f75w-hg4c in your dependencies?

Find it across Hex, including transitive dependencies.

Scan my dependencies How O3 SCA works
Ash Authentication has flawed token revocation checking…