What happened
Microsoft released the security update for CVE-2026-65660 on August 11, 2026. On September 24, 2026, Previdian captured 12 POST requests across six URL paths against a SharePoint honeypot, using two payload sizes of 7,834 and 535,404 bytes. On September 25, 2026, CISA added CVE-2026-65660 to the Known Exploited Vulnerabilities catalogue; the federal remediation deadline was September 28, 2026. The fixed builds are 16.0.5565.1001 for SharePoint Enterprise Server 2016, 16.0.10417.20198 for SharePoint Server 2019 and 16.0.19725.20522 for SharePoint Server Subscription Edition.
Hunt for POSTs from 169.150.248[.]21 to /_layouts/15/AddGallery.aspx or /_layouts/15/designgallery.aspx, including repeated /_layouts/ prefixes, with job=all&DisplayMode=Edit; look for /_layouts/15/sphealth.aspx, wt3k3sij.dll with SHA-256 d3faa4b443d98f272363f3484a5e6a9bab90979086aa2d31a1694c1dc8178742, 24e5mo4s.dll with SHA-256 a151a8fc193a96aac480fa749547b57c0f33116cf2cb8c82b6aa716c3c47f4b1, and the loader type SdLoader. Previdian did not recover the encrypted final assembly, so its behaviour remains unresolved. The cited sources did not publish victim organisations or confirmed impact beyond the observed honeypot traffic. The cited source did not publish the associated malware detail described as Final payload behaviour.
Why this matters now
The executive decision changed from routine patch compliance to active-exploitation response. CVE-2026-65660 requires authenticated access in Microsoft’s description, but the observed traffic attempted to combine it with a separate anonymous delivery weakness on sites allowing anonymous viewing. That means teams cannot assess risk from the CVE score or August update alone; they need configuration context, complete update history and evidence from web, endpoint and file-system telemetry.
SharePoint remains a high-value collaboration and document repository, often connected to privileged identities and sensitive internal content. A webshell or loader on an exposed server can outlive patch deployment. Organisations that cannot reconstruct request history or validate file integrity should record that assurance limitation and consider the affected server an incident-response scope, rather than declaring closure from a successful update job.
The decision for security leaders
Direct vulnerability management to provide more than a patch-compliance percentage. The decision record should connect each SharePoint instance to its build, internet exposure, anonymous-access configuration, update history, log retention and hunt result. Servers without sufficient telemetry require an explicit assurance limitation and a risk-based decision on isolation, rebuild or enhanced monitoring.
Incident response should own any positive indicator, unexpected file or suspicious request sequence. Preserve evidence before remediation, determine whether the anonymous delivery weakness and CVE-2026-65660 were both reachable, and assess whether credentials, secrets or connected repositories require containment. Do not allow a later successful patch to overwrite the compromise investigation.
Evidence of closure
- An asset export accounts for every on-premises SharePoint server and exposure path.
- Build evidence shows every retained server at or above the applicable fixed version.
- A documented hunt records results for every published request, file and hash artefact.
- A signed disposition addresses every server lacking sufficient historical telemetry.
The Security.io assessment
The evidence establishes active exploitation attempts and an authoritative KEV decision, but Previdian’s honeypot capture does not establish successful compromise of a production victim. The observed chain also depends on a second anonymous delivery issue and site configuration, so exposure cannot be inferred from CVE presence alone. Conversely, authentication requirements in the base advisory should not be used to dismiss internet-facing sites that allow anonymous viewing.
Attribution posture: Neither the Cyber Centre nor Previdian attributed the observed SharePoint exploitation attempts to a named actor. The absence of a recovered final assembly limits conclusions about post-exploitation objectives. The correct Monday posture is therefore evidence-led: treat the published artefacts as a hunt package, distinguish attempted traffic from successful code execution and retain uncertainty where logging cannot answer that question.
Questions for the morning meeting
- Which SharePoint servers permit anonymous viewing or face untrusted networks?
- Can the team prove both the June and August fixes are present?
- Who owns incident escalation when patch status is current but artefacts are found?