Patching a server does not mean the attacker who was already inside packed up and left.

That’s the uncomfortable lesson buried in this week’s advisories, and it’s one a lot of cybersecurity teams are still missing. CISA’s latest alert on Microsoft SharePoint Server makes the point explicitly: you can ship every fix Microsoft releases and still have someone else’s hands on your infrastructure, because the vulnerability was never the whole problem. It was just the door.

The Patch Didn’t Evict Anyone

On July 14, CISA confirmed active exploitation of three on-premises SharePoint Server flaws, CVE-2026-32201, CVE-2026-45659, and CVE-2026-56164. Two more, CVE-2026-55040 and CVE-2026-58644, dropped the same day as part of Microsoft’s July Patch Tuesday. By July 15, Microsoft had confirmed CVE-2026-58644 was already being exploited too. Five holes, four of them actively used, all in software organizations have been running in production for a decade.

Here’s the part that should worry you more than the CVSS scores. Attackers chained the three actively exploited bugs to get in, then went straight for the IIS machine keys, the cryptographic material SharePoint uses to sign and validate requests. Once those keys are stolen, an attacker can forge valid requests against your server long after you’ve applied the patch. CISA’s advisory says it plainly: rotating those keys is not a complete remediation unless you’ve also found and removed whatever the attacker planted while they had access. Patch the vulnerability, skip the hunt, and you’ve secured a house whose spare key is already in someone else’s pocket.

Cybersecurity Runs On A Patch Tuesday Myth

Talos put it well in their own writeup this week: the patch wars have begun, and it’s a doozy. July’s Patch Tuesday alone covered 569 CVEs. Nobody’s triage team is closing that gap in a day, and the SharePoint chain is a case study in what happens in the meantime.

Most security programs still measure success by patch percentage. Dashboards show green when the update deploys. Compliance frameworks check the box the moment the version number changes. But a patched CVE tells you nothing about whether the attacker who exploited it last week is still sitting on your network with a stolen key and a webshell nobody’s found yet.

It gets worse once you leave the Windows server world. SecurityWeek’s look at operational technology this week is a reminder that huge swaths of critical infrastructure can’t be patched on any reasonable timeline at all. Legacy industrial control systems, safety certification requirements, vendors who stopped supporting a platform years ago. For those environments, “just patch it” was never a real option, which means whatever compensating controls you’d throw at an unpatchable OT asset are exactly the controls a patched-but-still-compromised SharePoint server needs too.

Patching is necessary. It’s just never been sufficient, and treating it as the finish line is how organizations end up re-compromised by the same actor two weeks after the fix shipped.

What Actually Gets Them Out

If you’re running on-premises SharePoint, or honestly any internet-facing server that’s had a critical RCE disclosed against it recently, patching is step one of a longer list, not the whole list.

• Rotate machine keys and cryptographic secrets, but only after you’ve hunted for webshells, scheduled tasks, and other persistence artifacts, key rotation alone leaves backdoors intact
• Enable AMSI integration on SharePoint and IIS worker processes, and set request body scanning to full so malicious POST payloads actually get inspected
• Pull SharePoint Central Administration and any other admin interface off direct internet exposure entirely
• Rate-limit and lock out brute-force login attempts against every exposed admin portal, not just the ones you remember exist
• Feed IIS and SharePoint logs into your threat detection pipeline and actively hunt for anomalous worker-process behavior instead of waiting for a single alert to fire
• For legacy or OT systems that genuinely can’t be patched, apply network segmentation and strict allow-listing as your primary control, not a stopgap

Security hardening and threat-protection tooling matter here, but the sequencing matters more. Incident response has to run in parallel with patch deployment, not after it. Defense in depth isn’t a slogan for procurement meetings, it’s the only thing standing between a patched CVE and a still-compromised server. Treat the patch as evidence you closed the door, not proof the intruder walked back out.

Sources

• CVE-2026-32201, CVE-2026-45659, CVE-2026-56164: Frequently Asked Questions About Active Exploitation of Microsoft SharePoint Server Vulnerabilities
• Begun, the Patch Wars have
• Legacy Systems, Real-World Impacts: The Reality of OT Security