Microsoft Called CVE-2026-65660 a Spoofing Bug. It’s an Authenticated SharePoint RCE

A moderation-severity advisory sent defenders to sleep on a flaw that loads arbitrary .NET classes and executes code inside SharePoint worker processes. The full exploit mechanics are now public, and they are uncomfortably elegant.

When Microsoft shipped its August 11, 2026 security updates, CVE-2026-65660 arrived in the advisory bulletin as a spoofing vulnerability in SharePoint Server carrying a CVSS score of 6.5, moderate, no stated impact on integrity or availability, exploitation rated “Less Likely.” For a security team triaging a ninety-plus item Patch Tuesday backlog, that metadata is a one-line verdict: deprioritize. According to full technical details published today by Dinh Ho Anh Khoa of Viettel Cyber Security, that verdict was wrong. The same flaw is an authenticated remote code execution vulnerability that NVD scores at 8.8, and Microsoft’s own CVE record, silently updated on September 11, now titles it exactly that.

The gap between those two classifications is not a cosmetic editorial disagreement. It is the difference between a flaw that nudges an attacker’s presentation layer and a flaw that hands them a fully formed code-loading primitive inside one of the most widely deployed enterprise collaboration platforms on the planet. This analysis breaks down the root cause, walks through the published proof-of-concept capture line by line, reconstructs the gadget chain, and lays out what defenders should do about versions that will never receive a patch.

Key takeaways

• CVE-2026-65660 is authenticated RCE, not spoofing. Microsoft’s advisory rates it 6.5/spoofing; NVD rates it 8.8; Microsoft’s own CVE record, updated September 11, 2026, describes code execution. Both records assign CWE-94 (Code Injection), which was always a hint that “spoofing” undersold it.
• The root cause is a quoting failure in ToolPane. When SharePoint reconstructs Register directives from web part markup, it writes attribute values between double quotes without escaping quotes inside them, letting an attacker splice in additional directives after the SafeControls type check has already run.
• The payload is a XAML deserialization chain. Arbitrary class registration feeds XamlServices.Parse(), with an ObjectDataProvider gadget converting markup into method invocation, culminating in an in-memory web shell that sidesteps the registry permission failures that sink other deserialization approaches on hardened SharePoint farms.
• A pre-auth path existed until June 9, 2026. Chained with a separately patched authentication bypass, the flaw yields unauthenticated RCE on farms permitting anonymous page access. Servers that installed the June update are closed to the pre-auth route but remained fully exposed to authenticated exploitation until August 11.
• SharePoint 2013 is affected and will never be fixed. Microsoft’s advisory lists 2016, 2019, and Subscription Edition; Khoa reports 2013 is vulnerable too, a product that has been out of support since April 2023.
• No wild exploitation is currently reported, and the flaw is absent from CISA’s Known Exploited Vulnerabilities catalog. The complete exploit markup, however, is public, and the researcher confirms using it in live penetration tests.

A severity label that understated the risk

Vulnerability metadata is a triage instrument, and triage instruments that read low produce queues that read low. Defenders who processed CVE-2026-65660 against Microsoft’s August advisory saw an authorized-attacker spoofing issue with zero integrity or availability impact, the class of bug you schedule into a normal change window. The National Vulnerability Database disagreed, publishing a base score of 8.8, and on September 11 Microsoft’s separately maintained CVE record was revised to title the flaw a remote code execution vulnerability allowing “an authorized attacker to execute code.” Tellingly, both the advisory-derived record and the revised record carry CWE-94, the code injection weakness class. Code injection is not a spoofing primitive; it is the primitive from which spoofing, execution, and escalation are all downstream consequences.

None of this changes a single byte of the vulnerability or the patch. What it changes is six weeks of defender behavior: the window between the August 11 fix and the September 22 technical disclosure is a window in which patched fleets and unpatched fleets were separated less by risk appetite than by whether anyone on the team cross-referenced NVD against the bulletin. It also repeats a pattern SharePoint administrators have now lived through twice in eighteen months, a vulnerability whose public classification lagged its real capability until an external researcher published the mechanics.

What breaks: SafeControls, ToolPane, and a quote that never got escaped

SafeControls

SharePoint’s server-side extensibility model is built on ASP.NET web parts and user controls, and because those controls execute server-side code, SharePoint gates them behind the SafeControls list, an allowlist declared in each web application’s web.config that enumerates which assemblies, namespaces, and classes may be instantiated as web parts or user controls. The gate exists precisely because the alternative is arbitrary server-side class loading: any type reachable from the worker process’s binding context becomes a candidate gadget the moment markup can name it. When ToolPane, the editing surface behind web part management pages such as _layouts/15/AddGallery.aspx and _layouts/15/ToolPane.aspx, accepts web part markup, every class reference in that markup is supposed to be validated against SafeControls before anything is instantiated.

check now, load later

Khoa’s write-up locates CVE-2026-65660 in the narrow seam between validation and instantiation. When the ToolPane component processes submitted web part markup, it reconstructs Register directives (the <%@ Register ... %> declarations that map a tag prefix to a namespace and assembly) by writing attacker-influenced attribute values between double quotes. It does not escape double quotes contained inside those values. The consequence is a textbook injection: a value terminating in a quote, followed by directive syntax, closes the legitimate attribute and opens a brand-new Register directive of the attacker’s design.

The ordering is what converts a quoting bug into code execution. The SafeControls type check runs against the markup as submitted; the control load happens later, against the reconstructed directive string. An injected directive therefore never passes through the allowlist evaluation at all. It registers arbitrary .NET classes (any namespace and assembly the worker process can bind) after the check has run and before the control is loaded. The allowlist is not bypassed by trickery against its logic; it is simply never consulted about the second directive, because the second directive does not exist yet at the moment the gate swings shut.

XAML deserialization via XamlServices.Parse

Registering an arbitrary class is capability, not yet compromise; the attacker still needs a loaded type whose behavior converts markup into action. Khoa’s chain reaches for the XAML stack: with class registration under attacker control, the payload invokes XamlServices.Parse(), the System.Xaml entry point that deserializes a XAML document into a live object graph. XAML deserialization is a long-standing member of the .NET gadget canon for the same reason binary formatters are: the serializer faithfully instantiates whatever types the document names, and System.Windows.Data.ObjectDataProvider is the canonical escalation point, because its MethodName, ObjectType, and MethodParameters properties let a document declare “call this method, on this type, with these arguments” and have the deserializer obey at instantiation time. A XAML document is, in effect, a program written in markup, and XamlServices.Parse is its interpreter.

The published write-up includes a working in-memory web shell as the terminal payload, and the choice is deliberate rather than stylistic. Alternative deserialization routes on SharePoint frequently die on filesystem and registry permissions: gadget chains that need to drop artifacts, register persistence, or touch protected hive keys fail against the least-privilege configuration many farms actually run. A reflective, in-memory shell executes entirely within the w3wp.exe worker process address space: no .aspx file on disk for web shell scanners to hash, no registry write for integrity monitoring to flag, just a hijacked request pipeline answering subsequent commands from memory. The response body in the proof-of-concept capture (a directory enumeration of the server’s C: drive) is the shell’s first output.

Reading the proof-of-concept capture

The HTTP transaction published with the research (Figure 1) is worth studying closely, because it documents both the attack surface and the exploitation window with unusual precision.

The request line is POST /sites/zdi/_layouts/15/AddGallery.aspx?DisplayMode=Edit&a=/ToolPane.aspx HTTP/1.1, the web part gallery import page forced into edit display mode with the ToolPane component attached via the a parameter. This is legitimate SharePoint plumbing; nothing in the URL alone is malicious, which is precisely why URI-only detection is weak here. The body, posted as application/x-www-form-urlencoded at 20,714 bytes, carries two ToolPane protocol parameters. MSOTlPn_View pins the editing session to a control-template endpoint on the lab host (http://10.0.1.134/sites/zdi/_controltemplates/15/AclEditor.ascx), while MSOTlPn_DWP (the parameter that conveys the web part definition under edit) carries the weaponized markup.

URL-decoded, MSOTlPn_DWP resolves into a stack of Register directives referencing System.Web.UI (PublicKeyToken 31bf3856ad364e35), System.Xaml (token b03f5f7f11d50a3a), and the XAML/WPF data types that host ObjectDataProvider, with MethodParameters elements wiring method arguments into the object graph, followed by a large base64 blob consistent with the encoded inner XAML document and in-memory shell stage. The structure matches the described mechanics exactly: benign-looking directive attributes whose unescaped quotes splice in attacker-controlled registrations, then a XAML object graph whose deserialization via XamlServices.Parse() invokes process creation under the worker process identity.

The response is where the capture becomes evidence rather than theory. Behind a 200 OK from Microsoft-IIS/10.0 with X-AspNet-Version: 4.0.30319 and MicrosoftSharePointTeamServices: 16.0.0.19725 (a build fingerprint consistent with SharePoint Subscription Edition prior to the August 2026 fix), the 981-byte body opens with webroot = C:\inetpub\wwwroot\wss\VirtualDirectories\80\ and proceeds to enumerate the drive: <DIR> C:\inetpub, C:\PerfLogs, C:\Program Files, C:\ProgramData, C:\Recovery, and, notably for any assessor reading pivot potential, C:\SQL2022, indicating a co-located database instance on the compromised host. Command output rendered into an HTTP response from a layouts-page request is authenticated remote code execution, full stop. Two further details deserve attention. The Date header reads Thu, 18 Jun 2026, nine days after the June 9 update and nearly two months before the August 11 fix, demonstrating that the June patch cycle did nothing to close this path. And the Host header value sharepointse alongside the RFC1918 address in MSOTlPn_View confirms a controlled laboratory environment, consistent with coordinated disclosure rather than opportunistic attack.

From authenticated to anonymous: the pre-auth chain

Authenticated RCE in SharePoint is serious but bounded: it presupposes an account, and SharePoint farms increasingly sit behind Entra ID conditional access, MFA, and federation controls that raise the cost of obtaining one. Khoa’s chaining work removes even that bound under a common configuration. Combined with a separate authentication bypass (fixed in Microsoft’s June 9, 2026 patch), CVE-2026-65660 reaches pre-authentication remote code execution on servers configured to allow anonymous page access, a setting far more common in publishing-oriented and extranet-facing farms than operators sometimes realize.

The practical topology that falls out of the timeline is worth understanding. Farms that applied the June 9 update closed the anonymous entry door but kept the authenticated flaw live until August 11. Farms that applied neither were reachable without credentials on anonymous-enabled web applications. Farms that applied August 11 without June remain an interesting edge case only in reverse: the pre-auth chain is dead because its bypass component is patched, even though the ordering looks wrong on paper. Anonymous access deserves its own review regardless of patch state; every anonymous-enabled web application widens exposure to the next bypass primitive, and SharePoint’s history guarantees there is a next one.

A familiar battlefield: ToolShell, Pwn2Own, and a researcher who keeps returning

Context matters here more than usual, because CVE-2026-65660 does not exist in isolation: it sits in the same attack surface, and arguably the same research lineage, as the most consequential SharePoint compromise wave of the past two years. Khoa is the researcher who demonstrated the original ToolShell exploit chain against SharePoint at Pwn2Own Berlin in May 2025, a chain pairing spoofing and code execution legs (later catalogued as CVE-2025-53770 and CVE-2025-53771) that Chinese state-backed groups subsequently weaponized in the wild, forcing Microsoft into emergency out-of-band patches and sending defenders hunting for stolen SharePoint machine keys and dropped web shells across July and August 2025. That episode left two lessons that still hold: SharePoint’s internet-facing assets are a standing target for espionage clusters, and SharePoint compromise tends to persist, because machine-key theft lets attackers forge validation material long after the original vulnerability is patched.

Khoa has kept working the same seam since, disclosing multiple additional SharePoint flaws including CVE-2026-55040, an authentication bypass that attackers exploited shortly after its details became public in August 2026, a reminder that disclosure publications function as de facto exploit deadlines. Against that backdrop, CVE-2026-65660 reads less like an anomaly and more like the latest installment in a sustained, researcher-driven excavation of ToolPane and web part processing logic. Each published mechanic is a map for defenders and a template for adversaries simultaneously; the only variable is who reads it first.

Exploitation status

As of publication, no in-the-wild exploitation of CVE-2026-65660 has been reported, and the flaw does not appear in CISA’s Known Exploited Vulnerabilities catalog, meaning federal binding operational directives do not yet compel remediation on its own authority. Microsoft’s advisory rates exploitation “Less Likely.” Both facts deserve skepticism of the healthy kind. The complete exploit markup is public as of today, the researcher confirms operational use in penetration testing engagements, and the payload design (in-memory, registry-independent, anonymous-chainable) was engineered specifically to survive the hardened configurations that stop lazier exploits. “Less Likely” is a forecast made before the proof-of-concept existed; the forecast’s inputs have since changed.

Defenders should also resist reading KEV absence as safety. KEV enrollment typically follows observed exploitation, which follows weaponization, which follows public mechanics: the catalog is a lagging indicator by design. The operational question for September 2026 is not whether CVE-2026-65660 is being exploited today but whether your fleet was patched on August 11, because the cost of being wrong asymmetrically favors the attacker: exploitation requires only an authenticated session, or nothing at all on unpatched anonymous-enabled farms.

Affected versions and the SharePoint 2013 problem

Microsoft’s advisory lists SharePoint Server 2016, 2019, and Subscription Edition as affected, with patches available since the August 11, 2026 security update; the researcher states the flaw also affects SharePoint Server 2013, which exited extended support in April 2023 and receives no security updates of any kind. Organizations still operating 2013 farms (and they exist, disproportionately in industrial, public-sector, and acquired-estate environments) cannot patch this vulnerability and must compensate: network isolation of the farm, removal of anonymous access, reverse-proxy or WAF rules blocking authenticated reachability of _layouts ToolPane endpoints, and an upgrade or migration program treated as risk remediation rather than IT housekeeping. The August 11 patch additionally turns off the vulnerable function by default according to Khoa, which materially reduces residual risk on patched fleets even where configuration drift might otherwise re-expose legacy behaviors.

Defensive playbook

Patch it

Apply the August 11, 2026 security update to all 2016, 2019, and Subscription Edition farms, including every server in the farm topology (front ends, application servers, and any role hosting SharePoint web applications), then verify rather than assume. Confirm installed build levels via Central Administration or by fingerprinting the MicrosoftSharePointTeamServices response header (the capture’s 16.0.0.19725 is representative of a pre-fix Subscription Edition build), and confirm the vulnerable ToolPane function is disabled by default post-patch as described in the research. Verify the June 9, 2026 update is present as well; the pre-auth chain requires both fixes absent, and partial patching leaves composite exposure.

Restricting Access for the unpatchable

For SharePoint 2013 and any fleet that cannot immediately patch: disable anonymous access on every web application that does not strictly require it; restrict network reachability of _layouts/15/AddGallery.aspx and _layouts/15/ToolPane.aspx at the reverse proxy or WAF for all non-administrative sources; deploy virtual-patch rules matching URL-decoded request bodies for MSOTlPn_DWP values containing <%@ Register sequences or their percent-encoded equivalents (%3C%25%40); and tighten web part gallery permissions so that low-privilege authenticated accounts cannot reach web part import and editing surfaces. Review web.config SafeControls entries across the farm for unauthorized additions, a cheap integrity check that also doubles as compromise hunting, since adversaries who achieved earlier code execution frequently legitimize their shells by allowlisting them.

Detection

URI-only detection is weak because the endpoint is legitimate; body-aware detection is where signal lives. Where proxy, WAF, or full-packet logging captures POST bodies, the following Sigma rule matches the published proof-of-concept pattern:

yaml

title: SharePoint ToolPane Register Directive Injection (CVE-2026-65660 Pattern)
status: experimental
description: Detects POST bodies to SharePoint AddGallery/ToolPane endpoints carrying
  URL-encoded ASP.NET Register directives in the MSOTlPn_DWP parameter.
logsource:
  category: proxy   # Zeek/Suricata HTTP body logging, WAF audit logs, proxy logs
detection:
  selection_endpoint:
    cs-method: 'POST'
    c-uri|endswith:
      - '/_layouts/15/AddGallery.aspx'
      - '/_layouts/15/ToolPane.aspx'
    c-uri|contains: 'DisplayMode=Edit'
  selection_body:
    cs-body|contains:
      - 'MSOTlPn_DWP=%3C%25%40%20Register'
      - 'MSOTlPn_DWP=%3C%25%40+Register'
      - 'MSOTlPn_DWP=<%@ Register'
  condition: all of selection_*
falsepositives:
  - Rare legitimate web part imports embedding Register directives via this endpoint
level: high
tags: [attack.initial_access, attack.t1190]

Pair it with behavioral coverage on the worker process, since successful exploitation manifests as command execution under w3wp.exe:

yaml

title: SharePoint Worker Process Spawning Script Interpreters
status: stable
description: Detects cmd/powershell and common LOLBIN children of IIS worker processes
  hosting SharePoint, consistent with web shell activity including in-memory shells.
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\w3wp.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\certutil.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: all of selection_*
falsepositives:
  - Legitimate SharePoint administration or deployment scripts; baseline and tune per farm
level: high

Beyond signatures, baseline your IIS logs for POST rarity against AddGallery.aspx and ToolPane.aspx (in most healthy farms the count is near zero, which makes any hit analytically expensive for an attacker to hide), and alert on SharePoint ULS anomalies around web part loading failures and SafeControls evaluation, which frequently log noisily when malformed or injected markup is processed.

Assume-breach. check for exposed fleets

For farms that were internet-facing, anonymous-enabled, or unpatched between June and August 2026, treat this as a hunting exercise rather than a patching exercise. Enumerate worker-process memory indicators and reflective module loads on SharePoint servers; sweep for web shells both on disk and in memory; review IIS logs for the request pattern in Figure 1 across the entire exposure window; and, the lesson ToolShell burned into everyone in 2025, if any compromise indicator surfaces, rotate SharePoint machine keys and every service, farm, and application-pool credential, because stolen validation keys outlive the vulnerability that delivered them. Co-located services matter too: the proof-of-concept’s directory listing exposes a SQL2022 installation on the compromised host, a reminder that SharePoint server compromise is routinely a database compromise one hop later.

The metadata lesson: triage the capability, not the label

CVE-2026-65660 should prompt a process change, not just a patch cycle. Mature vulnerability management already cross-references multiple classification sources (vendor advisory, CVE record, NVD enrichment, and researcher publication) because each carries different latency and different incentives; this flaw demonstrated all four disagreeing in material ways across six weeks. Where classifications conflict, triage to the most severe credible capability, and treat CWE assignments as a sanity check: CWE-94 code injection paired with a “spoofing” label and zero integrity impact was an internally inconsistent story from the day it shipped. Build standing rules that ignore labels entirely for high-value platforms (internet-facing SharePoint among them) and key prioritization instead on attack-surface facts: authenticated versus pre-auth, public proof-of-concept versus private, supported versus end-of-life. And maintain an explicit policy for researcher disclosure dates: when a credible researcher publishes full mechanics, the clock on your patch SLA restarts, regardless of what any database scored the bug six weeks earlier.

FAQ

Is CVE-2026-65660 being actively exploited right now? No confirmed in-the-wild exploitation has been reported as of September 22, 2026, and the flaw is not listed in CISA’s KEV catalog. The complete exploit markup is public, however, and the disclosing researcher has used it in penetration tests, so defenders should treat public weaponization as a matter of time rather than possibility.

Why did Microsoft classify an RCE as spoofing? Microsoft’s August advisory describes authorized-attacker spoofing with a 6.5 CVSS score, while its CVE record updated September 11 describes code execution and NVD scores 8.8. Both records share CWE-94. The discrepancy appears to reflect initial impact assessment rather than technical disagreement about the mechanism; the practical consequence was six weeks of under-prioritized triage.

Does the August 11, 2026 patch fully fix the issue? For supported versions (2016, 2019, Subscription Edition), yes, and per the researcher the update also disables the vulnerable function by default. SharePoint 2013 is affected but out of support since April 2023 and will never receive a fix, requiring isolation and migration instead.

Do I need anonymous access enabled to be at risk? No. Anonymous access only matters for the pre-authentication chain, which additionally requires the June 9-patched authentication bypass to be missing. Authenticated RCE applies to any farm lacking the August 11 update, regardless of anonymous configuration.

How is this different from ToolShell (CVE-2025-53770 / CVE-2025-53771)? ToolShell was a 2025 exploit chain demonstrated at Pwn2Own Berlin by the same researcher and later mass-exploited by Chinese state-backed groups, notably enabling machine key theft for persistent access. CVE-2026-65660 is a distinct flaw in ToolPane’s Register directive reconstruction and SafeControls validation ordering, sharing the product and research lineage but not the code path.

Should I rotate SharePoint machine keys because of this CVE? Not as a routine patch action. Key rotation is an incident-response step warranted when compromise indicators exist, particularly given ToolShell-era key theft, not a prerequisite for closing CVE-2026-65660 itself.

The bottom line

CVE-2026-65660 shows two failures at once: a software failure, where an unescaped quote collapsed the boundary between data and directive in one of enterprise software’s most security-sensitive parsers, and a communication failure, where severity metadata told defenders the opposite of what the code actually permitted. The engineering lesson is narrow and old: escape your output, validate after reconstruction, never let the artifact you check diverge from the artifact you load. The operational lesson is broader and newer: in an ecosystem where researchers publish complete exploit mechanics on a coordinated schedule and adversaries read the same publications on the same day, the classification in your vulnerability console is a hypothesis, and the only verdict that counts is your patch level. Patch August 11 everywhere, compensate on 2013, hunt the exposure window, and stop letting labels do your thinking.