CVE-2026-65660: a SharePoint flaw that never writes a file to disk
Most incident response playbooks for a web server compromise start with the file system. Analysts look for recently written scripts, unexpected directories and timestamps that do not match a deployment window. CVE-2026-65660 breaks that habit, because the exploitation chain it uses builds its payload in memory and leaves no file behind.
Technical context
Microsoft rated the flaw 8.8 and fixed it on 11 August 2026 across SharePoint Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition. The corrected builds are 16.0.5565.1001, 16.0.10417.20198 and 16.0.19725.20522. The researcher credited with the report is Dinh Hoan Anh Khoa of Viettel Cyber Security. CISA added the identifier to the Known Exploited Vulnerabilities catalog on 25 September with a remediation deadline of 28 September, and the catalog entry marks it as subject to forensic triage.
Microsoft's description states that an authorized attacker can execute code over a network. Authorization is part of the default path, and a low-privileged account satisfies it.
Explanation and the exploitation path
The root cause is a parsing order problem. The method ToolPane.GetPartPreviewAndPropertiesFromMarkup() separates a Register directive from the Tag that follows it. The directive is then reconstructed by RegisterDirective.GetHtml(), which does not escape quotation marks inside attribute values. An attacker who supplies a crafted value can break out of the attribute context and inject an additional directive into the reconstructed markup.
The injected directive skips the safety verification that would normally apply. In a healthy flow, EditingPageParser.VerifyControlOnSafeList() consults SafeControls and rejects registrations that name dangerous .NET classes. Because the injected content is assembled after the check has already been reasoned about as safe, a class the SafeControls list would refuse can be registered anyway.
From there the chain is a known deserialization pattern: XamlServices.Parse() handles the parsed markup, ExpandedWrapper and ObjectDataProvider provide the gadget shapes, and LosFormatter deserialization completes execution. The result is a web shell that exists only as an in-memory object, which is exactly why the forensic triage flag matters.
Exploitation requires a POST to a WebPartPage that contains a WebPartZone, for example AddGallery.aspx. Microsoft's default position is that attackers must authenticate first, and that a low-privilege account is enough. Researchers demonstrated a pre-authentication path by pairing the flaw with a separate authentication weakness in the ToolPane component, a weakness Microsoft corrected on 9 June 2026. Installations that applied the June update do not expose that chaining route. QiAnXin counted 67,103 at-risk assets and 7,912 addresses worldwide, with 5,209 assets and 285 addresses in China, and reported that public proof-of-concept material exists. The same construction is reported to apply to SharePoint 2013, which no longer receives fixes.
Defensive implications
Detection has to move away from the file system. Useful signals are POST requests to WebPartPage endpoints from accounts that do not normally edit pages, and EditingPageParser or XAML parsing activity in SharePoint logs that does not correlate with a content change. Application pool identities should be treated as high value, because the in-memory payload runs with the site service account.
The practical lesson is about verification order. A safety check that runs before a string is reassembled protects the pre-assembly form and nothing else. Any component that reconstructs markup, SQL statements or command lines needs its own escaping at the point of reconstruction, and it needs a post-construction assertion that the result is still what the parser expects.
References
[1] Microsoft Security Response Center entry for CVE-2026-65660.
[2] SharePoint Server 2016 security update, 11 August 2026, KB5002906.
[3] CISA Known Exploited Vulnerabilities Catalog.
Top comments (0)