Safeguard
Vulnerability Analysis•

SharePoint CVE-2026-65660: The \"Spoofing\" Bug Now Exploited as RCE

Microsoft first listed CVE-2026-65660 as a 6.5 spoofing flaw. It is an 8.8 code injection bug, attackers are chaining it pre-auth, and CISA added it to KEV on 25 September.

Safeguard Security Team
6 min read

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:

ProductFixed buildKB
SharePoint Server Subscription Edition16.0.19725.20522KB5002893
SharePoint Server 201916.0.10417.20198KB5002894, KB5002896
SharePoint Enterprise Server 201616.0.5565.1001KB5002905, 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.aspx and /_layouts/15/designgallery.aspx, plus variants with an extra /_layouts/ prefix.
  • The query string was job=all&DisplayMode=Edit and the form fields were MSOTlPn_Uri and MSOTlPn_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.dll with an AES decrypt and Assembly.Load routine.

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

  1. 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.
  2. Confirm the June 2026 update is also installed. It closes the anonymous delivery path that turns this into pre-auth RCE.
  3. Turn off anonymous access on any web application or site that does not need it.
  4. Run the log and file checks above across the full retention window, not just since 24 September.
  5. If you find sphealth.aspx or a POST with DisplayMode=Edit to AddGallery.aspx that 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.
  6. 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

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.