HIGH: Microsoft SharePoint CVE-2026-65660 Now Exploited in the Wild

Six weeks. That is how long it took for a SharePoint bug Microsoft originally filed under "spoofing" to graduate into a confirmed, in-the-wild remote code execution problem. If your patch prioritization leaned on Microsoft's own severity label back in August, you were told this one could wait. It could not.

On September 25, 2026, Microsoft updated its guidance for CVE-2026-65660 to state that it had reliable evidence of observed attacks exploiting the flaw, and CISA added it to the Known Exploited Vulnerabilities catalog the same day. Federal civilian agencies have until September 28 to remediate, which is a remarkably short fuse even by KEV standards and tells you how seriously CISA is taking it. Everyone else running SharePoint on premises should treat that date as their deadline too.

From Spoofing to Code Execution

The story of CVE-2026-65660 is a textbook case of why the vulnerability class printed on an advisory is only the opening bid. When Microsoft shipped the fix in its August 11, 2026 security updates, the advisory described a flaw that allowed "an authorized attacker to perform spoofing," scored it at 6.5, and assigned no impact to integrity or availability. That is exactly the kind of entry that gets pushed into next month's maintenance window by teams already drowning in Patch Tuesday volume.

The tell was sitting in plain sight. Both Microsoft's advisory and the National Vulnerability Database tagged the bug as CWE-94, which is code injection. Code injection and "spoofing only" do not belong in the same sentence. Microsoft's separately published CVE record was updated on September 11 to call it a remote code execution vulnerability that allows an authorized attacker to execute code over a network, and NVD scored it at 8.8. By then a detailed technical writeup was already public, and the gap between "researchers understand this" and "criminals are using this" closed about as fast as it always does.

The discovery is credited to Dinh Ho Anh Khoa of Viettel Cyber Security, a name SharePoint administrators should already recognize. He is the researcher who demonstrated the ToolShell exploit chain at Pwn2Own Berlin in May 2025, the work that preceded one of the ugliest on-premises SharePoint compromise waves in recent memory. When that particular researcher publishes a SharePoint writeup, a lot of people read it very carefully, and not all of them are defenders.

What the Flaw Does

At a high level, CVE-2026-65660 is a code injection weakness in on-premises SharePoint Server that lets an authenticated, low-privileged user sidestep one of the platform's server-side safety checks and get arbitrary code running on the SharePoint server itself. The vulnerable path sits in the page editing machinery that handles web parts, which is a feature ordinary site members interact with every day. SharePoint is supposed to strictly limit which server-side components a user can cause to load, and this bug breaks that guarantee.

The practical consequence is that the attacker's code runs inside the SharePoint worker process with that process's identity. On a typical farm that means access to site content, configuration secrets, service account credentials, and a comfortable foothold from which to move laterally into the rest of the Windows estate. Public research also showed that the attack can be carried out in memory, which means the classic "look for a strange .aspx file in the LAYOUTS folder" hunt that worked well during past SharePoint incidents may come up empty.

The "authorized attacker" requirement deserves some honesty. It sounds reassuring until you remember what an authorized SharePoint user actually is. Any employee, contractor, or partner with basic site access qualifies, as does anyone holding a phished credential or a session token lifted by an infostealer. Researchers also noted that the bug could be combined with a separate authentication bypass that Microsoft fixed on June 9, 2026, opening a path to unauthenticated exploitation on farms that allow anonymous page access. If your servers missed the June update as well as the August one, the "needs credentials" caveat may not apply to you at all.

Who Is Affected

Supported versions in scope are SharePoint Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition. Research published on the flaw indicates that SharePoint 2013 is also affected, and since that product fell out of support in April 2023 it will not be getting a fix. Organizations still running 2013 farms are now holding an exploited code execution bug with no patch coming, which is an awkward thing to explain to an auditor or an insurance carrier.

Public reporting centers on the on-premises server products. Microsoft's cloud service is not described as affected, which fits the pattern of recent SharePoint campaigns that have gone after self-hosted farms, particularly those published to the internet for partner collaboration or remote access.

Microsoft has not said who is behind the attacks, how many organizations have been targeted, or what attackers did after gaining access. That silence is frustrating but not surprising this early. Given what happened after ToolShell, when a mix of state-aligned groups and ransomware affiliates piled onto exposed SharePoint servers within days, it would be optimistic to assume this activity stays small or stays in one set of hands.

What To Do Right Now

The first job is simple and non-negotiable. Apply the August 11, 2026 security updates to every SharePoint Server 2016, 2019, and Subscription Edition farm you own or manage, and confirm the June 9 updates are in place as well, since that earlier fix closes the route to unauthenticated abuse. SharePoint patching is notoriously fiddly, so verify that the configuration wizard actually completed on every server in the farm and check the build numbers afterward rather than trusting that the installer finished. A half-applied SharePoint update is a very common and very quiet failure.

If you are stuck on SharePoint 2013, or you cannot patch a supported farm immediately, reduce exposure as aggressively as you can. Pull the farm off the public internet or put it behind a VPN or an authenticating reverse proxy, disable anonymous access, and use a web application firewall to restrict access to administrative and page editing endpoints under the _layouts path to the smallest group of users and networks that genuinely need them. Then start planning a real migration, because compensating controls on an unsupported platform are a bridge, not a destination.

Because exploitation was confirmed after the details went public, patching alone is not the end of the job. Any farm that sat unpatched and reachable between mid-August and today should be treated as potentially compromised until you have looked. Review your SharePoint safe control configuration for entries you did not add, check for unexpected changes to web.config files across the farm, and rotate the machine keys if you find anything suspicious, since stolen keys were exactly how attackers kept access after the ToolShell patches landed.

For detection, the most reliable signal is behavioral. The SharePoint worker process, w3wp.exe, has very little reason to launch cmd.exe, powershell.exe, or other script interpreters, so any EDR alert showing that parent and child relationship on a SharePoint server deserves immediate attention. Researchers also pointed out that healthy farms see very little POST traffic to the web part editing pages under _layouts, so a baseline of that activity in your IIS logs, followed by a review of any spikes or unfamiliar source accounts, is a cheap and effective hunt. Pair that with a look at sign-ins for accounts that rarely touch SharePoint but suddenly started editing pages, which is a good indicator of a stolen credential being put to work.

Finally, take a hard look at your triage process. If CVE-2026-65660 slipped through because it was labeled spoofing, the fix is not to scold whoever made the call. It is to add CWE, exploitability research, and KEV status to the inputs you use for prioritization, and to re-review Microsoft advisories that get revised after release. Vendors reclassify bugs more often than most teams realize, and a changed title on an old CVE is easy to miss.

The Bigger Picture

SharePoint keeps landing on the KEV list because it is the perfect target. It sits at the intersection of sensitive documents, privileged service accounts, and deep Active Directory integration, and it is frequently exposed to the internet because business users want to collaborate with partners without the friction of a VPN. Every on-premises farm is effectively a domain-joined web application full of an organization's most valuable content, and attackers know it.

The more uncomfortable lesson here is about severity labels. A 6.5 spoofing entry does not set off alarms. An 8.8 remote code execution entry with a KEV listing does. Nothing about the underlying bug changed between those two moments, only the description of it. Security teams that rely purely on vendor severity to sort their queue are outsourcing their risk decisions to a text field that can be wrong for weeks.

MSP Angle

Every client still running on-premises SharePoint just handed you a reason to call them this week, so lead with a fixed-price patch verification and compromise assessment and follow it with a SharePoint Online migration proposal, especially for anyone on 2013. Clients who learned about this from the news rather than from you are also good candidates for a managed vulnerability prioritization service that watches KEV additions and advisory revisions, not just Patch Tuesday headlines.