Microsoft confirmed active exploitation of CVE-2026-65660 in late September 2026, a code injection flaw in on-premises SharePoint Server, and CISA added it to the Known Exploited Vulnerabilities catalog on 24 September. The Canadian Centre for Cyber Security published its own alert the same day. Microsoft had shipped the fix six weeks earlier, on 11 August, and the advisory alongside it described a spoofing vulnerability rated CVSS 6.5.
Exploitation requires two things: an account on the server, at low privilege, and a server that will accept the request carrying the payload. The severity label directed attention to the first. The second is the only one an organization can still change once the patch window has been missed.
What actually happened
The flaw is CWE-94, improper control of code generation, in SharePoint's ToolPane component. Viettel Cyber Security published the technical analysis on 22 September, describing Register directives that are reassembled without escaping quote characters inside attribute values. An attacker closes a quote early and registers arbitrary .NET classes after the SafeControls allowlist check has run and before ASP.NET parses the page, then chains that through .NET deserialization to code execution inside the SharePoint worker process. The same analysis reports that the resulting implant can stay in memory rather than being written to disk.
| Date | Event |
|---|---|
| 11 August 2026 | Fix ships. The advisory describes a spoofing vulnerability at CVSS 6.5, exploitation less likely |
| 11 September 2026 | The CVE record is revised to remote code execution at CVSS 8.8, vector AV:N/AC:L/PR:L/UI:N. Microsoft's advisory page still reads spoofing at 6.5 |
| 22 September | Full technical detail is published, including a working in-memory payload |
| 24 September | CISA adds the CVE to its Known Exploited Vulnerabilities catalog; the Cyber Centre publishes AL26-023 the same day |
| 25 September | Microsoft confirms evidence of attacks. The federal remediation deadline is 28 September |
The affected products are on-premises: SharePoint Enterprise Server 2016, SharePoint Server 2019, and Subscription Edition. SharePoint Online is not affected. The Cyber Centre's advisory also states that the flaw can reach pre-authentication remote code execution when chained with other SharePoint vulnerabilities on servers configured to permit anonymous access.
The gap: a credential requirement was read as a barrier
Nothing in this sequence was negligent, and the controls involved were doing the jobs they were built for.
- The SafeControls allowlist exists precisely to stop arbitrary class registration. It ran. The injected directive landed after it.
- Authentication was required and, as far as anything reported suggests, worked. It is not designed to ask whether an authenticated user's next request contains a parser trick.
- Severity triage is a real discipline. A vector carrying privileges required: low genuinely scores lower than one carrying none, and defenders have to prioritize somehow.
The difficulty is what that vector component costs an attacker in practice. A low-privilege SharePoint account is not a scarce artifact. It is the routine output of information stealers, of credential stuffing against reused passwords, and of one successful phish against anybody at all.
A vector that reads "privileges required: low" is a statement about the attacker's shopping list, not about the difficulty of the attack.
The six weeks matter for the same reason. Estates get patched in the order their labels suggest, and a moderate spoofing issue does not win an out-of-band maintenance window on the server the whole company stores its documents in.
What would have had to be true
The Cyber Centre's recommendations here include patching, multi-factor authentication for administrators, AMSI integration, monitoring for suspicious web part modifications, and limiting the internet exposure of SharePoint servers. That last item is not a patching instruction. It is a reachability one, and it is the only one on the list that would have held during the six weeks when nobody was treating the flaw as urgent.
So why was any on-premises SharePoint server answering the internet on 24 September? Not for want of the capability. Every firewall and reverse proxy in front of one of these servers can filter by source.
It is that the list of legitimate sources decays from the moment it is written. A collaboration server has to answer everybody who works at the company, and those people work from home, from a client site, from a broadband connection reassigned overnight. The failure mode is asymmetric: an address left in the group too long is silent, while a missing one is a support ticket from somebody who cannot open a document. So the range gets widened until it is no longer a control.
Where Veribound would have fitted
Veribound is a Pre-session Edge Access Control (PEAC) platform and an intelligence layer. It is additive: SharePoint stays, the identity provider stays, MFA stays, the firewall in front of the server stays, and the customer's own policy keeps enforcing its own rules, unchanged.
Agents on staff devices continuously attest that each device is still the one the organization trusted, and a trust-scoring engine turns those attestations into a per-device decision. What reaches the customer's existing controls is a trusted origin: the network that device is connecting from, in practice its public address, while the device behind it is still trusted. Those origins are kept current in the address groups the organization's own policy already references.
Applied to an on-premises SharePoint server:
- The server answers trusted origins only, which is the reachability item on the Cyber Centre's list, in place before the advisory rather than after it.
- A purchased low-privilege credential has nowhere to be presented, because the request carrying it does not arrive from an origin the policy recognizes.
- The anonymous-access chain needs the same reachability, so the variant requiring no credential at all meets the same decision.
- The August update is still required, along with the audit of whether it was ever installed on a server whose advisory said moderate.
- The group keeps up, changing when somebody changes network, which is the part that fails when it is maintained by hand.
What this would not have done, stated plainly. It does not repair the flaw, and the 11 August update remains the remedy. It would not have distinguished an attacker working from a device and network the organization already trusts, so a compromised staff workstation or an existing internal foothold satisfies the reachability precondition as well as an external connection does. It would not remove an in-memory implant already running in a worker process, or undo anything that followed code execution, which is why AMSI, telemetry review and incident response stay exactly where they were. And it is not a substitute for MFA, which the Cyber Centre recommends here and which remains the right control on an account that has legitimately reached a login.
One more line from that advisory is worth sitting with. SharePoint Server 2016 and 2019 reached end of life on 15 July 2026. For an estate still running them, the question of who the server answers is not a stopgap until the next patch. It is what is left.
Source: AL26-023 - Vulnerability Impacting Microsoft SharePoint Server - CVE-2026-65660, Canadian Centre for Cyber Security, 24 September 2026.