GHSA-v577-944g-7h3x — ash_authentication
Fix: team-alembic/ash_authentication@872db45GHSA-v577-944g-7h3x is a CWE-384 vulnerability in ash_authentication. A fix is available for ash_authentication — see the affected versions and patch details below.
Session id is not renewed on authentication in ash_authentication, allowing session fixation
Real-World Exposure
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
Summary
Session Fixation vulnerability in team-alembic ash_authentication allows an attacker who can plant a session identifier in a victim's browser to hold an authenticated session once that victim signs in.
AshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with carries into their authenticated session. Every authentication event reaches this one function: the default success/4 injected by AshAuthentication.Phoenix.Controller.__using__/1, the AuthController emitted by mix ash_authentication_phoenix.install, and remember-me auto-login. AshAuthentication.Phoenix.Plug.store_in_session/2 is a defdelegate to it. Logout does not close the window either, because clear_session/2 ends with Plug.Conn.clear_session/1, which clears session contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle.
This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Impact
An attacker holding a session identifier they planted before the victim signed in gains that victim's authenticated session, and with it full account takeover, in deployments using a server-side session store.
Workarounds
Call Plug.Conn.configure_session(conn, renew: true) in your own success/4 before store_in_session/2. This is a one-line change in application code and closes the controller sign-in path, though not remember-me auto-login, which does not pass through application code.
Add Plug.Conn.configure_session(conn, drop: true) at sign-out so a planted identifier does not survive a logout-then-login cycle.
Configurations
Exploitation for account takeover requires a server-side session store (ETS, Mnesia, Redis or a database), where the cookie carries a stable session identifier, and a position from which the attacker can plant that cookie in the victim's browser: cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser.
Phoenix defaults to the signed cookie store, and neither package's installer changes it. Under that store the authenticated session lives in the re-signed cookie delivered only to the victim, so a planted pre-authentication copy does not become an authenticated session. Attacker-planted session contents, such as a return_to value, still survive into the authenticated session there.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | ash_authentication | ≥ 0.2.0&&< 4.15.0 | 4.15.0mix deps.update ash_authentication |
Detection & mitigation playbook
Open-source dependencyDetect
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.
Fix
Update ash_authentication to 4.15.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v577-944g-7h3x 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-v577-944g-7h3x can be triaged on real exposure rather than presence alone.
Tailored to GHSA-v577-944g-7h3x. 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-v577-944g-7h3x in your dependencies?
O3 Security finds GHSA-v577-944g-7h3x across Hex dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.