Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement
Published Sep 17, 2026 · Updated Sep 17, 2026
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.
Summary
What happened
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.
The record
- CVE
- CVE-2026-76949
- Published
- Sep 17, 2026
- Updated
- Sep 17, 2026
- Vendor
- Alembic
- Product
- Ash Authentication
- Classifications
- Unavailable
- Attack vector
- Unavailable
- Privileges
- Unavailable
Timeline
How it unfolded
- Sep 17, 2026CVE publishedPublication date reported by the CVE source.
- Sep 17, 2026Record updatedLatest update available in the CVE record.
Exploitability
Present is not the same as exploitable
Compare your product and version with the public record. A matching version still requires validation against your environment.
Is a vulnerable build present?
Compare these published version ranges with your installed build and any vendor patches.
- Affected versionversion=3d3de314692558d06ec13945f857f00514e95a8c <* changes=[{"at":"b9568a53b438247238b1c5a4f49c8d84650f4bba","status":"unaffected"},{"at":"9a34136b844abe179da1075067cf2835c64dcc12","status":"unaffected"}]
- Affected versionversion=4.10.0 <4.15.0
- Affected versionversion=5.0.0-rc.0 <5.0.0-rc.14
What conditions does exploitation require?
What is affected?
Published CVSS scores
No CVSS assessment is available in this record.
CVSS describes severity. EPSS estimates exploitation probability.
Attacks
What attackers are doing with it
Daily unique IPs observed by Shadowserver honeypots for known exploited vulnerabilities (KEVs). Missing observations do not establish an absence of attacks.
Activity data is delayed. The latest report is Sep 28, 2026.
Weakness, pattern, technique
No sourced classifications are available.
Public exploit references
No public exploit references are available in this record.
Labels summarize the accepted research assessment. They do not indicate a test against your environment.
Technologies
Your stack
See the directory against your own environment.
Your stack
Check the software in your environment
Get started to see how Hinoki identifies affected software and validates exploitability in your environment.
Get started