Hunt SharePoint CVE-2026-65660: the spoofing label that was code execution


Microsoft shipped CVE-2026-65660 in August as a moderate spoofing advisory, CVSS 6.5, with no impact to integrity or availability. Anyone triaging by the MSRC title saw a mid-severity label and moved on, which is the reasonable thing to do with a spoofing bug. Then Viettel published how the same flaw lets an authenticated low-privilege user reach remote code execution through SafeControls quote injection on ToolPane Register directives, and the CVE record was rewritten as remote code execution at 8.8. CISA added it to the Known Exploited Vulnerabilities catalog on 25 September 2026 with a 28 September due date and forensic triage required under BOD 26-04, and Microsoft's revision that day cites reliable evidence of observed attacks. That deadline has now passed. If your farm skipped the 11 August update because the advisory said spoofing, the question is no longer whether to patch.
For on-prem SharePoint farms, the practical questions are:
Are SharePoint Server 2016, 2019, or Subscription Edition builds still below the August 11 patched floors?
Which sites still allow anonymous page access, and did those hosts miss the June 9 authentication-bypass patch?
Who can edit web parts or ToolPane surfaces, and which recent markup changes look unusual?
After suspicious web-part activity, did SharePoint worker processes load unexpected assemblies or did identities escalate on the farm?
How the attack works
On-prem SharePoint as the trust boundary
SharePoint Server 2016, 2019, and Subscription Edition still sit on plenty of estates, usually with authenticated low-privilege users and, on some sites, anonymous page access. SharePoint Online is not listed among the MSRC remediations for this CVE, so this is an on-prem problem specifically. What matters is the boundary that the farm represents: an identity that can reach web-part editing surfaces, in front of a server still running the vulnerable SafeControls check. Khoa also notes that out-of-support SharePoint 2013 is affected, which is worth saying out loud, because the farms most likely to still be running 2013 are the ones least likely to be reading advisories.
SafeControls check and quote injection
Viettel Cyber Security researcher Dinh Ho Anh Khoa published the mechanism through The Hacker News on 22 September 2026. When ToolPane processes web-part markup, SharePoint reconstructs Register directives by writing attribute values between double quotes without escaping quotes inside those values. An attacker who injects additional directives after the type check but before the control loads can register arbitrary .NET classes that SafeControls was supposed to block. The failure is in the sequencing between check and load, not a missing authentication gate by itself.
Code execution path
Once arbitrary class loading is available, XamlServices.Parse can trigger deserialization-style code execution, and Khoa demonstrated an in-memory webshell class path that sidesteps some of the permission failures other deserialization methods run into on disk. That last detail sets the detection shape. You are looking for worker-process behaviour and unexpected assemblies, not a tidy file drop you can grep for.
Khoa separately showed a chain with an already-patched authentication bypass, CVE-2026-55040. On a server that still permits anonymous page access and never took the 9 June fix, the same SafeControls issue becomes pre-authentication remote code execution, while a server that applied that June patch is not exposed to the pre-auth path at all. So treat this as configuration debt sitting beside the 11 August RCE fix rather than as a second incident, and do not read a missing June patch as proof that anything actually happened.
KEV add on 25 September
CISA added CVE-2026-65660 to KEV on 25 September 2026 with remediation due 28 September 2026. BOD 26-04 requires Federal Civilian Executive Branch agencies to prioritize KEV items and to check whether threat actors compromised the system before the patch landed. Public write-ups from 22 September still said in-the-wild use was unreported at that earlier moment. Treat the KEV date and Microsoft's 25 September exploitation note as the prioritization signal now, not the earlier "unlikely" language on the first advisory revision.
Risk: on-prem SharePoint behind a spoofing label
When authenticated low-privilege access turns into code execution on SharePoint, you are not looking at one compromised page. You are looking at site control, webshell persistence that may never touch disk, and a pivot into the farm and the identity stores behind it. The estates furthest behind here are the ones that read the August advisory, saw the word spoofing, and scheduled the update for a quieter month. Scope stays on-prem SharePoint, still running below the patched builds.
Impact areas to investigate, without claiming every farm saw all of them:
Markup and web-part integrity on sites where low-priv users can edit ToolPane surfaces.
Persistence through in-memory or unexpected assembly load in w3wp or SharePoint workers.
Credential and service-account use that extends beyond the SharePoint host after suspicious web-part activity.
Availability hits if an attacker changes permissions, pages, or service configuration while present.
Start with ownership, because scope is an org-chart question before it is a SIEM question: who runs the farm, which sites allow anonymous access, which identities can edit web parts, and which identity providers or file shares that farm can reach. Answer those four, and you have your incident scope before anyone pastes a query.
Mitigate and reduce risk
Apply the August 11, 2026, SharePoint security updates and verify builds are not below the MSRC FixedBuild floors:
SharePoint Enterprise Server 2016: 16.0.5565.1001 or later (KB5002905 / KB5002906)
SharePoint Server 2019: 16.0.10417.20198 or later (KB5002894 / KB5002896)
SharePoint Server Subscription Edition: 16.0.19725.20522 or later (KB5002893)
Confirm the vulnerable function is off by default after the August patch, per the researcher's guidance. Ensure the June 9 authentication-bypass patch is present so anonymous pre-auth chains stay closed. Follow CISA BOD 26-04 forensic triage expectations for KEV SharePoint entries where they apply to your sector. Restrict who can edit web parts and ToolPane surfaces, and review recent web-part markup changes before you declare the window clean.
An upgrade remediates the vulnerable software and nothing else. The investigation still has to establish what happened on hosts that sat exposed before the build floor moved, and that is a different piece of work with a different owner.
How to hunt the activity
Hunt this as a chain, because no single link in it looks alarming on its own: a mislabeled spoofing advisory, SafeControls quote injection on ToolPane Register handling, an authenticated low-privilege user reaching code execution through XamlServices.Parse and an in-memory webshell class, and then KEV urgency arriving on 25 September with BOD 26-04 triage attached. Name the artifact before anyone escalates. That means a build below the August floors, unusual ToolPane or web-part editing activity, or worker-process behaviour that nothing in change management explains.
Field mapping, false positives, and empty results
Field mapping: validate which fields actually hold the build version, request path, actor, and worker-process lines before you trust a negative result, and confirm that your IIS, ULS, and endpoint ingest genuinely cover the on-prem farms. Plenty of estates monitor SharePoint Online closely and collect almost nothing from the server sitting in their own data centre.
False positives: legitimate web-part packaging and ordinary admin markup edits generate exactly this kind of noise, so a single ToolPane POST proves nothing on its own. Require correlation across the build inventory, the request anomaly, and some process or identity follow-on before anyone calls it a compromise.
Empty results: an empty SIEM search may simply mean the organisation is SharePoint Online only, or already patched, and both are fine answers. What it is not is a substitute for a build inventory, because the farm you forgot about is also the farm that sends no logs. Empty means not seen in the telemetry you collected, which is a different claim from proven absent.
Hunt in KQL
// Inventory signal: pull SharePoint host inventory from CMDB/asset tables you already ingest.
// Replace InventoryTable / BuildVersion field names with your estate schema.
InventoryTable
| where TimeGenerated >= ago(14d)
| where Product has_any ("SharePoint Server", "SharePoint Enterprise", "Subscription Edition")
| extend BuildVersion = tostring(BuildVersion)
| where BuildVersion !startswith "16.0.19725.20522"
and BuildVersion !startswith "16.0.10417.20198"
and BuildVersion !startswith "16.0.5565.1001"
| project TimeGenerated, Hostname, Product, BuildVersion, Owner
| take 500// IIS / ULS style HTTP: ToolPane and web-part markup posts from authenticated low-priv actors
CommonSecurityLog
| where TimeGenerated >= datetime(2026-09-20)
| where RequestMethod =~ "POST"
| where RequestURL has_any ("ToolPane", "toolpane", "_layouts", "WebPart", "webpart")
| project TimeGenerated, DestinationHostName, SourceIP, SourceUserName,
RequestMethod, RequestURL, RequestClientApplication, DeviceAction
| order by TimeGenerated asc
| take 500// Process: SharePoint worker loading unexpected context near web-part activity
DeviceProcessEvents
| where Timestamp >= datetime(2026-09-20)
| where FileName =~ "w3wp.exe" or InitiatingProcessFileName =~ "w3wp.exe"
| where ProcessCommandLine has_any ("SharePoint", "Xaml", "SafeControl", "ToolPane")
or FolderPath has "SharePoint"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessCommandLine
| take 500Hunt in Falcon CQL
// Process evidence on SharePoint hosts: w3wp and unexpected loaders
event_simpleName=ProcessRollup2
| event_time>=2026-09-20
| (ImageFileName=*w3wp.exe* OR ParentBaseFileName=*w3wp*)
| (CommandLine=*SharePoint* OR CommandLine=*ToolPane* OR CommandLine=*Xaml* OR CommandLine=*SafeControl* OR CommandLine=*WebPart*)
| table event_time, ComputerName, UserName, ImageFileName, CommandLine, ParentBaseFileName// Identity follow-on on the same hosts after suspicious web-part windows
event_simpleName=UserLogon OR event_simpleName=ProcessRollup2
| event_time>=2026-09-20
| ComputerName=/sharepoint|sp-|wfe|app-/i
| table event_time, ComputerName, UserName, event_simpleName, ImageFileName, CommandLineHunt in Splunk
index=* (sourcetype=*iis* OR sourcetype=*sharepoint* OR sourcetype=*uls*)
(ToolPane OR toolpane OR WebPart OR webpart OR "_layouts")
earliest=09/20/2026:00:00:00
| eval method=upper(coalesce(http_method, method, request_method, cs_method))
| eval path=coalesce(uri_path, uri, url, http_uri, cs_uri_stem)
| eval client=coalesce(src_ip, src, clientip, client_ip, c_ip)
| eval actor=coalesce(user, user_name, username, cs_username)
| where method="POST"
| table _time, host, client, actor, method, path, status
| sort 0 _timeindex=* (sourcetype=*win* OR sourcetype=*sysmon* OR sourcetype=*process*)
(w3wp.exe AND (SharePoint OR ToolPane OR Xaml OR SafeControl OR WebPart))
earliest=09/20/2026:00:00:00
| table _time, host, user, process_name, parent_process, CommandLine
| sort 0 _timeLook for authenticated low-priv POST spikes to ToolPane or web-part endpoints from about 25 September onward, then pivot the same host into process and identity evidence.
Hunt in Kibana / Elastic
// Discover: ToolPane / web-part POSTs and SharePoint worker context since 2026-09-20
@timestamp >= "2026-09-20" AND (
url.path: (*ToolPane* OR *toolpane* OR *WebPart* OR *_layouts*)
OR message: (*ToolPane* OR *SafeControl* OR *XamlServices* OR *Register*)
OR process.name: "w3wp.exe"
)
AND http.request.method: POST// Lens assist: burst detection, then return to events
filters:
- query_string: "ToolPane OR WebPart OR w3wp OR SharePoint"
date histogram: @timestamp from 2026-09-20
terms: host.name, user.name, url.path
metric: countInterpret the results before escalating
Finding | Next investigative step |
Build below 16.0.5565.1001 / 16.0.10417.20198 / 16.0.19725.20522 | Patch to August 11 floors; preserve IIS/ULS and host telemetry before reboot if compromise is suspected. |
Unusual ToolPane or web-part POST by low-priv identity | Diff markup change history; confirm whether an approved edit explains it. |
w3wp loading unexpected assemblies or in-memory webshell-class behavior | Isolate the worker host; capture memory and module lists; do not rely on disk-only IOC sweeps. |
New local admin or odd SharePoint service-account use after web-part anomalies | Trace lateral movement from the farm; rotate affected credentials with owners. |
Anonymous site plus missing June 9 bypass patch | Close anonymous exposure; apply bypass patch; treat pre-auth path as configuration debt to verify. |
Empty SIEM searches | Validate IIS/ULS and endpoint ingest; still complete build inventory. Online-only estates are out of this CVE's MSRC product list, but confirm that claim in asset data. |
Avoid escalating solely on a single legitimate web-part edit or an admin packaging event. Require the correlated chain.
Sources
CISA: Known Exploited Vulnerabilities Catalog (CVE-2026-65660 dateAdded 2026-09-25)
CISA: Adds Two Known Exploited Vulnerabilities to Catalog (2026-09-25)
MSRC: CVE-2026-65660 (FixedBuild floors from August 2026 CVRF; exploitation note 2026-09-25)
The Hacker News: SharePoint flaw initially listed as spoofing (2026-09-22, Viettel / Dinh Ho Anh Khoa)
The Hacker News: SharePoint RCE and MikroTik RouterOS flaws in KEV (2026-09-26 amplify)
What This Means for Your Team
This case does not open on a fresh zero-day headline. It opens on a word. A spoofing label delayed an August patch, SafeControls quote injection turned an authenticated low-privilege user into code execution, and CISA then put a 28 September clock on forensic triage. If your farm still sits below the 11 August build floors or still allows anonymous page access without the 9 June bypass patch, pull the build inventory and the ToolPane activity now. And be realistic about what you will find, because most teams cannot answer the before-the-patch question at all: ULS logs were never forwarded anywhere, IIS retention is seven days, and nobody has ever looked at a web-part edit on that farm. That is not the same as concluding nothing happened. It is discovering you have no way to tell, which is a worse sentence to say out loud and a much better one to say early.
Inception Protection
Inception Protection is Inception Security's MDR on the Microsoft Defender and Sentinel stack, which many teams already license. For CVE-2026-65660, we hunt on-prem SharePoint build inventory against the August floors, IIS, and ULS ToolPane or web-part anomalies, unexpected assemblies, and in-memory webshell-class behavior in SharePoint workers, and identity follow-on from the farm, while you patch, close anonymous pre-auth gaps, and complete BOD-aligned triage where required.
Inception Foresight
Want to see where your environment stands against on-prem SharePoint exposure that a spoofing label can hide until KEV forces the clock, not just the cloud apps you already monitor? Grab our free Inception Foresight. No strings. If this is useful, follow Inception Security on LinkedIn and @inceptionsec on X.



