The last two issues have been about passkeys and the move to phishing-resistant authentication. This issue the story is the other side of that process: what happens when somebody needs to reset or recover a credential.
Two pieces of research this fortnight, one against Keycloak and one against Active Directory, arrived at the same place from completely different directions. Neither attacked the login. Both attacked the reset.
Keycloak: a password reset without the token
A critical Keycloak vulnerability, CVE-2026-18963, allowed an unauthenticated attacker to force a password reset for another Keycloak user, potentially including an administrator.
The flaw sat in how Keycloak validated the stages of the password recovery process. Researchers found they could manipulate the flow so the authentication session reached the password update stage without the attacker ever holding the reset token that is normally sent to the user's email. From there they could set a new password and take over the account.
Keycloak patched the vulnerability in version 26.7.2, with fixes also released for affected Red Hat builds. As of 24 August there was no evidence of exploitation in the wild.
ResetNightmare: impersonation inside Kerberos
At Black Hat this month, Shai Laron, a security researcher at Semperis, presented a password reset attack against Active Directory called ResetNightmare.
The weakness was in how the Kerberos password change protocol handled identity. An attacker with permission to modify the User Principal Name of an Active Directory user or computer object could manipulate it to impersonate another account during part of the Kerberos process, then use that position to reset another user's password. In the worst case that includes a Domain Admin, which is a complete domain takeover.
The precondition matters: the attacker already needed write access to an existing object, or the ability to create one, inside the directory. Microsoft patched the vulnerability, CVE-2026-27912, in April.
The pattern, and it is becoming a familiar one
The two vulnerabilities are technically unrelated. The reason they belong in the same story is that both route around strong authentication entirely, and they are not alone. Research published by Specops this week looked at the same problem from the social engineering side: attackers increasingly target identity verification during onboarding, password resets, MFA resets and account recovery, rather than trying to beat the authentication controls directly.
The service desk is the sharpest version of the problem. An organisation can require phishing-resistant MFA on every account, but the helpdesk still needs some way to verify a caller who says they have lost their authentication device. If that verification is weaker than the authentication it replaces, the attacker simply becomes that caller.
There is not much point building an incredibly strong front door if the process for getting a new key is easier to attack.
Readers of Issue #001 will recognise the shape. The passkey enrolment campaign we covered there, and the Black Hat implementation research from last issue, are the same lesson at different points in the lifecycle: as the login hardens, every other place a credential can be created, replaced or recovered becomes the profitable target.
Six questions to answer in writing
Who can trigger a password, MFA or passkey reset? Name every path, including the helpdesk-assisted one.
What proofing is required before a reset is approved? And is it proofing, or is it a caller who knew an employee ID?
Does account recovery meet the same security standard as normal authentication? If not, recovery is your real authentication standard.
Should privileged accounts have a different recovery process? If admins recover the same way as everyone else, they can be attacked the same way as everyone else.
Who is alerted when a credential is reset or replaced? The account holder, the security team, or in practice nobody.
Can unusual resets and new credential registrations be detected? Both attacks this fortnight would have surfaced there first.
As authentication keeps getting harder to attack, resets and recovery will keep getting more attractive. The teams that treat recovery as part of the authentication system, rather than an IT process bolted onto the side of it, are the ones this research will not surprise.
Sources
Critical Keycloak password reset flaw, The Hacker News
ResetNightmare research, Semperis
The growing identity verification risk, Specops via BleepingComputer