On 25 September 2026 Microsoft updated its advisory for CVE-2026-65660 to say it "had reliable evidence of observed attacks" against the SharePoint Server flaw, and CISA added it to the Known Exploited Vulnerabilities catalog the same day with a federal due date of 28 September. The fix itself is not new. It shipped in the 11 August security updates.
The problem is how the bug was first described. Microsoft's original August record called it a spoofing issue with a CVSS 3.1 score of 6.5. On 27 August Microsoft revised the title, impact and FAQ to remote code execution with a score of 8.8, and labelled that change "informational only". Teams that triaged it in August as a medium spoofing bug may never have looked again.
What's affected
Microsoft's security update table lists three on-premises products. The fixed builds and KB articles are:
| Product | Fixed build | KB |
|---|---|---|
| SharePoint Server Subscription Edition | 16.0.19725.20522 | KB5002893 |
| SharePoint Server 2019 | 16.0.10417.20198 | KB5002894, KB5002896 |
| SharePoint Enterprise Server 2016 | 16.0.5565.1001 | KB5002905, KB5002906 |
Microsoft's FAQ says customers must apply every update listed for their product, in any order, and that the 2016 KB also covers SharePoint Server 2016 (non-Enterprise).
The bug is CWE-94, code injection. Microsoft rates it CVSS 8.8 with PR:L: an attacker needs a low-privileged account and no user interaction. Viettel Cyber Security researcher Dinh Ho Anh Khoa published the technical details on 22 September. The flaw sits in how the ToolPane component rebuilds Register directives when it checks web part markup against the SafeControls list. Attribute values are written between double quotes without escaping quotes inside them, so an attacker can inject an extra directive after the type check runs and load a .NET class that should have been blocked.
The researcher also says SharePoint 2013 is affected. That version has been out of support since April 2023 and has no fix.
The pre-auth chain attackers are using
CVE-2026-65660 needs authentication on its own. Viettel's write-up shows it chained with a separate anonymous delivery bug, fixed in a 9 June 2026 update, which let a page in edit mode build a ToolPane without an authentication check. That path only works on sites that allow anonymous viewing.
Previdian captured exactly this chain on a SharePoint honeypot on 24 September. One source sent 12 POST requests across six URL paths, with no cookies and no Authorization header:
- Targets were
/_layouts/15/AddGallery.aspxand/_layouts/15/designgallery.aspx, plus variants with an extra/_layouts/prefix. - The query string was
job=all&DisplayMode=Editand the form fields wereMSOTlPn_UriandMSOTlPn_DWP. - The first body (7,834 bytes) tried to disable a .NET deserialization type check. The second (535,404 bytes) carried a loader assembly named
wt3k3sij.dllwith an AES decrypt andAssembly.Loadroutine.
In a 25 September update Previdian said the exploitation creates a webshell at /_layouts/15/sphealth.aspx. Note that this traffic does not touch ToolPane.aspx, so detections written for last year's ToolShell campaign will miss it.
How to check if you're exposed
First, confirm the build on each farm. From the SharePoint Management Shell:
(Get-SPFarm).BuildVersion
Compare the build to the table above. If any server in the farm is below the fixed build, the farm is exposed.
Second, find web applications that allow anonymous access, since those are reachable by the pre-auth chain:
Get-SPWebApplication | ForEach-Object {
$wa = $_
$wa.IisSettings.Keys | ForEach-Object {
[pscustomobject]@{ Url = $wa.Url; Zone = $_; Anonymous = $wa.IisSettings[$_].AllowAnonymous }
}
}
Third, search IIS logs for the request pattern Previdian recorded:
Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC*\*.log" `
-Pattern "AddGallery.aspx|designgallery.aspx|sphealth.aspx" |
Where-Object { $_.Line -match "POST" -and $_.Line -match "DisplayMode=Edit" }
Finally, check the layouts folder on every web front end for the webshell file name:
Get-ChildItem "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS" -Filter "sphealth.aspx"
What to do now
- Install every KB listed for your product from the August 2026 release or a later cumulative update, then run the SharePoint Products Configuration Wizard so the farm build actually changes.
- Confirm the June 2026 update is also installed. It closes the anonymous delivery path that turns this into pre-auth RCE.
- Turn off anonymous access on any web application or site that does not need it.
- Run the log and file checks above across the full retention window, not just since 24 September.
- If you find
sphealth.aspxor a POST withDisplayMode=EdittoAddGallery.aspxthat returned 200, treat the server as compromised and follow your incident response process, including rotation of the farm's ASP.NET machine keys once the server is clean. - If you still run SharePoint 2013, plan its removal. There is no patch coming.
Why it matters
This CVE shows the cost of triaging on the first severity label you see. The advisory changed from spoofing to RCE two weeks after release, the change was flagged as informational, and exploitation followed a month later. A process that only reads advisories on Patch Tuesday would not have caught it.
It also shows why chained bugs need their own tracking. Neither half on its own is pre-auth RCE. Together, on a site with anonymous viewing, they are. Your vulnerability records should note which other fixes a CVE depends on, not just its own score.
Try it yourself
Pull the list of CVEs your team rated medium or lower in August 2026 and re-check each against its current vendor record and the KEV catalog. Count how many changed severity or gained a KEV entry since you first triaged them. Then walk through how an exploitability signal changes priority in this demo:
Click through it at your own pace, or open it full screen.
Quick check
Does CVE-2026-65660 need a SharePoint account to exploit?
On its own, yes. Microsoft's FAQ describes an authenticated attacker with low-level access. Attackers are pairing it with an anonymous delivery bug fixed in June 2026, which removes that requirement on sites that allow anonymous viewing.
Is hunting for ToolPane.aspx requests enough?
No. The exploitation Previdian captured targeted AddGallery.aspx and designgallery.aspx with DisplayMode=Edit, not ToolPane.aspx.
When did the fix ship?
11 August 2026. CISA's KEV listing on 25 September added exploitation evidence, not a new patch.
Sources
- Microsoft Security Response Center: CVE-2026-65660
- CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog (25 September 2026)
- CISA Known Exploited Vulnerabilities Catalog
- Viettel Cyber Security: SharePoint CVE-2026-65660, From Anonymous Access to Pre-Auth RCE
- Previdian: CVE-2026-65660 two-stage SharePoint exploitation attempts
- The Hacker News: SharePoint flaw initially listed as spoofing enables authenticated RCE
- NVD: CVE-2026-65660