Repository navigation
Description
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:
- an attacker creates an account using someone else's email address (classic pre-account takeover attack)
- an email verification message is sent to the victim
- 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
- the victim gets the emails
- the victim doesn't confirm the email, but goes directly to the application
- tries to log in, but can't since only the attacker knows the password
- the victim clicks forgot password
- password reset email is sent and the victim completes the action
- 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
- the victim now verifies the email
- user logs in
- 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?
- set up a virgin Keycloak installation
- log into the admin console and create a new realm
- enable forgot password feature and enforce email verification upon registration (needs email server configuration too, of course)
- open two different browsers, one for the attacker, one for the victim
- use the built-in account UI as the "application" and follow the steps from the description
Anything else?
No response
Activity
graziang commentedon Feb 10, 2026
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.
22 remaining items
Update password after email verification during registration of users (…
Update password after email verification during registration of users (…