Dissecting CVE-2026-32202: The Zero-Click NTLM Leak from an Incomplete Patch
What CVE-2026-32202 Is and Why CISA Flagged It
CVE-2026-32202 is a Windows flaw that leaks NTLM hashes from unpatched systems, and CISA added it to the Known Exploited Vulnerabilities catalog after reports of active abuse.
What makes this worth dissecting is the patch trail, not just the bug class. Akamai tied CVE-2026-32202 to an incomplete fix for CVE-2026-21510, a remote code execution issue Microsoft addressed in February. So this is not just a new bug appearing out of nowhere. It is a gap left behind by a partial remediation.
Microsoft's public wording says an attacker can send a malicious file that the victim has to execute, then “view some sensitive information” on an unpatched machine. Akamai's analysis makes the impact clearer: a leaked NTLM hash can be reused in pass-the-hash attacks.
How the Incomplete Patch Became a New Vulnerability
The relationship to CVE-2026-21510
This is the part I would call out in a report. CVE-2026-32202 does not read like an unrelated Windows flaw. It appears to be leftover behavior from a partial fix for CVE-2026-21510. That pattern shows up often in incident response: one execution path gets closed, but a side effect or alternate path still reaches the same sensitive behavior.
Akamai described CVE-2026-32202 as a zero-click NTLM hash leak, but that needs a small correction. The user still has to execute the malicious file. So “zero-click” here means no extra interaction after execution, not true drive-by compromise.
Why NTLM hash leaks matter to attackers
NTLM hashes are not cleartext passwords, but they are still reusable authentication material. If an attacker gets a hash, they may be able to reuse it against other internal services that still accept NTLM authentication.
That gives you a very ordinary-looking attack chain:
- one user opens a crafted file
- the file coerces Windows into exposing NTLM material
- the attacker reuses the hash elsewhere
- lateral movement starts without the password
That becomes especially useful in mixed environments where legacy auth still exists.
The Zero-Click Part Still Needs a User Action
Malicious file delivery and what actually gets triggered
The delivery step is the real entry point. The source material says the victim must execute a malicious file. That makes email attachments, shared folders, chat-delivered archives, and download links all viable if users can run untrusted content.
In practice, I would test three things first:
- Does the endpoint block the file type at the mail gateway?
- Does the user profile allow execution from common staging locations?
- Does Windows still attempt NTLM-authenticated access when parsing the file?
That last check is where the bug turns into a credential leak instead of a harmless failure.
What the Attack Chain Looks Like in Practice
From leaked hash to pass-the-hash access
Akamai said the flaw can be used in pass-the-hash attacks. That usually means the attacker does not need the password itself. They only need enough NTLM material to authenticate as the victim to something useful.
A simplified chain looks like this:
| Stage | What happens | Defender signal |
|---|---|---|
| Initial access | User runs malicious file | Email, web gateway, or download logs |
| NTLM leak | Windows exposes hash material | Unusual outbound auth behavior |
| Reuse | Attacker authenticates elsewhere | New logon from odd host or subnet |
| Expansion | Attacker uses the account internally | Lateral movement and data access |
Where lateral movement becomes possible
The real damage starts when the leaked identity is trusted in more than one place. If that account can reach file shares, admin consoles, remote management tools, or internal apps with weak segmentation, one leak can turn into broad reach.
That is why NTLM exposure is not just a credential hygiene problem. It is an architectural one.
What CISA's KEV Order Means for Federal Teams
The May 12 deadline and BOD 22-01
CISA ordered Federal Civilian Executive Branch agencies to patch by May 12 under Binding Operational Directive 22-01. That directive forces federal teams to treat KEV-listed bugs as active risk, not as “next patch cycle” material.
CISA also told agencies to apply vendor mitigations or discontinue use of the product if mitigations are unavailable. That is standard KEV language, but it matters here because the vulnerability is already being used in attacks.
Why non-federal teams should still treat it as urgent
Even if BOD 22-01 does not apply to you, the lesson does. KEV entries are a decent predictor of where attackers will spend time. If your Windows estate still lets users execute untrusted files and still relies on NTLM in internal workflows, assume exposure until you prove otherwise.
How to Check Exposure in a Windows Environment
Inventory endpoints, servers, and file delivery paths
Start with the boring list:
- Windows endpoints with user execution rights
- file shares used for inbound content
- mail and chat channels that deliver attachments
- servers that still accept NTLM auth
- remote access surfaces that trust internal hashes
If you cannot answer where untrusted files enter the environment, you are not done.
Look for evidence of NTLM leakage and suspicious file execution
I would review:
- Windows Security logs for odd logon patterns
- process creation logs for execution from downloads or temp paths
- outbound connections that line up with document or archive opening
- authentication attempts from hosts that do not normally originate them
If you have EDR, correlate file execution with subsequent network auth. That pairing is usually where this kind of issue shows up first.
Defensive Steps That Actually Reduce Risk
Patch first, then reduce NTLM exposure
Patch CVE-2026-32202 everywhere you can. Then reduce the blast radius of any future credential leak.
A practical sequence:
- apply the vendor fix
- disable NTLM where your environment allows it
- prefer Kerberos or modern auth paths
- segment admin accounts away from user workstations
If NTLM has to stay, make it an exception, not the default.
Limit user execution paths and quarantine untrusted files
Most of the exploit value depends on user execution. You can weaken that path with:
- attachment filtering
- download quarantine
- application control for common user folders
- blocking scriptable or unpackable file types from external sources
This is not flashy, but it cuts off the easiest delivery routes.
Monitor for credential relay and unusual authentication
Watch for:
- NTLM auth from unusual hosts
- repeated access from a user account to new systems
- remote sessions that do not match normal admin behavior
- authentication after opening inbound files
The sooner you connect file handling to auth anomalies, the faster you can contain a leak.
Conclusion
CVE-2026-32202 is a clean example of why incomplete patches are dangerous. The original issue was supposed to be fixed, but the leftover behavior created a new path to leak NTLM hashes and enable pass-the-hash abuse.
If you run Windows at scale, this is not a theoretical edge case. It is a patch-now item, and a reminder that file execution and legacy authentication still make a very effective combination for attackers.
