The Maintenance Window Is Dead. The 24-Hour Clock Won.

There’s a particular kind of dread in a SharePoint server. It sits at the middle of an org like a coat closet everyone throws things into — HR policies, contract drafts, the spreadsheet that quietly runs finance — and it’s usually reachable from more of the network than anyone admits. When a remotely exploitable flaw lands in that box, you don’t have a SharePoint problem. You have a “how much of the company is in that coat closet” problem.

CISA added CVE-2026-65660 to its Known Exploited Vulnerabilities catalog with a federal remediation deadline of September 28, 2026 — today. Active exploitation is confirmed. Federal agencies had, functionally, 24 hours. You are not a federal agency, but attackers don’t check your org chart before scanning your perimeter. The KEV listing is the tell: this is being used in the wild now, not modeled on a whiteboard.

A note on honesty before the list. As of writing, the granular exploitation mechanics aren’t fully public, and I’m not going to invent them to sound authoritative. What matters for you is the shape of the thing: a SharePoint vulnerability serious enough to earn a KEV entry and a same-day federal deadline. Microsoft’s Security Update Guide holds the authoritative affected builds and the exact update packages — check the CVE there for the KB numbers that apply to your farm version, because they differ across SharePoint Server editions and I’m not going to guess a KB and send you chasing a number that doesn’t exist.

Here’s the order I’d work in.

1. Figure out if you’re even in the blast radius — on-prem vs. Online

This is the fork that decides whether your weekend is ruined. SharePoint Online is Microsoft’s server to patch, and they do it centrally, without asking you. If you’re pure SharePoint Online / Microsoft 365, your action here is mostly to confirm that and move on. The pain lives in SharePoint Server on-premises — Subscription Edition and the older Server builds — and in hybrid setups, where an on-prem farm you own is stitched into the cloud. Hybrid is the sneaky one: people mentally file it under “cloud, someone else’s problem” and forget there’s a Windows box in a rack that is very much their problem.

Inventory before you panic. On each SharePoint server:

1
2
3
4
5
6
7
8
9
10
11
12
13

# Run on a SharePoint server. Read-only inventory, no changes.
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
​
$farm = Get-SPFarm
[pscustomobject]@{
    BuildVersion = $farm.BuildVersion
    Servers      = (Get-SPServer | Where-Object Role -ne 'Invalid').Address -join ', '
}
​
# Installed SharePoint patches and their reported build levels
Get-SPProduct | Select-Object ProductName,
    @{n='PatchableUnits';e={$_.PatchableUnitDisplayNames -join '; '}} |
    Format-List

Take that BuildVersion and compare it against the fixed build Microsoft lists for CVE-2026-65660. If your build is below the fixed one, you’re exposed. Don’t eyeball the version in the GUI — the farm build and the per-component patch level can disagree, which is exactly how “we patched that” turns into “we thought we patched that.”

2. Find every SharePoint box, including the one nobody owns

The farm you know about is the easy part. The one that bites you in six months is the dev instance a team stood up in 2021, the one that never made it into the CMDB. If you run Microsoft Defender for Endpoint, ask it what it can actually see rather than trusting the asset spreadsheet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# Defender for Endpoint - Advanced Hunting via Microsoft.Graph.
# Read-only. Surfaces devices running SharePoint components.
Connect-MgGraph -Scopes "ThreatHunting.Read.All"
​
$query = @"
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFolderPath has_any (
    "web services\\root",
    "SharePoint")
    or FileName in~ ("owstimer.exe","wsstracing.exe","noderunner.exe")
| summarize LastSeen=max(Timestamp) by DeviceName, DeviceId
| order by LastSeen desc
"@
​
$body = @{ Query = $query } | ConvertTo-Json
Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/security/runHuntingQuery" `
    -Body $body -ContentType "application/json"

Adjust the process/path indicators to your build. The point isn’t the exact query — it’s the reflex. Trust telemetry over inventory. Shadow SharePoint is where these campaigns get their beachhead.

3. Check what’s reachable from outside before you check anything else

An internal-only SharePoint farm and an internet-facing one are two completely different risk levels, and active exploitation makes exposure the variable that matters most. Confirm which of your farms answer from the public internet:

1
2
3
4
5
6
7
8

#!/usr/bin/env bash
# Reachability check only. No exploitation. Reports which hosts answer.
hosts=("sharepoint.example.com" "portal.example.com")
for h in "${hosts[@]}"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
    --max-time 8 "https://${h}/_layouts/15/start.aspx" 2>/dev/null)
  echo "${h} -> HTTP ${code}"
done

Anything answering with a live response from the outside jumps to the top of your patch queue. A box only your VPN can reach still needs patching, but it buys you hours, not the emergency.

4. Patch — and reboot, because SharePoint patching is a two-act play

Apply the update Microsoft ships for your specific SharePoint Server version, then run the configuration wizard (or PSConfig) across the farm. This is the step people botch. SharePoint patching is binaries and a schema/config upgrade; skip the second act and you get a half-patched farm that reports success and stays vulnerable. It’s like changing the lock but leaving the old key under the mat. Patch every server in the farm — web front ends and app servers — not just the one users hit.

5. If you genuinely can’t patch tonight, buy time with controls

Sometimes there’s a change freeze, or a fragile customization, or a maintenance window that’s three days out. Fine — reduce the attack surface while you wait. Pull internet-facing farms behind the VPN or a WAF and restrict inbound to known ranges. Rotate the machine keys / ASP.NET keys after patching if the vulnerability class touches request handling, so anything stolen pre-patch stops working. Tighten monitoring on those SharePoint process names and on unexpected child processes spawning from w3wp.exe. None of this is a fix. It’s a tourniquet, and you still need the surgery.

6. Assume compromise on anything that was exposed and unpatched

“Active exploitation confirmed” changes the math. If a farm was internet-facing and behind on updates, patching closes the door but doesn’t evict anyone already inside. Hunt for web shells in the SharePoint layouts directories, review IIS logs for anomalous POSTs to admin endpoints, and check for new or modified scheduled tasks and local accounts. Patching a box that’s already been popped just gives you a secured house with the burglar still in it.

If you only do one thing

Find your internet-facing on-prem SharePoint farms and patch them today, wizard included. Everything else on this list is refinement around that single act. SharePoint Online users can exhale; on-prem and hybrid admins have a KEV entry with today’s date on it and adversaries who already know the way in. The scheduled maintenance window was a nice idea. The clock won.