EEF-CVE-2026-76949 CVE-2026-76949 GHSA-hh34-374j-pfr5
Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement
- Severity
- 0.0 / 10
- Unknown · CVSS 4.0
- Exploit chance (EPSS)
- 0.77%
- Chance of exploitation in the next 30 days. Higher than 55.72% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-290 Authentication Bypass by Spoofing
- Fix
5.0.0-rc.14- Upgrade ash_authentication to this version or later
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 versions
Hex
| Package | Vulnerable | Fixed in |
|---|---|---|
| ash_authentication | >= 4.10.0, < 4.15.0>= 5.0.0-rc.0, < 5.0.0-rc.14 |
4.15.05.0.0-rc.14 |
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 Hex → 5.0.0-rc.14
- mix
{:ash_authentication, "~> 5.0.0-rc.14"} # then: mix deps.update ash_authentication
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-290: Authentication Bypass by Spoofing
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
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-86688 Session id is not renewed on authentication in ash_authentication, allowing session fixation | Not rated yet | Also affects ash_authentication |
| EEF-CVE-2026-91039 dynamic_oidc identities are not namespaced by connection in ash_authentication, allowing cross-connection account takeover | Not rated yet | Also affects ash_authentication |
| EEF-CVE-2026-88952 OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication | Not rated yet | Also affects ash_authentication |
| EEF-CVE-2026-85500 `require_confirmed_with` is not enforced on the action and fails open on an unreadable attribute in AshAuthentication | Not rated yet | Also affects ash_authentication |
| 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 |
| EEF-CVE-2026-81632 Single-use sign-in token placed in a redirect query string in AshAuthenticationPhoenix | Not rated yet | Also affects ash_authentication |
| EEF-CVE-2026-80218 Sign-in token minted for one resource accepted by another in AshAuthentication | Not rated yet | Also affects ash_authentication |
| EEF-CVE-2026-78223 Token revocation record built from unverified JWT claims in AshAuthentication | Not rated yet | Also affects ash_authentication |
Credits: James Harton, Jonatan Männchen / EEF, Peter Ullrich
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