EEF-CVE-2025-4754 CVE-2025-4754 GHSA-f7gq-h8jv-h3cq
Missing Session Revocation on Logout in ash_authentication_phoenix
- Severity
- 0.0 / 10
- Low · CVSS 4.0
- Exploit chance (EPSS)
- 0.50%
- Chance of exploitation in the next 30 days. Higher than 42.87% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-613 Insufficient Session Expiration
- Fix
2.10.0- Upgrade ash_authentication_phoenix to this version or later
Description
Summary
Insufficient Session Expiration vulnerability in team-alembic ash_authentication_phoenix allows a session token captured before sign-out to remain usable afterwards.
The default sign_out/2 that AshAuthentication.Phoenix.Controller injects into an application's auth controller only calls Plug.Conn.clear_session/1. It never revokes the stored session or bearer tokens, so a token obtained before sign-out, through script injection, interception or device theft, keeps authenticating until its own expiry. Changing the password still revokes it.
This issue affects ash_authentication_phoenix: from 0.1.0 before 2.10.0.
Affected versions
Hex
| Package | Vulnerable | Fixed in |
|---|---|---|
| ash_authentication_phoenix | >= 0.1.0, < 2.10.0 |
2.10.0 |
| ash_authentication_phoenix | < 2.10.0 |
2.10.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
ash_authentication_phoenix Hex → 2.10.0
- mix
{:ash_authentication_phoenix, "~> 2.10.0"} # then: mix deps.update ash_authentication_phoenix
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- Passive
- Confidentiality (vulnerable system)
- Low
- Integrity (vulnerable system)
- Low
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-613: Insufficient Session Expiration
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
How to prevent it
- Implementation: Set sessions/credentials expiration date.
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| EEF-CVE-2026-86533 Revoked session accepted because the session jti is never checked in AshAuthentication and AshAuthentication Phoenix | Not rated yet | Also affects ash_authentication_phoenix |
| EEF-CVE-2026-81632 Single-use sign-in token placed in a redirect query string in AshAuthenticationPhoenix | Not rated yet | Also affects ash_authentication_phoenix |
| GHSA-r7rc-c989-86g6 Keycloak: Attacker can re-enable and take over disabled clients via registration access token | Medium | Same weakness, CWE-613 |
| GHSA-wq4w-vwvq-q3x9 Nginx UI: Standalone short tokens survive administrative revocation in cache and authenticate again after account re-enable | Medium | Same weakness, CWE-613 |
| GHSA-hjx8-qv73-f7cm Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed | High | Same weakness, CWE-613 |
| GHSA-4hv6-xc92-j86g Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes | High | Same weakness, CWE-613 |
| GHSA-jq7h-wrvp-3rgx pyLoad: Privilege revocation and password change through the REST API do not invalidate the user's session | High | Same weakness, CWE-613 |
| GHSA-889w-m37p-88m5 pyLoad: Api.set_user_permission never invalidates the target's session | High | Same weakness, CWE-613 |
Credits: James Harton, Jonatan Männchen / EEF, Josh Price / Alembic, Mike Buhot, Zach Daniel
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor