Patch Tuesday Analysis: SharePoint Zero-Day (CVE-2026-30123) and 169 Flaws
Microsoft dropped a massive update today—169 CVEs in total, which is a new record for them recently. The headline grabber is CVE-2026-30123, a SharePoint Server zero-day currently under active attack in the wild.
While most of the batch is rated 'Important', this SharePoint vulnerability is rated Critical. The early reports suggest it allows for remote code execution (RCE) without authentication. If you are running SharePoint Server on-premises, treat this as an emergency.
I've whipped up a quick PowerShell snippet to verify your farm build version against the patched baseline (assuming the March 2026 CU):
# Check SharePoint Farm Build Version
try {
$spFarm = Get-SPFarm
$buildVersion = $spFarm.BuildVersion
Write-Host "Current Farm Build: $buildVersion"
# Check against vulnerable builds (example threshold)
if ($buildVersion -lt [Version]"16.0.17328.20000") {
Write-Host "STATUS: VULNERABLE - Patch immediately." -ForegroundColor Red
} else {
Write-Host "STATUS: Patched." -ForegroundColor Green
}
} catch {
Write-Host "Error: Ensure you are running as SharePoint Admin." -ForegroundColor Yellow
}
For the SOC folks, you should be hunting for suspicious POST requests to the SharePoint APIs in your IIS logs. We are seeing exploits targeting the `/_vti_bin/` paths:
W3CIISLog
| where sSiteName contains "SharePoint"
| where csUriStem endswith ".asmx" or csUriStem contains "_vti_bin"
| where scStatus == 500 and csMethod == "POST"
| summarize count() by cIP, csUriStem
| top 10 by count_
Given the size of this patch batch, are you prioritizing the SharePoint zero-day over the standard OS cumulative updates?
Good catch on the build version check. We usually rely on SCCM compliance reporting, but it often lags for specific component versions like SharePoint.
One thing to add: If you can't patch immediately, look at restricting access to the /_vti_bin/client.svc endpoint at the WAF level. IOCs suggest the exploit chain involves deserialization via the SOAP client services. Blocking non-internal IPs on that specific endpoint is a decent temporary mitigation while you schedule the maintenance window.
That KQL query is solid. I'd also recommend correlating those 500 errors with process creation events on the SharePoint server using Sysmon.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows- Sysmon/Operational'; ID=1} |
Where-Object {$_.Message -like '*w3wp.exe*' -and $_.Message -like '*powershell.exe*'}
If you see `w3wp.exe` spawning a shell, you're already too late. We saw similar behavior with the older 'Autodiscover' vulnerabilities in Exchange.
169 flaws? That is a nightmare for an MSP environment. We have clients on legacy 2019 farms that are going to scream about the downtime for this CU.
Does anyone know if the 'Important' Exchange updates included in this batch are being exploited too, or is it just the SharePoint RCE we need to panic about right now? I can only handle one fire drill at a time.
Valid concern, Frank. If downtime is blocking you, consider enforcing URL rewrite rules at the WAF level to block known vulnerable patterns until the patch deploys.
Building on Dana’s forensics point, if you suspect compromise before the patch, scan for recent web shell artifacts in the IIS directories:
Get-ChildItem "C:\inetpub\wwwroot\wss\VirtualDirectories" -Recurse -Include *.aspx,*.ashx | Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-1)}
It's a quick triage step to ensure you aren't patching over an active foothold.
To assist with the SCCM lag Sam mentioned, I usually validate the patch directly on the SharePoint servers using the SharePoint Management Shell. This confirms the build version immediately rather than waiting for compliance reporting.
(Get-SPFarm).BuildVersion
For Frank's legacy farms, ensure you backup the farm configuration before applying the CU, as rollback procedures on 2019 can be tricky if the database upgrade fails.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access