EEF-CVE-2026-86688

## Summary

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.

## Impact

An attacker holding a session identifier they planted before the victim signed in gains that victim's authenticated session, and with it full account takeover, in deployments using a server-side session store.

## Workarounds

Call `Plug.Conn.configure_session(conn, renew: true)` in your own `success/4` before `store_in_session/2`. This is a one-line change in application code and closes the controller sign-in path, though not remember-me auto-login, which does not pass through application code.

Add `Plug.Conn.configure_session(conn, drop: true)` at sign-out so a planted identifier does not survive a logout-then-login cycle.

## Configurations

Exploitation for account takeover requires a server-side session store (ETS, Mnesia, Redis or a database), where the cookie carries a stable session identifier, and a position from which the attacker can plant that cookie in the victim's browser: cookie tossing from a sibling subdomain, an HTTP host without HSTS, or a shared or kiosk browser.

Phoenix defaults to the signed cookie store, and neither package's installer changes it. Under that store the authenticated session lives in the re-signed cookie delivered only to the victim, so a planted pre-authentication copy does not become an authenticated session. Attacker-planted session contents, such as a `return_to` value, still survive into the authenticated session there.