CVE-2026-76949: Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement

Published Sep 17, 2026
·
Updated

Authentication Bypass by Spoofing vulnerability in team-alembic ashauthentication 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.signinusingrememberme/3 skips re-authenticating an already-signed-in visitor by checking the session for "<subjectname>token", but storeinsession/2 writes that key only when requiretokenpresenceforauthentication? 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 authenticateresourcefromsession/4 selects the key correctly, so the guard and the reader disagree about which key holds the session.

This issue affects ashauthentication: from 4.10.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.

Affected Software

2 affected components
ash_authentication>=4.10.0<4.15.0
ash_authentication>=5.0.0-rc.0<5.0.0-rc.14

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade ash_authentication to a version that resolves this vulnerability.

    Fixed in 4.15.0
  2. Upgrade

    Upgrade ash_authentication to a version that resolves this vulnerability.

    Fixed in 5.0.0-rc.14

Event History

Sep 17, 2026
CVE Published
via MITRE·09:57 PM
Data Sourced
via MITRE·09:57 PM
DescriptionWeakness

Frequently Asked Questions

1

Is the default configuration affected?

Yes. The vulnerable behavior occurs when require_token_presence_for_authentication? is not enabled, which is the default setting. In that configuration, the sign-in guard checks for a session key that store_in_session/2 does not write.

2

What must an attacker be able to do to exploit this?

The attacker must be able to plant a remember-me cookie for the attacker’s own account in the victim’s browser. The victim must then make requests through the per-request browser pipeline plug while holding an authenticated session.

3

What can be done if patching is not immediately possible?

Enable require_token_presence_for_authentication? so store_in_session/2 writes the <subject_name>_token key that the remember-me guard checks. This aligns the session key written by storage with the key used by the guard.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203