CISA Says SharePoint CVE-2026-45659 Is Now Used in Ransomware Attacks
CISA has flagged Microsoft SharePoint vulnerability CVE-2026-45659 as being used in ransomware attacks, according to BleepingComputer reporting published August 11, 2026. The vulnerability is a deserialization flaw that can allow an attacker with low privileges to execute arbitrary code on an unpatched SharePoint server. CISA had already added it to the agency’s Known Exploited Vulnerabilities catalog in July, meaning evidence of exploitation existed before the ransomware designation was added.
For infrastructure teams, the shift from “actively exploited” to “used in ransomware” changes the recovery discussion. Patching remains essential, but once an attacker has gained access, containment and restoration become equally important. A resilient environment needs more than successful backup jobs. It needs backup testing that proves workloads can actually be restored after a destructive incident.
Why the SharePoint finding matters
BleepingComputer reports that CVE-2026-45659 affects SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition, with Microsoft having released security updates earlier in 2026. CISA has urged organizations to apply current patches, verify that installation succeeded, monitor affected systems for exploitation, and use available antimalware protections.
The risk is especially serious for internet-facing enterprise systems because they can provide attackers with an initial foothold inside networks that also contain identity services, file systems, application servers, backup infrastructure, and administrative tools. Ransomware groups increasingly combine exploitation with credential theft, lateral movement, data exfiltration, and encryption. Fixing the entry vulnerability therefore addresses one part of the incident, but it does not automatically remove persistence or undo activity that occurred before the patch was applied.
Recovery architecture matters after initial access
The most practical lesson from ransomware exploitation is that organizations should assume some preventive controls can eventually fail. Backup design should account for an attacker who has administrative access and is actively trying to destroy recovery options. That means separating backup credentials, limiting administrative paths, maintaining independent copies, and verifying that recovery data has not been silently corrupted or deleted.
A useful benchmark is the 3-2-1-1-0 backup rule, which adds an offline or immutable copy and a requirement for zero unverified backup errors to the traditional 3-2-1 model. The point is not the mnemonic itself. The point is failure independence. A backup stored under the same identity system, network trust, or administrative control as production can become vulnerable during the same compromise.
What administrators should do now
Organizations running affected SharePoint versions should confirm patch status against Microsoft guidance and CISA’s exploited vulnerability information, then review logs and security telemetry for signs of earlier compromise. Systems that were exposed before patching deserve investigation rather than an assumption that the update closed the incident.
Recovery teams should also use the event as a reason to validate restore procedures. Identify which SharePoint content, configuration, databases, identity dependencies, and connected services would be needed for a full rebuild. Test whether those components can be recovered into a clean environment and measure how long that takes.
The broader pattern is familiar: a vulnerability becomes known, exploitation follows, and ransomware operators eventually turn the same weakness into a monetization path. The organizations that handle that progression best are the ones that combine rapid patching with isolation, monitoring, independent backups, and rehearsed recovery.
Originally published on the Mr.PlanB blog.