8000 Pending auth flow waiting for email verification succeeds even after password reset - providing room for pre-account takeover attacks · Issue #45568 · keycloak/keycloak · GitHub
[go: up one dir, main page]

Skip to content

Pending auth flow waiting for email verification succeeds even after password reset - providing room for pre-account takeover attacks #45568

Closed

Description

@vekonypeter

Before reporting an issue

  • I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

authentication

Describe the bug

An attacker can silently get logged into and stay logged in to a victim's account even when email verification is turned on in the realm.

Attack steps:

  1. an attacker creates an account using someone else's email address (classic pre-account takeover attack)
  2. an email verification message is sent to the victim
  3. the attacker waits at the screen which tells that a confirmation email was sent - this session might expire, but then the attacker logs in again and the email is re-sent
  4. the victim gets the emails
  5. the victim doesn't confirm the email, but goes directly to the application
  6. tries to log in, but can't since only the attacker knows the password
  7. the victim clicks forgot password
  8. password reset email is sent and the victim completes the action
  9. either before or after the new password is set (however it is configured) the user sees the email verification screen too and gets another confirmation mail
  10. the victim now verifies the email
  11. user logs in
  12. attacker (who is waiting all this time) refreshes the login page and gets logged in too

Note that, this is possible only if the victim completes both the password reset and email confirmation within the time while the attacker's verify email session is still valid.

Version

26.5.1 (latest)

Regression

  • The issue is a regression

Expected behavior

When I use the password reset flow, all pending sessions that might result in a login are invalidated. Or, only that pending session should succeed and result in a login which sent the message that the user actually used to verify the email.

Actual behavior

A pending authentication session succeeds despite that within its lifetime credentials were reset and a different email confirmation link was used.

How to Reproduce?

  1. set up a virgin Keycloak installation
  2. log into the admin console and create a new realm
  3. enable forgot password feature and enforce email verification upon registration (needs email server configuration too, of course)
  4. open two different browsers, one for the attacker, one for the victim
  5. use the built-in account UI as the "application" and follow the steps from the description

Anything else?

No response

Activity

  1. added theissue type on Jan 19, 2026
  2. < 10BC8 div class="timelineBodyRowContainer__tbZsj7">
  • self-assigned this
    on Feb 9, 2026
  • graziang commented on Feb 10, 2026

    @graziang
    Contributor

    The issue is valid, but it requires an edge case scenario: the victim needs to trigger a password reset for an application where they have never created an account, and then verify the email.

    This happens because there is no user session yet, and the attacker’s auth session is not removed when it is waiting on the “verify email” required action. So he can just wait for the victim to change the password and verify the email.

    One possible fix would be to programmatically invalidate all authentication sessions attached to the user when the password is changed, like with the user sessions.

    @ahus1 Do you know if there is a way to get or remove an authentication session based on an auth note or on the user attached to the authentication session? AFAIK, this is only possible with the auth session ID.

  • removed their assignment
    on Feb 10, 2026
  • 22 remaining items

  • self-assigned this
    on Apr 10, 2026
  • added a commit that references this issue on Apr 17, 2026
    72e0c26
  • added a commit that references this issue on Jul 20, 2026
    2b2ef9b
  • Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    Type

    Fields

    No fields configured for bug.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0