SharePoint CVE-2026-65660 is a code injection flaw in on-premises Microsoft SharePoint Server that lets an attacker who already holds a low-level account on the server run code on it over the network, with no action from any other user. Microsoft fixed it in the August 2026 security updates, researchers published technical details in September, and attacks followed within days; Microsoft confirmed exploitation on September 25 and CISA added it to the Known Exploited Vulnerabilities catalog. It affects SharePoint Enterprise Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition. SharePoint Online in Microsoft 365 is a different service and is not in that list. If your organization still runs its own SharePoint farm, confirm the August or later update is installed on every server, then review who holds accounts that could reach it.
Why a Six-Week-Old Patch Became an Emergency
A six-week-old patch became an emergency because many organizations treat on-premises SharePoint as stable infrastructure and update it slowly, and attackers moved the moment exploit details became public. The August fix sat available while the risk looked theoretical, and then the window closed in a matter of days.
That pattern shows up in our client reviews all the time. A firm keeps a SharePoint 2016 or 2019 farm because a line-of-business workflow, a records system or a regulatory archive depends on it. Our SharePoint services team sees this in most firms that started on-premises. The farm works, the people who built it have moved on, and cumulative updates are applied when somebody remembers. When a flaw like this one turns from patched to exploited, that habit becomes the exposure, a pattern described in 5 SharePoint consulting services mistakes SMBs make.
Here are the five principles behind the steps in this article:
- Every server in the farm counts. Web front ends, application servers and search servers all need the update, not just the one users browse to.
- Low-level access is enough. The attacker needs an account, not an administrator, so contractor and service accounts matter.
- Online and on-premises are different products. Microsoft 365 SharePoint is managed by Microsoft and is not on the affected list.
- Patching closes the door, not the house. A server reachable before the update needs a review for signs of code already running.
- Old farms need an exit plan. SharePoint 2016 and 2019 are past the end of Microsoft extended support, and every flaw raises the cost of staying.
This guide is written for IT managers, operations leads and owners at organizations of 50 to 500 people that still run SharePoint Server in their own data center or in a hosted virtual environment.
Who Still Runs SharePoint Server
On-premises SharePoint is more common in small and midsize organizations than most people assume. Law firms use it for document management, manufacturers for quality records, nonprofits and schools for intranets built years ago, and regulated businesses for archives they were told to keep in their own environment.
The counterpoint is that many of these organizations believe they migrated to Microsoft 365. Often they moved mail and new team sites while an old farm kept running for one department or one application. Ask your provider to list every SharePoint Server in the environment, including test and disaster recovery copies, before deciding you are unaffected.
Why an Authenticated Flaw Still Matters
A flaw that requires a login can sound less urgent, and for some flaws that is fair. Here the bar is a low-privilege account, and in a typical organization dozens or hundreds of people, contractors and service identities hold one.
Phished passwords, reused credentials from other breaches and old accounts of departed staff all meet that bar, which is why identity-based attacks cost SMBs real money and why security awareness training belongs alongside patching. If the farm is published to the internet for remote access, the pool of people who could try is larger still. Treat this as a serious remote code execution risk, not a niche insider issue.
How the Code Injection Flaw Works
The code injection flaw works because SharePoint fails to escape certain quote characters in input it later processes, which lets an attacker add their own directives, register arbitrary .NET classes and then use XAML parsing to trigger code execution through deserialization. Put simply, the server is tricked into building and running objects the attacker described.
Code running on a SharePoint server runs with the server’s permissions, which usually include broad read access to document libraries, connections to SQL Server and service account credentials. That makes a SharePoint foothold a strong position for stealing data and moving into the rest of the network, which network security monitoring is designed to catch.
What Attackers Do After Getting In
Attackers who reach code execution on SharePoint typically plant a web shell for return access, harvest machine secrets and service credentials, and copy documents. In past SharePoint campaigns, stolen machine secrets let attackers forge authentication even after the original flaw was patched.
An opposing view holds that document libraries are protected by SharePoint’s own permissions. They are, for users. Code running as the server bypasses that model, because the server is the thing enforcing it.
Why the Exposure Window Matters
The meaningful window runs from public technical details in September to the day your August or later update was installed. A farm patched in August had little exposure. A farm patched after September 25 should be treated as possibly touched, especially if it is reachable from the internet.
Patching Every Server in the SharePoint Farm
Patching the SharePoint farm for CVE-2026-65660 means installing the August 2026 security update or any later cumulative update on every SharePoint server, running the configuration wizard to complete the upgrade, and confirming the build number afterward. Partial patching is common and easy to miss.
Confirming the Build on Each Server
The farm’s build number is visible in Central Administration under the servers in the farm list, and each server’s status should read as no action required once the upgrade completes. A server stuck at upgrade required is not fully patched even if the binaries were installed.
Some teams check only the server users browse to. That leaves application and search servers behind, and an attacker can reach code on any of them. Ask for the build number of every server, with a date, in writing.
Scheduling Downtime
SharePoint updates usually take the farm offline for the duration of the configuration wizard, which can run from minutes to hours depending on content database size. For most small and midsize farms an evening or weekend window works.
The objection that a busy department cannot lose access is real. It is also the reason to schedule a short planned outage now instead of an unplanned one later, when an incident response team takes the farm offline for days.
Reducing Exposure While You Patch
If the update cannot go on today, remove internet publishing for the farm and require a VPN for remote users. Review and disable accounts that no longer need access, especially old contractor and vendor accounts. Turn on and confirm antimalware scanning integration on the servers.
These steps buy time without fixing the flaw. Keep them after patching anyway, because a farm reachable only from the internal network is a much smaller target for the next SharePoint flaw, the same reasoning behind zero trust security for a small business.
Checking a Farm That Was Exposed
Checking an exposed SharePoint farm means looking for web shells, unusual processes and changed configuration, and rotating secrets that an attacker could have copied. If the farm was reachable and unpatched after the September technical disclosure, plan for this review.
Signs to Look For
Ask your administrator to search the SharePoint web folders for recently created .aspx files that nobody deployed, review IIS logs for unusual requests to layouts pages, check for unexpected child processes of the IIS worker process, and compare the farm’s deployed packages and feature list with what is expected.
Microsoft and security researchers publish indicators of compromise for exploited SharePoint flaws. Compare against them and document the result. A provider offering managed security services should run this for you.
Rotating Machine Secrets
If there is any sign of compromise, rotate the ASP.NET machine validation and decryption secrets for the farm and restart IIS on every server, then rotate service account passwords. Earlier SharePoint campaigns showed that patching without rotating those secrets can leave attackers able to forge sessions.
Rotation is disruptive and some teams resist it without proof of compromise. That is a reasonable judgement when the farm was patched early and never published externally. For an internet-facing farm patched late, the safer default is to rotate.
Planning the Exit From On-Premises SharePoint
Planning the exit from on-premises SharePoint means deciding which content and workflows still need a farm you run yourself and which can move to SharePoint Online, where Microsoft applies fixes for you. SharePoint Server 2016 and 2019 reached the end of extended support in July 2026, so many affected farms now run on software Microsoft no longer commits to fix.
Questions to Ask Your IT Provider
Send your provider these questions:
- How many SharePoint servers do we run, including test and recovery copies?
- What build is each server on, and when was the August update applied?
- Is any part of the farm reachable from the internet?
- Has the farm been checked against Microsoft’s published indicators of compromise?
- What would it take to retire the farm, and what still depends on it? A cyber security audit is a good way to get these answers documented.
Weighing the Move
Some organizations have good reasons to keep a farm: custom code, records rules or contracts that require data to stay in an environment they control. Those are fair constraints, and Subscription Edition gives them a supported path. For many others, the farm stays only because nobody owns the migration. Each new exploited flaw is a reason to give that migration an owner and a date. Our guide to running a cloud migration without downtime covers how to sequence it, and cloud security planning covers what replaces the farm’s controls.
Frequently Asked Questions
Does SharePoint CVE-2026-65660 affect SharePoint Online?
No, the affected products are SharePoint Enterprise Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition. SharePoint Online in Microsoft 365 is maintained by Microsoft.
Which update fixes SharePoint CVE-2026-65660?
The August 2026 security update for each affected version fixes it, and later cumulative updates include the fix. Confirm the build on every server in Central Administration after running the configuration wizard.
Does an attacker need an account to exploit CVE-2026-65660?
Yes, a low-privilege account is required. Phished, reused and stale accounts make that bar easier to clear than it sounds.
Should we rotate machine secrets after patching?
Rotate them if the farm was internet-facing and patched after exploitation began, or if you find any sign of compromise. Rotation prevents attackers from reusing stolen secrets to forge sessions.
Is it time to move off on-premises SharePoint?
For many small and midsize organizations, yes, especially on 2016 or 2019. Keep a farm only where a clear business or regulatory reason requires it.
Who Stands Behind This Guidance
Mindcore Technologies supports Microsoft environments for small and midsize organizations, from on-premises SharePoint farms that still carry critical records to full moves into Microsoft 365. Our team follows Microsoft’s security updates and CISA’s exploited vulnerability list closely and turns each new entry into concrete checks for the servers our clients run. That approach comes from Matt Rosenthal, Mindcore’s CEO, who has built the company around giving leaders clear, accountable answers about the systems their business depends on.
Close the SharePoint Gap Before the Next Flaw
SharePoint CVE-2026-65660 lets anyone holding a basic account run code on an unpatched on-premises SharePoint server, and it is being exploited. Install the August or later update on every server in the farm, confirm the build, take the farm off the internet if you can, and review and rotate secrets if it was exposed after the September disclosure. Then decide, with a date and an owner, whether your organization still needs to run SharePoint itself. If you want help checking your farm or planning a move to SharePoint Online, book a free strategy call and we will walk through your environment with you.
