A 4.3 that mattered: the 13-day gap between patch and exploitation flag

If your team triages by CVSS score, CVE-2026-32202 sat in the 30-day bucket for nearly two weeks while APT28 used it to steal credentials from government targets. The bug scored 4.3. Microsoft shipped the fix on April 14 with no exploitation flag. CISA added it to KEV on April 28. Thirteen days is a long time when the exploit fires without the user clicking anything.

That gap is the story. Not the vulnerability itself, which is a well-understood NTLM coercion primitive. Not the threat actor, whose playbook here is consistent with years of prior campaigns. The story is what happens when a vendor patches a bug that’s actively exploited and doesn’t say so, and your triage pipeline trusts the vendor’s label.

The obvious read

CVE-2026-32202 is a Windows Shell spoofing vulnerability. A crafted .lnk shortcut file embeds a UNC path in its icon-location field. When a user opens any folder containing that file in Windows Explorer, shell32.dll tries to resolve the icon, opens an outbound SMB connection to the attacker’s server on TCP 445, and hands over the user’s Net-NTLMv2 hash. No click on the file. No prompt. The user navigates to a folder and the hash leaves the machine.

Microsoft patched it in the April 14 cumulative update. CVSS 4.3, medium severity. The advisory carried no “Exploitation Detected” marker. In most organizations, that combination puts it on a routine remediation track.

Then, on April 27, Microsoft revised the advisory to confirm active exploitation. CISA followed the next day with a KEV entry and a May 12 federal deadline. Microsoft hasn’t explained why the flag was initially absent.

The pattern underneath

This CVE is the residue of an incomplete earlier fix. In February 2026, Microsoft patched CVE-2026-21510, a SmartScreen bypass that APT28 had chained with CVE-2026-21513 to achieve remote code execution. The February patch blocked the RCE path by enforcing SmartScreen verification at launch time. But it left the icon-fetching phase unguarded. Akamai researcher Maor Dahan described it as “the gap between path resolution and trust verification.”

So the kill chain adapted. Spearphishing delivered the .lnk file. The original RCE chain was dead, but Explorer still resolved external icon paths without challenge. The attacker didn’t need code execution anymore; they just needed the hash. That campaign, targeting government entities in Ukraine and EU member states with phishing lures impersonating Ukraine’s hydro-meteorological center, had been running since at least December 2025.

This is a pattern that repeats. Check Point Research documented CVE-2025-24054 as a variant of CVE-2024-43451: same NTLM theft outcome, different file format trigger. The fix addresses the specific code path; it doesn’t address the class. And the class is large. Unit 42 documented over 240 untested RPC functions carrying the same coercion primitive across protocols like MS-RPRN (PrinterBug, 2018), MS-EFSRPC (PetitPotam, 2021), MS-DFSNM (DFSCoerce), and MS-FSRVP (ShadowCoerce). Each patch is local. Adjacent functions remain.

Two patches in two months for the same protocol’s coercion surface is either bad luck or a design review that never happened. Microsoft’s own three-phase NTLM deprecation plan, announced in February 2026, suggests they know the answer. Phase 1, currently active, adds enhanced auditing. Phase 2 in the second half of 2026 introduces IAKerb and Local KDC as alternatives. Phase 3 disables NTLM by default in the next major Server release. The deprecation plan is an implicit admission that the protocol can’t be patched into safety.

The evidence on timing

The sequence matters for anyone running a triage model.

April 14: Microsoft ships the fix. Advisory says no exploitation detected. NVD base score: 4.3. In a CVSS-driven queue, this is low priority.

April 27: Microsoft updates the advisory to confirm active exploitation. Thirteen days after the patch was available.

April 28: CISA adds the CVE to KEV with a May 12 remediation deadline.

For those 13 days, the only signal available to most defenders was the CVSS score and the vendor’s own exploitation assessment. Both said this could wait.

This isn’t the first time the pattern has played out. CVE-2024-26234 shipped without an exploitation flag; Sophos later found it was being actively used. CVE-2025-59287, a WSUS vulnerability, had its advisory updated post-release after NCSC identified exploitation. The lag between vendor knowledge and vendor disclosure is a recurring blind spot, and it’s one that score-based triage can’t compensate for because the score itself isn’t the problem. The missing context is.

A compounding factor

There’s a second structural issue that makes this worse going forward. On April 15, 2026, one day after this patch shipped, NIST shifted NVD to risk-based triage. The practical effect: NVD now fully enriches only an estimated 15-20% of CVEs, those already on KEV, federal lists, or covered by EO 14028. The remaining roughly 80% will lack CVSS scores and CPE identifiers entirely.

That means the triage model most organizations rely on, scan for CVEs, check the score, prioritize by severity, is losing coverage on the input side at the same time vendors are demonstrating that their exploitation flags aren’t reliable on the output side. Scanner visibility concentrates on confirmed-exploited CVEs while the blind spots get broader.

What this means for prioritization

A single-signal triage model has known failure modes. This CVE hit two of them simultaneously: a low CVSS score and a missing exploitation flag. Either one alone might not have changed the outcome. Together, they pushed an actively exploited zero-click credential theft bug into a routine remediation window.

The minimum viable triage stack needs at least three layers. CVSS provides the technical baseline, what the bug can do in theory. EPSS provides exploitation probability, a statistical estimate of whether it will be used. KEV provides ground truth, confirmation that it already has been. When you’re missing one layer, the other two can sometimes compensate. When you’re missing two, as was the case here for 13 days, the model fails silently. Nothing alerts. Nothing escalates. The bug just sits in the queue.

The operational mitigations for this specific vulnerability are straightforward: apply the April 14 cumulative update (affected versions: Windows 10 1607 through 22H2, Windows 11 23H2 and 26H1, Windows Server 2012 R2 and later), block outbound SMB (TCP 445/139) at the perimeter, enforce SMB signing domain-wide, and enable Extended Protection for Authentication to tie NTLM auth to the TLS channel. Detection options include monitoring for outbound TCP 445 from workstations to non-RFC1918 addresses, Sysmon Event ID 3 from explorer.exe on port 445, and scanning shared drives for .lnk files with external UNC paths.

But the more interesting detail isn’t the remediation. It’s that this bug was patchable on April 14 and most defenders had no reason to prioritize it until April 28.

What to watch

Microsoft’s NTLM deprecation plan has a timeline, but Phase 2 isn’t due until the second half of 2026 and Phase 3 has no firm date. Watch whether the cadence of NTLM coercion CVEs accelerates the deprecation schedule or whether it stays on the original track regardless.

Watch, too, whether NIST’s reduced NVD enrichment changes the lag between patch availability and exploitation confirmation. If fewer CVEs get full analysis, the gap between “patched” and “flagged as exploited” could widen from days to weeks as a baseline, not an exception.

No public proof-of-concept exists for CVE-2026-32202 yet. No IOCs have been published. When either appears, the exploitation surface will expand beyond the targeted government campaigns observed so far. The 13-day gap happened with a sophisticated actor and a narrow target set. The next gap might not be so contained.

PatchDay Alert flags CVEs when the exploitation signal changes, not just when the patch ships. That distinction mattered here by about two weeks.