Patch SharePoint Server CVE-2026-45659 Before the July 4 KEV Deadline

CISA added CVE-2026-45659 to the Known Exploited Vulnerabilities catalog on July 1 with a remediation deadline of July 4, 2026. That is a three-day window over a holiday weekend. The vulnerability is a deserialization-based remote code execution flaw in Microsoft SharePoint Server, carries a CVSS score of 8.8, and CISA has confirmed active exploitation in the wild. The patch has been available since May. If your on-prem SharePoint servers are unpatched, stop reading the analysis sections and go straight to the patch playbook below.

If you use Microsoft 365 and SharePoint Online, you are not affected. Microsoft patches the cloud service directly. This CVE applies only to on-premises SharePoint Server installations.

Microsoft originally rated this vulnerability as “Exploitation Less Likely” when it shipped the fix in the May 2026 Patch Tuesday update. That assessment changed. Between late May and early July, exploitation activity was confirmed, prompting CISA to add it to the KEV catalog with the shortest possible remediation timeline under BOD 26-04. If your organization still runs SharePoint on-premises, particularly SharePoint 2016 or 2019, this applies to you.

Patch Checklist

Before you read anything else, confirm these three items:

1. Identify your SharePoint version. Open Central Administration > System Settings > Manage servers in this farm. Note the build number.
2. Apply the correct KB. SharePoint 2016: KB5002868. SharePoint 2019: KB5002870. SharePoint Subscription Edition: KB5002863.
3. Run the SharePoint Products Configuration Wizard on every server in the farm after installing the update. The patch is not effective until this step completes.

If those three steps are done and your build numbers match the fixed versions listed below, you are patched. Keep reading for the post-compromise verification steps, because the exploit has been active since before CISA flagged it.

What CVE-2026-45659 Does

The vulnerability sits in SharePoint’s deserialization handling. SharePoint accepts serialized .NET objects through several internal endpoints. CVE-2026-45659 exploits a gap where one of those endpoints deserializes untrusted input without sufficient validation, allowing an authenticated attacker with low-level site permissions (a standard site member account is enough) to execute arbitrary code on the SharePoint server.

The attack requires network access and a valid SharePoint account, but the privilege bar is low. Any user with member-level site access can trigger it. In most SharePoint deployments, that includes every employee with access to the intranet, plus any external users granted site access for collaboration.

Once an attacker achieves code execution on the SharePoint server, they are running in the context of the SharePoint service account, which typically has broad access to the content databases, file system, and often the Active Directory environment. From there, lateral movement into the rest of your on-prem network is a well-documented attack path.

Why the KEV Deadline Matters

CISA’s Known Exploited Vulnerabilities catalog is not a severity list. It is a list of vulnerabilities with confirmed active exploitation. When a CVE lands on KEV, it means someone is using it against real organizations right now.

The July 4 deadline creates a specific problem. CISA’s BOD 26-04 sets remediation timelines based on exploitation risk, and a three-day window signals the highest urgency tier. BOD 26-04 is a binding directive for federal civilian agencies only. It does not legally compel private businesses. The real risk for private organizations is not the directive itself but the confirmed active exploitation that triggered it. The holiday weekend compounds the risk: attacker groups routinely time campaigns around long weekends when IT staff are out and change freezes are in place.

Microsoft released the patch in May. That means the fix has been sitting in Windows Update and the Microsoft Download Center for nearly seven weeks. Organizations that applied the May cumulative updates are already protected. The ones still exposed are typically businesses that patch SharePoint on a delayed schedule, skip months, or have farms that fell out of their patch management process entirely.

Who Should Be Concerned

Three versions of SharePoint Server are affected:

The businesses most at risk are those still running SharePoint 2016 or 2019 on-premises for intranet portals, document management, or custom workflows. Across the Dallas-Fort Worth metro and throughout Texas, we see this frequently in professional services firms, manufacturers, and healthcare organizations that have compliance or data residency reasons for keeping SharePoint on-prem. Many of these farms were deployed years ago and receive inconsistent patching attention.

Step-by-Step Patch Playbook

0. Back Up Content and Configuration Databases

Before applying the update, back up your SharePoint content databases and the farm configuration database. If the patch or PSConfig step fails, you need a rollback path.

Backup-SPFarm -Directory "D:\SharePointBackups" -BackupMethod Full

Alternatively, back up the content databases and config database individually through SQL Server Management Studio. Confirm the backups completed successfully before proceeding.

1. Confirm Your Current Build Number

On each SharePoint server, open Central Administration and navigate to System Settings > Manage servers in this farm. The build number displayed there tells you whether you are vulnerable. Compare it to the “Fixed Build” column in the table above. You can also check from PowerShell:

(Get-SPFarm).BuildVersion

If the build number is at or above the fixed version, you are already patched. Proceed to the post-compromise checks in the next section.

2. Download and Install the Correct Update

Download the update for your SharePoint version from the Microsoft Download Center links above (KB5002868, KB5002870, or KB5002863). Install it on every SharePoint server in the farm, including application servers and web front-ends.

For multi-server farms, follow this sequence: install the KB on every server in the farm, then restart each server. After all servers have restarted, run PSConfig on the Central Administration server first. Once PSConfig completes on the Central Admin server, run it on the remaining servers one at a time.

3. Run the SharePoint Products Configuration Wizard

After the update installs and the servers restart, run the SharePoint Products Configuration Wizard (PSConfig) on every server in the farm, starting with the Central Administration server.

From PowerShell:

PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources

PSConfig typically takes 30 to 60 minutes per server. Plan for the farm to be unavailable during this window and notify users before starting. If you are patching outside business hours over the holiday weekend, confirm that someone can monitor the process through completion.

The patch does not take full effect until PSConfig completes. Skipping this step leaves you vulnerable even after installing the update binary.

4. Verify the Patch

After PSConfig finishes, confirm the new build number:

(Get-SPFarm).BuildVersion

Check that IIS application pools have recycled and that all SharePoint services are running normally. Test a few site collections to confirm the farm is operational.

Assume-Breach: Post-Compromise Verification

The patch has been available since May 12. CISA confirmed active exploitation. That timeline gap means your servers may have been targeted before you applied the fix. Patching closes the door, but you need to check whether someone already walked through it.

Before running these checks, verify that your SharePoint diagnostic logs cover the full lookback window. Default ULS log retention is 14 days, which may not reach back far enough:

Get-SPDiagnosticConfig | Select-Object DaysToKeepLogs, LogLocation

If DaysToKeepLogs is less than 60, your ULS logs may have already rolled over. Rely on Windows Event Logs and IIS logs for the full lookback period instead.

Check Windows Event Logs for Exploitation Indicators

Do not rely on SharePoint ULS logs alone for detecting exploitation of this vulnerability. Filtering ULS logs for terms like “deserializ” or “untrusted” gives false confidence because the exploit does not necessarily trigger those specific log messages. ULS may record the activity under generic error categories or not at all, depending on the logging level configured on your farm.

Check the Windows Application Event Log for BinaryFormatter or type-loading exceptions from the w3wp.exe process, which hosts SharePoint’s application pools:

Get-WinEvent -FilterHashtable @{
  LogName = 'Application'
  StartTime = (Get-Date).AddDays(-60)
} | Where-Object {
  $_.Message -match 'BinaryFormatter|TypeLoadException|SerializationException' -and
  $_.Message -match 'w3wp'
} | Select-Object TimeCreated, Id, Message |
  Export-Csv -Path "C:\Temp\SP-AppLog-Deser-Review.csv" -NoTypeInformation

Also check Security Event ID 4688 (process creation) for child processes spawned by w3wp.exe. Successful exploitation of deserialization RCEs typically results in the SharePoint worker process launching command-line tools:

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = 4688
  StartTime = (Get-Date).AddDays(-60)
} | Where-Object {
  $_.Message -match 'w3wp\.exe' -and
  $_.Message -match 'cmd\.exe|powershell\.exe|net\.exe|net1\.exe|whoami\.exe|certutil\.exe'
} | Select-Object TimeCreated, Message |
  Export-Csv -Path "C:\Temp\SP-ProcessCreation-Review.csv" -NoTypeInformation

Any instance of w3wp.exe spawning cmd.exe or powershell.exe outside of a known maintenance window should be investigated as a potential indicator of compromise.

Review IIS Logs for Anomalous POST Requests

Deserialization exploits require sending crafted payloads to the server. Check your IIS logs for unusual POST requests to SharePoint service endpoints:

Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC*\*.log" -Pattern "POST.*_vti_bin|POST.*_api" |
  Where-Object { $_.Line -notmatch "svc_sharepoint|sp_farm|sp_search|sp_crawl" } |
  Select-Object -First 200

Replace the service account names in the filter with the actual accounts used in your farm. Look for POST requests from IP addresses or user agents that are unfamiliar, particularly during off-hours or from external IP ranges.

Audit SharePoint Service Account Activity

The exploit runs code as the SharePoint service account. Check Active Directory logs (Event ID 4624, 4672) for the SharePoint farm account performing actions outside its normal pattern, such as authenticating to servers it does not normally touch, or receiving privilege escalations.

Look for Web Shells and Unauthorized Files

Attackers who achieve code execution on SharePoint servers frequently drop web shells for persistent access. Check the SharePoint web application directories and the _layouts directory for recently modified or created .aspx, .ashx, or .asmx files that your team did not deploy:

Get-ChildItem -Path "C:\inetpub\wwwroot\wss\VirtualDirectories" -Include *.aspx,*.ashx,*.asmx -Recurse |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-60) } |
  Select-Object FullName, LastWriteTime, Length |
  Sort-Object LastWriteTime -Descending

Get-ChildItem -Path "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS" -Include *.aspx,*.ashx,*.asmx -Recurse |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-60) } |
  Select-Object FullName, LastWriteTime, Length |
  Sort-Object LastWriteTime -Descending

Compare the results against your deployment records. Any file you cannot account for should be treated as a potential indicator of compromise and preserved for forensic analysis.

Check for Lateral Movement

If you find any of the indicators above, expand your investigation beyond SharePoint. An attacker who compromised the SharePoint service account likely attempted lateral movement into Active Directory, file servers, and other on-prem systems.

Check for new scheduled tasks, unfamiliar services, and recently created local administrator accounts on servers that share a network segment with the SharePoint farm:

Get-ScheduledTask |
  Where-Object { $_.Author -and $_.Author -notmatch 'Microsoft' } |
  Select-Object TaskName, TaskPath, Author

Get-LocalGroupMember -Group "Administrators"

Get-CimInstance Win32_Service |
  Where-Object { $_.StartMode -eq 'Auto' -and $_.PathName -notmatch 'Windows\\System32|Microsoft|Program Files' } |
  Select-Object Name, DisplayName, PathName, StartName

Review the output for tasks, administrator accounts, or services you do not recognize. If your investigation reveals evidence of compromise, isolate the affected servers and engage your incident response resources immediately. Do not simply patch and resume operations.

The On-Prem SharePoint Blind Spot

This CVE highlights a pattern we see repeatedly across our managed IT client base and in assessments of new environments. On-premises SharePoint farms are some of the most inconsistently patched systems in SMB networks. The multi-step patch-then-PSConfig process discourages quick patching, and many farms are managed by a single person who may not track Microsoft security advisories. These systems tend to be treated as “internal only” and receive less security scrutiny than internet-facing servers.

That last assumption is dangerous. CVE-2026-45659 requires only an authenticated user with low-level permissions. For an attacker who has already compromised an employee account through phishing or credential theft, the SharePoint farm is reachable and exploitable from inside the network without any further privilege escalation.

Organizations that have been considering a migration to SharePoint Online should factor this into their timeline. Cloud-hosted SharePoint eliminates the on-prem patching burden entirely. For businesses that must keep SharePoint on-premises for compliance or data residency reasons, bringing those farms under an actively managed patching program is the minimum baseline.

Next Steps

1. Back up your SharePoint databases before starting the patch process
2. Check your SharePoint build number against the fixed versions listed above
3. Apply the correct KB update (KB5002868, KB5002870, or KB5002863) on every server in the farm
4. Run the SharePoint Products Configuration Wizard after the update installs, starting with the Central Admin server
5. Review Windows Event Logs, IIS logs, and service account activity for signs of exploitation before the patch date
6. Check for web shells in SharePoint web application directories and the _layouts folder
7. Ask your IT provider how they handle CISA KEV deadlines and whether your SharePoint farm is covered by their patching process

If you need help with emergency patching, post-compromise verification, or bringing your SharePoint environment under active management, contact our team at 800-985-1365. We provide managed security and managed IT services for businesses across Texas and Oklahoma.