Team Alembic
Monthly
JWT token replay in AshAuthentication exposes any application using the stateless bearer-token path to full account takeover using purpose-scoped tokens. The `retrieve_from_bearer/3` helper in versions 3.10.5-4.14.2 and 5.0.0-rc.0-5.0.0-rc.13 verifies JWT signatures and rejects tokens with an `act` claim, but never validates that the token's `purpose` claim equals "user", allowing sign-in, remember-me, and TOTP-setup tokens to be silently accepted as full bearer credentials. No public exploit has been identified at time of analysis, but the attack requires only obtaining a still-valid, not-yet-exchanged sign-in token - a realistic threat surface via log leakage, referrer exposure, or intercepted magic-link delivery.
Account takeover in team-alembic AshAuthentication (0.1.0 to <4.14.0 and 5.0.0-rc.0 to <5.0.0-rc.10) lets an unauthenticated attacker hijack any local user account by completing an OAuth2 or OIDC sign-in with the victim's email address. The library matched federated logins to local users by email rather than by the OpenID Connect iss/sub pair, so any accepted provider that allows an attacker to register or reuse the victim's email - including providers that return email_verified: false - resolves to the victim's existing account. No public exploit identified at time of analysis, but the underlying technique (OIDC email-claim takeover) is well-documented and trivially reproducible.
Reflected XSS in AshAuthentication's confirmation and magic link interaction pages allows unauthenticated attackers to inject arbitrary JavaScript into a victim's browser by crafting a malicious GET URL. Versions 4.8.0 through 4.14.1 and 5.0.0-rc.0 through 5.0.0-rc.12 of this Elixir framework authentication library embed user-supplied request parameters verbatim into hidden HTML form inputs using unescaped EEx template expressions, and since the vulnerable accept handlers are served over GET, simply loading the crafted link is sufficient - no form submission or prior session is required. No public exploit code has been independently identified at time of analysis, though the attack is trivially constructable from the public advisory and commit diff alone.
JWT token replay in AshAuthentication exposes any application using the stateless bearer-token path to full account takeover using purpose-scoped tokens. The `retrieve_from_bearer/3` helper in versions 3.10.5-4.14.2 and 5.0.0-rc.0-5.0.0-rc.13 verifies JWT signatures and rejects tokens with an `act` claim, but never validates that the token's `purpose` claim equals "user", allowing sign-in, remember-me, and TOTP-setup tokens to be silently accepted as full bearer credentials. No public exploit has been identified at time of analysis, but the attack requires only obtaining a still-valid, not-yet-exchanged sign-in token - a realistic threat surface via log leakage, referrer exposure, or intercepted magic-link delivery.
Account takeover in team-alembic AshAuthentication (0.1.0 to <4.14.0 and 5.0.0-rc.0 to <5.0.0-rc.10) lets an unauthenticated attacker hijack any local user account by completing an OAuth2 or OIDC sign-in with the victim's email address. The library matched federated logins to local users by email rather than by the OpenID Connect iss/sub pair, so any accepted provider that allows an attacker to register or reuse the victim's email - including providers that return email_verified: false - resolves to the victim's existing account. No public exploit identified at time of analysis, but the underlying technique (OIDC email-claim takeover) is well-documented and trivially reproducible.
Reflected XSS in AshAuthentication's confirmation and magic link interaction pages allows unauthenticated attackers to inject arbitrary JavaScript into a victim's browser by crafting a malicious GET URL. Versions 4.8.0 through 4.14.1 and 5.0.0-rc.0 through 5.0.0-rc.12 of this Elixir framework authentication library embed user-supplied request parameters verbatim into hidden HTML form inputs using unescaped EEx template expressions, and since the vulnerable accept handlers are served over GET, simply loading the crafted link is sufficient - no form submission or prior session is required. No public exploit code has been independently identified at time of analysis, though the attack is trivially constructable from the public advisory and commit diff alone.