← Back to CVE List
CVE-2026-76949NVD
Vulnerability 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.
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.
CVSS v4.0 Base Metrics — Score 9.1 (CRITICAL)
Attack VectorNetwork
Attack ComplexityLow
Attack RequirementsPresent
Privileges RequiredNone
User InteractionNone
Confidentiality (Vulnerable System)High
Integrity (Vulnerable System)High
Availability (Vulnerable System)None
Confidentiality (Subsequent System)None
Integrity (Subsequent System)None
Availability (Subsequent System)None
Affected & Patched Versions
- team-alembic ash_authentication >= 4.10.0 and < 4.15.0
- team-alembic ash_authentication >= 5.0.0-rc.0 and < 5.0.0-rc.14
- team-alembic ash_authentication >= 3d3de314692558d06ec13945f857f00514e95a8c and < *
- team-alembic ash_authentication 4.15.0
- team-alembic ash_authentication 5.0.0-rc.14
- team-alembic ash_authentication *
External References
- https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-hh34-374j-pfr5
- https://cna.erlef.org/cves/CVE-2026-76949.html
- https://osv.dev/vulnerability/EEF-CVE-2026-76949
- https://github.com/team-alembic/ash_authentication/commit/3d3de314692558d06ec13945f857f00514e95a8c
- https://github.com/team-alembic/ash_authentication/commit/b9568a53b438247238b1c5a4f49c8d84650f4bba
- https://github.com/team-alembic/ash_authentication/commit/9a34136b844abe179da1075067cf2835c64dcc12