ash_authentication: Session Fixation
CVE-2026-86688 is a high-severity session fixation vulnerability in ash_authentication from Team-alembic, with a CVSS 4.0 base score of 7.4 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, but only if a user takes part, for example by opening a link or file. The record lists versions 4.15.0, 5.0.0-rc.14 as the first without the flaw, so updating ash_authentication to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.74% chance of exploitation within 30 days, higher than 55% of scored CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update ash_authentication to 4.15.0 or 5.0.0-rc.14, whichever matches your release line, or a later version.
- Read the advisory on github.com for workarounds and exact fixed builds.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
- Because the attack needs a user to take part, warn users about unexpected links and files related to this product until it is patched.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Team-alembic | ash_authentication | 0.2.0 up to, but not including, 4.15.0; 5.0.0-rc.0 up to, but not including, 5.0.0-rc.14; a939dde9b917c072cdf10c4b0913a9886a4b0231 and later | 4.15.0, 5.0.0-rc.14 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Attack requirements
- PresentThe target must be in a specific state or configuration for the attack to work.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- ActiveA user must deliberately do something unusual, such as dismissing a warning.
- Confidentiality (vulnerable system)
- HighSerious loss of confidentiality on the vulnerable system.
- Integrity (vulnerable system)
- HighSerious loss of integrity on the vulnerable system.
- Availability (vulnerable system)
- NoneNo loss of availability on the vulnerable system.
- Confidentiality (other systems)
- NoneNo loss of confidentiality on systems beyond the vulnerable one.
- Integrity (other systems)
- NoneNo loss of integrity on systems beyond the vulnerable one.
- Availability (other systems)
- NoneNo loss of availability on systems beyond the vulnerable one.
Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. Scored by CNA.
Official description
Session Fixation vulnerability in team-alembic ash_authentication allows an attacker who can plant a session identifier in a victim's browser to hold an authenticated session once that victim signs in. AshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with carries into their authenticated session. Every authentication event reaches this one function: the default success/4 injected by AshAuthentication.Phoenix.Controller.__using__/1, the AuthController emitted by mix ash_authentication_phoenix.install, and remember-me auto-login. AshAuthentication.Phoenix.Plug.store_in_session/2 is a defdelegate to it. Logout does not close the window either, because clear_session/2 ends with Plug.Conn.clear_session/1, which clears session contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle. This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Session Fixation
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
How developers prevent this class of flaw
- Invalidate any existing session identifiers prior to authorizing a new user session.
- For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.
- Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Other vulnerabilities in ash_authentication
- 7.6 High severity
- 9.1 Critical severity
- 9.1 Critical severity
- 9.1 Critical severity
- 9.1 Critical severity
- 9.1 Critical severity
Recent Session Fixation vulnerabilities
- 8.1 High severity
- 8.8 High severity
- 8.8 High severity
- 7.4 High severity
- 8.3 High severity
- 7.4 High severity
Spotted an error? Tell us.