Ash Authentication Phoenix
Monthly
Revoked sessions continue to be treated as fully authenticated on affected AshAuthentication and AshAuthentication Phoenix deployments, so anyone holding a session value captured before the victim signed out can keep acting as that user indefinitely. The flaw affects ash_authentication_phoenix from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 onward, and ash_authentication from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14, but only for resources configured with session_identifier :jti while require_token_presence_for_authentication? is disabled; deployments using require_token_presence_for_authentication? true validate the token and are not affected. No public exploit identified at time of analysis, though the upstream advisory rates the issue 9.1 and vendor patches are already published.
Password sign-in in AshAuthentication Phoenix (ash_authentication_phoenix 1.7.0 to <2.17.4 and 3.0.0-rc.0 to <3.0.0-rc.11, with the companion ash_authentication 3.10.5 to <4.15.0 and 5.0.0-rc.0 to <5.0.0-rc.14) places a freshly issued single-use sign-in token in the query string of a GET redirect to the sign_in_with_token route, so the live credential is written into the request line where it is retained by web server access logs, reverse-proxy logs, request telemetry and the victim's browser history. Anyone who can read those artifacts - and can replay the token before the legitimate redirect consumes it or it expires - can authenticate as the affected user. The exposure is only reachable when sign_in_tokens_enabled? is true and the password sign-in form is in use; the vendor rates it CVSS 4.0 7.2 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H) and our independent assessment aligns at CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, indicating no public exploit identified at time of analysis rather than remotely exploitable default-configuration compromise.
Revoked sessions continue to be treated as fully authenticated on affected AshAuthentication and AshAuthentication Phoenix deployments, so anyone holding a session value captured before the victim signed out can keep acting as that user indefinitely. The flaw affects ash_authentication_phoenix from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 onward, and ash_authentication from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14, but only for resources configured with session_identifier :jti while require_token_presence_for_authentication? is disabled; deployments using require_token_presence_for_authentication? true validate the token and are not affected. No public exploit identified at time of analysis, though the upstream advisory rates the issue 9.1 and vendor patches are already published.
Password sign-in in AshAuthentication Phoenix (ash_authentication_phoenix 1.7.0 to <2.17.4 and 3.0.0-rc.0 to <3.0.0-rc.11, with the companion ash_authentication 3.10.5 to <4.15.0 and 5.0.0-rc.0 to <5.0.0-rc.14) places a freshly issued single-use sign-in token in the query string of a GET redirect to the sign_in_with_token route, so the live credential is written into the request line where it is retained by web server access logs, reverse-proxy logs, request telemetry and the victim's browser history. Anyone who can read those artifacts - and can replay the token before the legitimate redirect consumes it or it expires - can authenticate as the affected user. The exposure is only reachable when sign_in_tokens_enabled? is true and the password sign-in form is in use; the vendor rates it CVSS 4.0 7.2 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H) and our independent assessment aligns at CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, indicating no public exploit identified at time of analysis rather than remotely exploitable default-configuration compromise.