Business logic of attack: why break password reset
Password reset is the only legitimate mechanism for changing credentials without knowledge of the current password. For the attacker, this is a direct path to Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation): not needed Brutforce (T1110.001, Password Guessing) or phishing - a logical error in one API-endpoint is enough. More details - in our detailed analysis of the attack on authentication.
The typical monetization chain looks like this:
Recon - collecting email addresses through leaks, LinkedIn or username enumeration (T1589.001, Credentials)
Exploit Public-Facing Application (T1190, Initial Access) - operation of the bug in password reset
Account takeover - change the password of the target account, getting a valid session
Privilege - if compromised by admin, the attacker controls the entire platform
Impact - data theft, lateral movement inside the infrastructure, ransomware deploy
According to OWASP Top 10 (2021) this crossing A01:2021 (Broken Access Control) and the authentication. Root CWE: CWE-640 (Weak Password Recovery Mechanism for Forgotten Password) - weak recovery mechanism, and CWE-28 (Authentication Bypass Using an Alternate Path or Channel) - bypassing authentication through an alternative channel.
Vector: AV:N/AC:L/AT:N/PR:N:N - network attack, low complexity, no privileges, no user interaction. The impact on confidentiality, integrity and accessibility is high in all three parameters.
Root Cause - CWE-288 (Authentication Bypass Using an Alternate Path or Channel): Endpoint /api/v1/auth/force-reset-password received anonymous requests and did not check the current password or reset token when the system administrator password is reset. POST with target username and new password - the account is compromised. Vulnerable all versions of SmarterMail to the 9511 build.
Why this CVE is an absolute priority in pentest:
CISA KEV: added January 26, 2026, patch deadline February 16, 2026, labeled as associated with ransomware campaigns
EPSS: 0.9654, percentile 0.9988 - Top 0.12% on probability of operation among all CVEs in the FIRST.org database
CISA SSVC Decision: Act - patch immediately. Operation active, automated, technical impact complete
PoC: public repository MaxMnMl/smartermail-CVE-2026-23760-poc on GitHub
Nuclei template: CVE-2026-23760.yamlin projectdiscovery/nuclei-templates
Found SmarterMail on the perimeter? Fingerprinting version and endpoint verification: nuclei -t http/cves/2026/CVE-2026-23760.yaml -u https://target-mail.com. If the patch is not possible right now - WAF-rule on blocking POST to /api/v1/auth/force-reset-password and restrict access to administrative interfaces over IP-whitelist.
CVSS 9.1 (CRITICAL) according to CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N vector - no privileges, no user interaction, high impact on privacy and integrity.
The root reason - CWE-640 (Weak Password Recovery Mechanism for Forgotten Password): incorrect state check in the reset-credentials stream. The attacker sent a specially generated request, and the authentication session jumped directly to the password update stage. The action token, which in the staff scenario comes to the email, was not required. According to the Red Hat bulletin, the risk applies to administrative accounts.
Here is an interesting point: according to CISA SSVC solution - Track (monitor). Operation - none at the time of evaluation, automation - yes, technical impact - total. That is, not yet broken, but when they start - it will be painful.
EPSS: 0.0318, percentile 0.8784 - above the median
Vulnerable versions: upstream Keycloak up to 26.7.2; RHBK 26.4 to 26.4.15; RHBK 26.6 to 26.6.6
PoC: Snizi/CVE-2026-18963-Exploit, prot0tw/Keycloak_CVE-2026-18963_PoC, gman0x00/keycloak-CVE-2026-18963gman0x00/keycloak-CVE-2026-18963 with Docker-site and patch diffin analysis
Nuclei template: CVE-2026-18963.yamlin projectdiscovery/nuclei-templates
Temporary measure to patch: disable Forgot Password in each realm via Realm Settings -> Login -> Forgot password. Setting up per realm - there is no single global switch, you will have to go through each.
In the same release, Keycloak 26.7.2 closed six more vulnerabilities, including CVE-2026-15571 (CVSS 7.3, HIGH) - predictable hash when linking accounts, allowing account takeover through malicious OIDC-client (CWE-341, Predictable from Observable State). If Keycloak is not updated to 26.7.2, not only password reset is vulnerable.
Fingerprinting Keycloak on the pentest: the version can be pulled through /auth/realms/master/.well-known/openid-configuration, HTTP response headers or HTML login page. Next - checking the flow of reset-credentials in Burp Repeater: request a password reset through UI, intercept all requests in Proxy, try to send a request to install a new password without a token from the email. The full-time stream requires a valid action token - if the server accepts the request without it, it is a confirmation of the vulnerability.
CVE password reset 2026: comparison
Parameter CVE-2026-23760 (SmarterMail) CVE-2026-18963 (Keycloak)
CVSS 9.3 (CRITICAL, CVSS 4.0) 9.1 (CRITICAL, CVSS 3.1)
CWE CWE-288 CWE-640
Privileges Not required (PR:N) Not required (PR:N)
Interaction Not required (UI:N) Not required (UI:N)
Vulnerable versions Up to the 9511 build Up to 26.7.2 (upstream)
CISA KEV Yes (ransomware) No
EPSS 0.9654 (Top 1%) 0.0318 (above the median)
Public PoC Yeah Yes (46 stars)
Nuclei template Yeah Yeah
Broken authentication pentest: patterns of attacks on password reset
Specific CVEs are good, but there are also recurring patterns in custom password recovery logic implementations. Three of them I see regularly.
Password reset without verification: leaking the token into the API
This pattern is not tied to a particular CVE - found in custom applications. According to OnSecurity, on the real pentest, the API returned the reset token directly in the JSON response body to the reset request. Attack - two HTTP requests: POST /api/auth/request-password-reset with the victim's email, then POST /api/auth/reset-password with the resulting token and new password. Account takeover without access to mail.
JSON:
{
"message": "If an account exists, you will receive reset instructions.",
"token": "8e8d6a18759f2b06f3ba43b8538c7cf707537d69226cf48f151e0816c2f99291"
}
Translation of the message:
JSON:
{
"token": "8e8d6a18759f2b06f3ba43b8538c7cf707537d69226cf48f151e0816c2f99291"
}
The field message says "get instructions by email" and the token is already in charge. Beautiful fan, and inside - full access. Bonus: if the token is returned only for registered accounts, availability/absence of the field token allows you to list users (username enumeration).
The second subtype is leakage through the API misconfiguration. According to Vaadata, on the pentest of ecommerce-app API comments to the goods returned all the fields of the user-object from the database, including token_reset. The attacker initiated the password reset for the target email, then twitched any endpoint that returns the data of that user, and received a fresh token - along with the password hash and email address.
How to search: in Burp Proxy, examine the body response to each query to /forgot-password, /reset-password and related endpoints. Look for the fields token, reset_token, code, otp, key. Check not only JSON – the token can lie in HTML as hidden input, in the answer headers, or in the redirect URL.
Host header injection reset
The app generates a reset link using the title Host from an HTTP request. If the server does not validate Host - the attacker replaces it with its domain, the victim receives a letter with a link https://attacker.com/reset?token=abc123. Click - and the token flies to the server of the attacking GET-parameter. This is password reset poisoning in a classic form.
Code:
POST /forgot-password HTTP/1.1
Host: attacker.com
Content-Type: application/x-www-form-urlencoded
csrf=qxoCDf28hFqnF2xP6HtGiIhnDFHmryPm&username=carlos
The attack requires the action of the victim (UI:R in CVSS), which reduces the final score compared to UI:N variants. But let's be honest: the percentage of opening letters from a legitimate service is usually high, so UI:R as a mitigating factor is a conditional thing.
Options for bypassing the Host validation in Burp Repeater:
Direct replacement Hostto your domain
Headlines X-Forwarded-Host, X-Forwarded-For, X-Original-URL
Double Host Header - Some Reverse-Proxy Miss Second
Parameters in the query body: according to Vaadata, on one pentest JSON-body contained a parameter baseurl, which directly generated the reset link. Server validation via Python urlparsebypassed the payload format [email protected] the parser took it for the userinfo part of the URL
IDOR in password reset and race condition
IDOR (Insecure Direct Object Reference): take a reset token issued for your account and substitute a foreign password in the request user_id or email. If the server does not check the token binding to a specific user - account takeover. It is checked trivially: two test accounts, one token, identifier substitution in Burp Repeater.
Race condition: via Turbo Intruder, send 20-50 parallel password reset requests for a single account. The goal is to check whether multiple valid tokens are generated simultaneously and whether the old token remains a worker after creating a new one. If yes, the attack window expands, and the disposable token does not actually work. The test takes 5 minutes, but often opens the broken access control in restoring access, which other checks miss.
Password reset is the only legitimate mechanism for changing credentials without knowledge of the current password. For the attacker, this is a direct path to Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation): not needed Brutforce (T1110.001, Password Guessing) or phishing - a logical error in one API-endpoint is enough. More details - in our detailed analysis of the attack on authentication.
The typical monetization chain looks like this:
Recon - collecting email addresses through leaks, LinkedIn or username enumeration (T1589.001, Credentials)
Exploit Public-Facing Application (T1190, Initial Access) - operation of the bug in password reset
Account takeover - change the password of the target account, getting a valid session
Privilege - if compromised by admin, the attacker controls the entire platform
Impact - data theft, lateral movement inside the infrastructure, ransomware deploy
According to OWASP Top 10 (2021) this crossing A01:2021 (Broken Access Control) and the authentication. Root CWE: CWE-640 (Weak Password Recovery Mechanism for Forgotten Password) - weak recovery mechanism, and CWE-28 (Authentication Bypass Using an Alternate Path or Channel) - bypassing authentication through an alternative channel.
Vector: AV:N/AC:L/AT:N/PR:N:N - network attack, low complexity, no privileges, no user interaction. The impact on confidentiality, integrity and accessibility is high in all three parameters.
Root Cause - CWE-288 (Authentication Bypass Using an Alternate Path or Channel): Endpoint /api/v1/auth/force-reset-password received anonymous requests and did not check the current password or reset token when the system administrator password is reset. POST with target username and new password - the account is compromised. Vulnerable all versions of SmarterMail to the 9511 build.
Why this CVE is an absolute priority in pentest:
CISA KEV: added January 26, 2026, patch deadline February 16, 2026, labeled as associated with ransomware campaigns
EPSS: 0.9654, percentile 0.9988 - Top 0.12% on probability of operation among all CVEs in the FIRST.org database
CISA SSVC Decision: Act - patch immediately. Operation active, automated, technical impact complete
PoC: public repository MaxMnMl/smartermail-CVE-2026-23760-poc on GitHub
Nuclei template: CVE-2026-23760.yamlin projectdiscovery/nuclei-templates
Found SmarterMail on the perimeter? Fingerprinting version and endpoint verification: nuclei -t http/cves/2026/CVE-2026-23760.yaml -u https://target-mail.com. If the patch is not possible right now - WAF-rule on blocking POST to /api/v1/auth/force-reset-password and restrict access to administrative interfaces over IP-whitelist.
CVSS 9.1 (CRITICAL) according to CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N vector - no privileges, no user interaction, high impact on privacy and integrity.
The root reason - CWE-640 (Weak Password Recovery Mechanism for Forgotten Password): incorrect state check in the reset-credentials stream. The attacker sent a specially generated request, and the authentication session jumped directly to the password update stage. The action token, which in the staff scenario comes to the email, was not required. According to the Red Hat bulletin, the risk applies to administrative accounts.
Here is an interesting point: according to CISA SSVC solution - Track (monitor). Operation - none at the time of evaluation, automation - yes, technical impact - total. That is, not yet broken, but when they start - it will be painful.
EPSS: 0.0318, percentile 0.8784 - above the median
Vulnerable versions: upstream Keycloak up to 26.7.2; RHBK 26.4 to 26.4.15; RHBK 26.6 to 26.6.6
PoC: Snizi/CVE-2026-18963-Exploit, prot0tw/Keycloak_CVE-2026-18963_PoC, gman0x00/keycloak-CVE-2026-18963gman0x00/keycloak-CVE-2026-18963 with Docker-site and patch diffin analysis
Nuclei template: CVE-2026-18963.yamlin projectdiscovery/nuclei-templates
Temporary measure to patch: disable Forgot Password in each realm via Realm Settings -> Login -> Forgot password. Setting up per realm - there is no single global switch, you will have to go through each.
In the same release, Keycloak 26.7.2 closed six more vulnerabilities, including CVE-2026-15571 (CVSS 7.3, HIGH) - predictable hash when linking accounts, allowing account takeover through malicious OIDC-client (CWE-341, Predictable from Observable State). If Keycloak is not updated to 26.7.2, not only password reset is vulnerable.
Fingerprinting Keycloak on the pentest: the version can be pulled through /auth/realms/master/.well-known/openid-configuration, HTTP response headers or HTML login page. Next - checking the flow of reset-credentials in Burp Repeater: request a password reset through UI, intercept all requests in Proxy, try to send a request to install a new password without a token from the email. The full-time stream requires a valid action token - if the server accepts the request without it, it is a confirmation of the vulnerability.
CVE password reset 2026: comparison
Parameter CVE-2026-23760 (SmarterMail) CVE-2026-18963 (Keycloak)
CVSS 9.3 (CRITICAL, CVSS 4.0) 9.1 (CRITICAL, CVSS 3.1)
CWE CWE-288 CWE-640
Privileges Not required (PR:N) Not required (PR:N)
Interaction Not required (UI:N) Not required (UI:N)
Vulnerable versions Up to the 9511 build Up to 26.7.2 (upstream)
CISA KEV Yes (ransomware) No
EPSS 0.9654 (Top 1%) 0.0318 (above the median)
Public PoC Yeah Yes (46 stars)
Nuclei template Yeah Yeah
Broken authentication pentest: patterns of attacks on password reset
Specific CVEs are good, but there are also recurring patterns in custom password recovery logic implementations. Three of them I see regularly.
Password reset without verification: leaking the token into the API
This pattern is not tied to a particular CVE - found in custom applications. According to OnSecurity, on the real pentest, the API returned the reset token directly in the JSON response body to the reset request. Attack - two HTTP requests: POST /api/auth/request-password-reset with the victim's email, then POST /api/auth/reset-password with the resulting token and new password. Account takeover without access to mail.
JSON:
{
"message": "If an account exists, you will receive reset instructions.",
"token": "8e8d6a18759f2b06f3ba43b8538c7cf707537d69226cf48f151e0816c2f99291"
}
Translation of the message:
JSON:
{
"token": "8e8d6a18759f2b06f3ba43b8538c7cf707537d69226cf48f151e0816c2f99291"
}
The field message says "get instructions by email" and the token is already in charge. Beautiful fan, and inside - full access. Bonus: if the token is returned only for registered accounts, availability/absence of the field token allows you to list users (username enumeration).
The second subtype is leakage through the API misconfiguration. According to Vaadata, on the pentest of ecommerce-app API comments to the goods returned all the fields of the user-object from the database, including token_reset. The attacker initiated the password reset for the target email, then twitched any endpoint that returns the data of that user, and received a fresh token - along with the password hash and email address.
How to search: in Burp Proxy, examine the body response to each query to /forgot-password, /reset-password and related endpoints. Look for the fields token, reset_token, code, otp, key. Check not only JSON – the token can lie in HTML as hidden input, in the answer headers, or in the redirect URL.
Host header injection reset
The app generates a reset link using the title Host from an HTTP request. If the server does not validate Host - the attacker replaces it with its domain, the victim receives a letter with a link https://attacker.com/reset?token=abc123. Click - and the token flies to the server of the attacking GET-parameter. This is password reset poisoning in a classic form.
Code:
POST /forgot-password HTTP/1.1
Host: attacker.com
Content-Type: application/x-www-form-urlencoded
csrf=qxoCDf28hFqnF2xP6HtGiIhnDFHmryPm&username=carlos
The attack requires the action of the victim (UI:R in CVSS), which reduces the final score compared to UI:N variants. But let's be honest: the percentage of opening letters from a legitimate service is usually high, so UI:R as a mitigating factor is a conditional thing.
Options for bypassing the Host validation in Burp Repeater:
Direct replacement Hostto your domain
Headlines X-Forwarded-Host, X-Forwarded-For, X-Original-URL
Double Host Header - Some Reverse-Proxy Miss Second
Parameters in the query body: according to Vaadata, on one pentest JSON-body contained a parameter baseurl, which directly generated the reset link. Server validation via Python urlparsebypassed the payload format [email protected] the parser took it for the userinfo part of the URL
IDOR in password reset and race condition
IDOR (Insecure Direct Object Reference): take a reset token issued for your account and substitute a foreign password in the request user_id or email. If the server does not check the token binding to a specific user - account takeover. It is checked trivially: two test accounts, one token, identifier substitution in Burp Repeater.
Race condition: via Turbo Intruder, send 20-50 parallel password reset requests for a single account. The goal is to check whether multiple valid tokens are generated simultaneously and whether the old token remains a worker after creating a new one. If yes, the attack window expands, and the disposable token does not actually work. The test takes 5 minutes, but often opens the broken access control in restoring access, which other checks miss.
