Two CVE listings cover CVE-2026-65660. According to the security advisory from Microsoft, the vulnerability is spoofing, has a score of CVSS 6.5, and no impact on integrity or availability. According to the other CVE listing by Microsoft, dated September 11, 2026, it is remote code execution with a score of 8.8.
Microsoft’s own description reveals the contradiction within the CVE listing. ChatGPT can make mistakes. Check important info. The vulnerability is improperly controlled code generation, CWE-94, and the impact of spoofing via a network by an authorised user.
The Gap Between The Two Labels
Severity is triaged before any other consideration. The vulnerability that is described as “spoofing” without an integrity effect and medium severity gets sorted into a different line than one that is described as “authenticated code execution” at a 8.8 severity level.
None of the characteristics of the vulnerability have changed between the two descriptions. The CVE entry has just been edited.
What is CVE-2026-65660? A code injection flaw in on-premises Microsoft SharePoint Server that lets an authenticated, low-privileged user bypass the SafeControls allowlist and run arbitrary code on the server. Microsoft’s advisory classifies it as spoofing at CVSS 6.5 while the corresponding CVE record classifies it as remote code execution at 8.8. Security updates shipped on August 11, 2026.
What The Flaw Actually Does
SharePoint maintains a whitelist named SafeControls that is supposed to prevent instantiation of any untrusted server-side classes within a page.
Bypass comes from the logic in which the ToolPane component processes web part markup. During reconstruction of Register directives, it puts attribute values in quotes and does not escape quotes inside those values.
Thus, a special value would close the quotes early and append another directive. This additional directive would register any .NET class, and it appears after the allowlist check is performed, but before parsing/loading of the control by ASP.NET.
The allowlist is checked. It is simply checked against markup which will not be used in execution.
From Class Registration To Code Execution
Arbitrary class registration is the primitive. Turning it into execution uses a deserialization chain.
The published technique reaches XamlServices.Parse() by way of ExpandedWrapper generics and ObjectDataProvider, with LosFormatter handling deserialization. Other deserialization routes in SharePoint run into registry permission failures, and this path avoids them.
The demonstrated payload is an in-memory webshell. Nothing is written to the filesystem, so the artefacts a defender would normally hunt for are not produced.
What An Attacker Needs
Exploitation requires authentication, but only at low privilege. The vector is network-based and no user interaction is involved.
A separate weakness in ToolPane authentication could be chained with this one to reach pre-authentication code execution on deployments that permitted anonymous access. Microsoft’s June 2026 update is reported to have closed that route.
Affected products are SharePoint Server 2016, 2019 and Subscription Edition. SharePoint 2013 carries the flaw as well and has been out of support since April 2023, so it receives nothing.
The Patch Shipped Before The Details Did
Security updates landed on August 11, 2026, and the fix disables the vulnerable function by default. Patched builds are 16.0.5565.1001 for 2016, 16.0.10417.20198 for 2019 and 16.0.19725.20522 for Subscription Edition.
Full technical details went public on September 22, 2026, six weeks after the updates. It is demonstrated that the original ToolShell chain at Pwn2Own Berlin in May 2025 and later disclosed CVE-2026-55040, a SharePoint authentication bypass that was exploited in August 2026.
What a CVE Record Tells You, and What It Leaves Out
| Release | Support Status | Security Updates |
|---|---|---|
| SharePoint Server 2013 | Out of support since April 2023 | No |
| SharePoint Server 2016 | Supported | Yes |
| SharePoint Server 2019 | Supported | Yes |
| Subscription Edition | Current, continuously serviced | Yes |
| SharePoint in Microsoft 365 | Vendor-operated service | Patched by the vendor |
The last row is the one that matters: a cloud tenant inherits the vendor’s patch schedule, an on-premises farm inherits its own.
| The weakness | The impact |
|---|---|
| The coding error, such as code injection or improper escaping | What an attacker achieves, such as spoofing or code execution |
| Expressed as a CWE identifier | Expressed as a category plus a CVSS score |
| Usually stable once assigned | Can change as understanding improves |
| Rarely drives triage on its own | Drives triage almost entirely |
| Tells the reader the mechanism | Tells the reader the priority, and nothing about the mechanism |
On-Premises SharePoint Has A Record
One organisation caught in that wave was Switzerland’s federal IT office, which lost roughly 200 accounts to flaws Microsoft had already patched. Patches were available. Deployment had begun. Neither fact arrived early enough.
The pattern repeats because on-premises SharePoint sits where it does. It authenticates against the corporate directory, stores whatever departments put in it, and runs on infrastructure the organisation patches on its own schedule.
Two Failure Modes, One Outcome
Prioritisation runs on vendor-supplied metadata. Most organisations patch by severity because patching everything at once is not available to them, which makes the severity field a control in practice even though it is only a description. When two authoritative records disagree by more than two CVSS points and by category, the field stops being reliable input.
What sits underneath the disagreement is worth naming separately. The flaw works by registering a class the allowlist was written to exclude, and the allowlist still runs. Checking happens at one moment, loading happens at another, and the injected directive occupies the gap between them.
The payload then executes entirely in memory. A file scanner finds nothing because nothing reached disk, and the process doing the work is the SharePoint worker process itself. Recognition-based defence has very little to recognise here. What remains is whether the server is permitted to load and execute a class that nobody sanctioned, at the instant it tries to.
Conclusion: Spoofing on Paper, Code Execution in Practice
CVE-2026-65660 demonstrates why vulnerability metadata cannot be treated as a substitute for understanding technical impact. A flaw described as moderate-severity spoofing presents a very different patching priority from one that allows a low-privileged authenticated user to execute arbitrary code on a SharePoint server. In this case, the underlying mechanics support the latter.
The weakness sits in the boundary SharePoint uses to decide which server-side classes are safe to instantiate. SafeControls still performs its check, but attacker-controlled markup can be altered after that decision and before ASP.NET loads the resulting control. The demonstrated chain turns arbitrary class registration into code execution and can deploy an in-memory webshell without placing a conventional payload on disk.
That makes the classification problem operational rather than semantic. Organizations that prioritize patches from severity and impact fields can make a materially different decision when authoritative records describe the same flaw in different ways.
Why This Threat Matters
- Patch priority depends on accurate metadata. A medium-severity spoofing issue may receive very different treatment from authenticated RCE.
- Low privilege is enough. Exploitation requires authentication, but not administrative access.
- The security check still runs. The flaw succeeds because the object checked is not the same markup ultimately used for execution.
- The demonstrated payload can remain in memory. Traditional file-oriented hunting may therefore have little or nothing to inspect.
- Public exploit details change defensive urgency. Even without confirmed exploitation, defenders now have enough technical information to reproduce the execution path.
Where Defensive Control Must Operate
Xcitium Vulnerability Assessment is the primary control for identifying affected SharePoint systems, prioritizing the August security updates, and verifying that vulnerable builds are no longer exposed.
If exploitation reaches a managed server, Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, provides runtime and post-exploitation visibility. Execution Governance adds a complementary trust boundary when exploitation attempts to turn unauthorized code into executable activity.
Patch by Capability, Not Just the Label
Organizations running SharePoint Server 2016, 2019, or Subscription Edition should verify installation of the August 2026 fixes rather than relying on the original severity label. SharePoint 2013 requires separate attention because it is out of support. Where vulnerable systems were exposed before patching, review authentication and SharePoint telemetry for exploitation attempts and investigate unusual in-memory or worker-process activity rather than limiting the search to files written to disk.
