Windows Shell Patch Bypass: Why April 2026 Updates Matter for NTLM Hash Theft

Terra's numbers have not been independently checked, and the claim that AI is behind the rise is suggested, not shown. The Windows case is well documented, though, and it is the part worth understanding properly.

What Terra says it found​

The Register reports that Terra reviewed published CVE records and GitHub-reviewed security advisories, looking for fixes that later needed another fix. Its main claims:

• A tenfold jump in failed fixes. The share of GitHub security fixes that got a follow-up advisory reporting a failed patch within 90 days sat at about 0.2 percent from 2019 through 2025. In 2026 it reached 2.3 percent.
• Bypassed fixes are more likely to be exploited. Vulnerabilities whose fixes were later bypassed were about four times as likely to land on CISA's Known Exploited Vulnerabilities (KEV) list as other bugs from the same vendors.
• Two bug classes break most often. Compared with their share of all CVEs, prototype-pollution bugs were about 11 times as common among broken fixes, and server-side request forgery (SSRF) bugs 4.6 times as common.
• Kernel fixes cause new kernel bugs. Citing Linux kernel CNA records as of October 8, Terra says 3.2 percent of kernel CVEs were introduced by the fix for another CVE. In busy subsystems such as fs/smb and net/sched, the figure is about 10 percent.

Terra's explanation for the SSRF and prototype-pollution results is simple. Fixes for those bugs often rely on blocklists of bad hostnames, paths or object keys. In the researchers' words, "If the blocklist doesn't foresee every encoding of a bad input, the attacker only needs to find one."

Caveats:

• I could not find a Terra report or dataset to check these figures against, so treat them as Terra's claims as reported by The Register.
• The Register says it is "not a coincidence" that AI-driven vulnerability discovery took off in the same year. Two things rising together does not prove one caused the other.
• Other factors could explain some of the jump: more researchers looking specifically for bypasses, changes in how advisories get filed, or simply more advisories overall.
• None of this has been measured yet. The direction is believable. How much AI contributed is unknown.

In short: Terra reports a roughly tenfold rise in failed fixes in 2026, concentrated in blocklist-style fixes. The numbers are unverified, and the AI explanation is a reasonable guess, not a finding.

The Windows case: CVE-2026-21510 and CVE-2026-32202​

This example is backed by Microsoft, CISA and Akamai's research, not just Terra.

The timeline, per Akamai: "We detected the APT28 (also known as Fancy Bear) exploit in January 2026 and Microsoft patched it on February's Patch Tuesday." The flaw was CVE-2026-21510, a Windows Shell protection-mechanism failure. Akamai says CVE-2026-21513 and CVE-2026-21510 were exploited in the same LNK file and were a crucial part of the exploitation chain. SecurityWeek, citing Akamai, says the bugs were likely exploited by APT28 in December 2025, in attacks against Ukraine and European Union countries.

How the original attack worked. In Akamai's description, "APT28 leverages the Windows shell namespace parsing mechanism to load a dynamic link library (DLL) from a remote server using a UNC path. The DLL is loaded as part of the Control Panel (CPL) objects without proper network zone validation." Put simply, a booby-trapped shortcut convinced Explorer to treat a DLL on an attacker's server as a trusted Control Panel item.

What the February patch fixed. According to Security Boulevard, it addressed the remote code execution component by triggering a SmartScreen check on CPL file signatures and origin zones, but left an authentication coercion gap. Akamai confirms that while Microsoft's fix successfully prevented the initial remote code execution (RCE) and SmartScreen bypass, it left behind a zero-click authentication coercion vulnerability (which is now classified as CVE-2026-32202).

What it missed. The trust check ran too late. One analysis summed it up: the original patch protected the execution boundary but did not initially protect the earlier path-resolution boundary. By the time SmartScreen or another trust decision rejected the remote object, the network connection and authentication attempt could already have occurred. Windows had already contacted the attacker's server before it refused to run anything. That contact included an automatic NTLM handshake, which hands over the user's Net-NTLMv2 hash. Attackers can crack that hash offline or relay it to log in to other systems.

Zero clicks needed. According to TechRepublic, simply browsing to a folder containing a malicious file was now enough to hand over a user's credentials.

The second fix. Akamai found the gap and reported it to Microsoft, who shipped a fix in the April 14, 2026 Patch Tuesday update. Microsoft's advisory flags the security defect as exploited, but does not detail the observed attacks. The advisory was initially published with incorrect severity data. Microsoft later corrected it to confirm active exploitation.

Why the severity score misleads. CVE-2026-32202 is rated only 4.3 under CVSS. As Security Boulevard put it, a CVSS score of 4.3 understates the operational risk here. A stolen hash from a well-placed user can be the first step toward taking over a whole Windows domain.

In short: The February fix stopped code execution, but Windows still connected to the attacker's server first. That leftover behaviour became a separate, exploited zero-click bug that Microsoft fixed in April.

A second example: n8n's XML node​

The problem isn't limited to Windows, and it matches Terra's point about prototype pollution. GitHub's advisory database lists CVE-2026-44791, a critical bypass of an earlier patch in the XML node of the n8n workflow platform:

• Who can exploit it: an authenticated user with permission to create or edit workflows. Combined with other nodes, this could lead to remote code execution on the n8n host.
• Affected versions: below 1.123.43; 2.0.0-rc.0 up to (not including) 2.20.7; and 2.21.0 up to (not including) 2.22.1.
• Fixed versions: 1.123.43, 2.20.7 and 2.22.1.
• Temporary workarounds: limit workflow editing to fully trusted users, or disable the XML node by adding n8n-nodes-base.xml to the NODES_EXCLUDE environment variable. The advisory warns that these workarounds do not fully remove the risk and should only be short-term.

The attacker needs an account first. That matters for prioritising, but in multi-user automation setups it is often easy to satisfy.

What Windows admins should do​

Terra suggests three questions for vendors before shipping a fix: Does it fix the root cause? Does it cover the whole class of bug? Does it break something else? Most admins can't inspect Microsoft's code to answer those, so here is what you can actually do.

1. Confirm the April 2026 cumulative update (or later) is on every machine. If a device has February's update but not April's, it is protected from code execution and still exposed to hash theft.
2. Watch for follow-up advisories. A CVE marked as fixed is not necessarily done. As Security Boulevard noted, the incomplete patch pattern is also worth noting for security teams that treat a CVE's closure as a clean resolution. Keep tracking any exploited CVE for a few months after it's patched.
3. Rank by exploitation, not just CVSS. CVE-2026-32202 shows that a medium score can hide an actively exploited credential-theft bug. Check whether a flaw is on CISA's KEV list before deciding it can wait.
4. Test the whole attack chain, not just the payload. If your post-patch check is "the DLL no longer runs," you would have missed this one. Also watch for outbound connections triggered when a folder is merely opened or rendered.
5. Reduce what NTLM can leak (general good practice, not taken from the advisories above):
   • Block outbound SMB on TCP port 445 at the network edge.
   • Audit NTLM traffic, then restrict it where you can. The relevant Group Policy settings are under "Network security: Restrict NTLM."
   • Put high-value accounts in the Protected Users group.
   • Turn on SMB signing to make relay attacks harder.
   Test each change first. NTLM restrictions are known for breaking older applications.
6. For software vendors and developers: treat blocklists as a temporary measure, not the real fix. Allowlists and fixing the input-handling logic itself hold up better against encoding tricks.

The bigger picture​

Reading patches to find what they missed is not new. "Patch diffing" (comparing code before and after a fix) has been a standard attacker technique since the days of Windows XP updates. What may be changing is the cost. If AI tools make it cheap to compare binaries, generate input variations and test edge cases, a narrow fix can be found and bypassed much faster. That is consistent with Terra's numbers, even though it doesn't prove them.

Terra's own advice is worth keeping: "If a vendor fixes an exploited bug, assume someone is reading the patch for a way around it." For Windows admins, that means installing the update, confirming it actually closed the attack path, and checking back in a few months for a follow-up fix.

Bottom line: Treat Terra's trend as a claim and the AI link as unproven. The Windows Shell case is documented: it was exploited, partly fixed, exploited again, then fully fixed. If any machine has February's update but not April's, fix that first.