You patched SharePoint. They're still inside.

Here's the trap in this month's SharePoint emergency: you can patch every server, close every listed CVE, and still be owned. Because the attackers didn't just walk through the door — on the way in, they copied your keys.

That's the detail most of the "patch now" coverage buries, and it's the one that decides whether you're actually safe or just feel safe.

What's being exploited

Through mid-July 2026, CISA flagged active exploitation of a cluster of on-premises SharePoint Server flaws — including the zero-day CVE-2026-58644, exploited before a fix existed, alongside CVE-2026-56164, CVE-2026-45659, and CVE-2026-32201. They affect all supported on-prem versions: Subscription Edition, 2019, and 2016. Chained together, they give an unauthenticated attacker remote code execution on the server — and then the real objective: stealing the IIS/ASP.NET machine keys.

The mechanical fingerprint matches the ToolShell campaign of July 2025, when nation-state actors and a ransomware crew exploited SharePoint at scale across finance, healthcare, government, and energy. Same playbook, new CVEs. CISA issued a hardening advisory on July 14 and added the flaws to its Known Exploited Vulnerabilities catalog on July 16.

Why stealing the keys changes everything

SharePoint runs on ASP.NET, and ASP.NET uses cryptographic machine keys to sign and validate things like the __VIEWSTATE data that rides along with page requests. If an attacker steals those keys, they can forge their own perfectly valid, signed payloads — which SharePoint will trust and execute. In practice: authenticated remote code execution, on demand, whenever they want.

Now put that next to patching. Applying the update closes the vulnerability they used to get in. It does nothing about the keys they already copied. The door is fixed; the locks are unchanged; and the attacker is holding a duplicate. This is why the official guidance isn't just "patch" — it's patch, then rotate the machine keys, then hunt for the persistence they planted. Skip those last two steps and your fully-patched, "remediated" SharePoint server is still quietly serving an intruder.

A patch closes the vulnerability. It doesn't evict the attacker. When persistence is a forged-but-valid request, "we patched it" and "we're clean" are two very different claims.

The reason this hides so well

Post-exploitation via stolen keys is nearly invisible to the tools built to catch break-ins. There's no exploit to detect anymore — the attacker's requests are cryptographically valid and authenticated. They look like legitimate SharePoint traffic because, as far as the server is concerned, they are. The web shell dropped during initial access blends into IIS. The persistence blends into normal operation.

The evidence still exists — it's just scattered and quiet: the anomalous IIS worker behavior during initial exploitation, the machine-key access, a new file where none belongs, an authenticated action that doesn't match how the account actually behaves. Individually, each is a low-signal event a stretched SOC will wave through. The compromise only becomes obvious when you assemble them into a sequence — which is exactly the work that doesn't happen fast enough by hand.

Catching the persistence the patch leaves behind

This is where making sense of the noise beats chasing individual alerts. n0limit investigates every one of those signals the moment it appears — the exploitation attempt, the key access, the web shell, the too-perfect authenticated request — and correlates them across the estate into a single verdict in under 500 microseconds, with a reasoning trail an operator can audit. A forged request that's valid but contradicts everything known about the user doesn't get filed under "normal SharePoint traffic." It gets surfaced as the persistence it is.

The lesson of this SharePoint round is bigger than one product. Modern intrusions don't end when you patch — they persist in signals that look legitimate, waiting. The defenders who stay safe aren't the ones who patched fastest. They're the ones who can still see the attacker after the patch — by correlating the quiet evidence at machine speed, and knowing it's an intruder even when every request checks out.