If you still measure patching urgency in months, the calendar just moved again. On September 25, 2026, CISA added CVE-2026-65660, a code execution flaw in Microsoft SharePoint Server, to its Known Exploited Vulnerabilities catalog, giving federal civilian agencies a remediation deadline of September 28. Three days’ notice. And the flaw had been patched since August.

That sequence of patch first, details later, then exploitation almost immediately is no longer the exception. It’s becoming the standard lifecycle of a serious enterprise vulnerability, and it changes what a workable patching program looks like for organizations of every size.

What happened with CVE-2026-65660

The short version, based on Microsoft’s advisory and reporting from SecurityWeek and threat-intelligence firm Previdian:

  • August 2026: Microsoft patches the flaw. CVE-2026-65660 was originally described as a spoofing issue; Microsoft later updated the advisory to reflect that it could be abused for far more: authenticated attackers with low-level access could achieve remote code execution.
  • September 24: After researchers published technical details, exploitation attempts began appearing in the wild. Previdian (formerly KEVIntel) observed attackers chaining CVE-2026-65660 with a separate anonymous delivery bug to deliver an encrypted loader to compromised SharePoint servers.
  • September 24 and 25: Attempted webshell backdoor installations were observed on targeted servers.
  • September 25: Microsoft updated its advisory to confirm reliable evidence of active attacks. CISA added the CVE to the KEV catalog the same day.
  • September 28: Federal deadline to remediate under Binding Operational Directive 26-04.

Notice the pattern inside the pattern: the exploit chain didn’t rely on one bug. It combined an authenticated code execution flaw with a separate anonymous delivery mechanism. Patching one while ignoring the other leaves you exposed. Attackers increasingly buy, borrow, or build the missing piece.

Why “we patch on our schedule” no longer works

For years, the industry treated patch-to-exploit gaps as a comfortable buffer. Historic averages stretched into weeks or months. That buffer has collapsed for one simple reason: vulnerability research is now industrialized.

When researchers publish technical details, as the original reporters and Viettel Security did here, that disclosure is instantly convertible into working exploit code. Scripts appear on GitHub within hours. Ransomware crews and access brokers watch the same disclosures you do, and they move faster than your monthly patch cycle.

The practical consequence: the moment details go public on a known-patched vulnerability, your exposure clock starts in days, not months. CISA’s three-day federal deadline isn’t bureaucracy; it’s a realistic reflection of how quickly exploitation follows disclosure.

What a modern patching discipline looks like

You don’t need to panic-patch everything. You need a triage system that recognizes when a specific patch jumps the queue. Here’s the framework I recommend to clients:

1. Watch the KEV catalog like a stock ticker

CISA’s Known Exploited Vulnerabilities catalog is the single highest-signal feed in vulnerability management. If a flaw lands in KEV, it’s not theoretical. Someone is using it. Make “is it in KEV?” your first triage question, and treat KEV additions as same-week (ideally same-day) patching triggers regardless of your normal cycle.

2. Patch within 72 hours when KEV and your stack intersect

The federal standard under BOD 26-04 is a useful benchmark for everyone: when a KEV-listed flaw affects your environment, your window should be measured in days. For internet-facing systems like SharePoint, Exchange, VPN appliances, and firewalls, the window should be even shorter, because those are precisely what attackers scan for at scale.

3. Assume chaining: patch the whole chain, not the headline CVE

The SharePoint attacks combined an authenticated RCE with an anonymous delivery bug. When a threat advisory describes an exploit chain, verify that every component of the chain is patched in your environment. A partial patch is often no patch at all.

4. Hunt for prior compromise before you celebrate the patch

Exploitation attempts were observed before CISA’s catalog entry and before many organizations would have heard about the issue. If a vulnerability was patched in August and exploited in September, anyone running the vulnerable version during that window needs to check for webshells, unexpected scheduled tasks, and anomalous service accounts, not just apply the update and move on. Patching closes the door; it doesn’t evict whoever is already inside.

5. Inventory is the real bottleneck

Every one of these steps depends on knowing where SharePoint (or any affected product) actually runs, including the forgotten staging server nobody remembers. If your asset inventory is a spreadsheet last touched last year, that’s the gap to fix first. You cannot patch in 72 hours what you cannot find in 72 minutes.

The takeaway

CVE-2026-65660 is a SharePoint story, but the lesson is generic: disclosure is the starting gun, not the finish line. The organizations that come out ahead aren’t the ones with the biggest security budgets. They’re the ones with the shortest distance between “KEV entry published” and “patch deployed, compromise ruled out.”

If your patch cycle is still monthly, you’re not late. You’re just running a race that’s now timed in days. Shrink the loop for the vulnerabilities that matter (actively exploited, internet-facing, chainable) and let everything else stay on the regular schedule.

Need help pressure-testing your patch and response process? That’s the work I do every day. Reach out via the contact page.