GHSA-hh34-374j-pfr5 — ash_authentication
Fix: team-alembic/ash_authentication@b9568a5GHSA-hh34-374j-pfr5 is a CWE-290 vulnerability in ash_authentication. A fix is available for ash_authentication — see the affected versions and patch details below.
Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement
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
Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who can plant a remember-me cookie in a victim's browser to replace that victim's authenticated session with one for the attacker's own account.
AshAuthentication.Plug.Helpers.sign_in_using_remember_me/3 skips re-authenticating an already-signed-in visitor by checking the session for "<subject_name>_token", but store_in_session/2 writes that key only when require_token_presence_for_authentication? is enabled and otherwise writes the bare subject name. At the default setting the guard therefore reads a key that is never written, its already-signed-in branch is unreachable, and the remember-me sign-in runs on every request through the per-request browser pipeline plug. A planted remember-me cookie is consequently honoured even for a visitor holding a live authenticated session, so whatever the victim enters afterwards lands in data the attacker controls. The read path in authenticate_resource_from_session/4 selects the key correctly, so the guard and the reader disagree about which key holds the session.
This issue affects ash_authentication: from 4.10.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Impact
An attacker who can set a remember-me cookie in a victim's browser silently replaces the victim's authenticated session with one for the attacker's own account, so data the victim subsequently enters is written to records the attacker controls. The victim is given no indication their identity changed.
Workarounds
Set require_token_presence_for_authentication? true on the authenticated resource's token configuration. store_in_session/2 then writes the key the guard reads, so the already-signed-in branch fires and the remember-me sign-in no longer runs against a live session. Note this changes session storage semantics for the whole application and requires a token resource.
Otherwise remove the remember-me plug from the browser pipeline, which disables remember-me auto-login entirely.
Configurations
The application must enable the remember_me strategy and run its per-request plug in the browser pipeline, with require_token_presence_for_authentication? at its default of false. Enabling that setting makes the guard read the key the session actually holds, which closes the issue.
The attacker also needs a position from which to set a cookie in the victim's browser, such as cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | ash_authentication | ≥ 4.10.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-hh34-374j-pfr5 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-hh34-374j-pfr5 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-hh34-374j-pfr5. 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-hh34-374j-pfr5 in your dependencies?
O3 Security finds GHSA-hh34-374j-pfr5 across Hex dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.