Am I vulnerable?
CVE-2026-56164 is a missing-authentication flaw (CWE-306) in on-premises Microsoft SharePoint Server. An unauthenticated network attacker reaches a critical server function without any credentials, and Microsoft flagged the CVE "Exploitation Detected" on the day it published (2026-07-14). CISA added it to the KEV catalog the same day with a three-day remediation fuse, alongside two other SharePoint bugs it says are being exploited together. This is on-prem only. SharePoint Online (Microsoft 365) is not in scope.
The score itself is a story worth knowing before you triage: Microsoft, as the assigning CNA, rated this only 5.3 (Moderate), while NVD's own analysts scored it 9.8 (Critical) with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Both agree it needs no privileges and no user interaction. When a bug this reachable is confirmed exploited, treat the higher assessment as your planning number and patch on the KEV clock, not the CNA score.
Affected versions
| Product |
Vulnerable range |
Fixed build |
| SharePoint Enterprise Server 2016 |
16.0.0 up to < 16.0.5561.1001 |
16.0.5561.1001 |
| SharePoint Server 2019 |
16.0.0 up to < 16.0.10417.20175 |
16.0.10417.20175 |
| SharePoint Server Subscription Edition |
16.0.0 up to < 16.0.19725.20434 |
16.0.19725.20434 |
Diagnostic checks (read-only)
- Report the farm build:
(Get-SPFarm).BuildVersion. A build below the fixed build for your edition (above) is vulnerable.
- Confirm the July 2026 update is installed:
Get-SPProduct -Local | Select-Object ProductName, PatchName, Version. Absence of KB5002891 (2016), KB5002883 (2019), or KB5002882 (Subscription Edition) means the farm is unpatched.
- Verify the AMSI mitigation is actually blocking:
Invoke-WebRequest -Uri "https://servername/sites/sitename?amsiscantest:x5opap4pzx54p7cc7$eicar-standard-antivirus-test-fileh+h*" -Method GET. With AMSI active and Defender present, the request is blocked (Defender logs Exploit:Script/SharePointEicar.A). If the page returns HTTP 200 normally, AMSI is not protecting that web application.
Any internet-facing SharePoint farm below the fixed build should be considered exposed and triaged for compromise, not just patched.
Vulnerability
The defect is CWE-306, Missing Authentication for a Critical Function. A function that should require an authenticated, authorized caller can be reached over the network by anyone who can send the request. There is no credential to steal, no session to hijack, and no phishing step. That absence of a precondition is why both scorers set PR:N and UI:N, and it is what makes the flaw attractive to mass-scanning operators as much as to targeted intruders.
The vendor-versus-NVD score gap is the operational headline. Microsoft's 5.3 vector reports low impact and treats the primitive as an elevation of privilege; NVD's 9.8 reports full confidentiality, integrity, and availability loss. Rapid7 called the low base score "an imperfect signal concealing something much spicier," and the Zero Day Initiative's Dustin Childs framed it plainly: when something this reachable is being actively abused, patch it now and worry about the score later. Tenable likewise flagged it as a zero-day despite the Moderate label. The lesson for triage is to rank this by exploitability and KEV status, not by the CNA severity string.
SharePoint runs on IIS under a privileged, Active-Directory-joined service account, which is why an unauthenticated reach into a server function is dangerous well beyond the immediate host. Public proof-of-concept code was not located for this specific CVE at the time of writing, but active in-the-wild exploitation is confirmed by both Microsoft and CISA, so the practical exposure does not depend on a public exploit appearing.
Threat model
Who would exploit this: the unauthenticated, no-interaction network vector lowers the bar for everyone. The most likely operators are financially motivated criminals, split between opportunistic ransomware affiliates who mass-scan the internet for exposed on-prem SharePoint and initial-access brokers who resell footholds. State-aligned actors are a credible secondary category, since SharePoint is an internet-facing repository of corporate documents inside AD-joined enterprises, which suits espionage and long-dwell collection. No named actor is tied to this specific CVE by a primary source, so attribution is left open.
What they're after:
- Initial foothold and code execution on the SharePoint host
- Persistence via stolen IIS machine keys and ViewState secrets that survive patching
- Exfiltration of documents, PII, and intellectual property held in the farm
- Lateral movement into Active Directory, file shares, and connected systems
- Ransomware deployment or extortion once access is broad
Attack chain: an attacker scans for reachable on-prem SharePoint and sends a crafted request that hits the unauthenticated function, gaining a server-side foothold without valid credentials. Post-exploitation typically harvests the IIS machine keys and abuses deserialization to establish durable, key-based re-entry. Because SharePoint runs as a privileged AD service account, the operator then pivots toward directory services and stored content.
Blast radius: a single compromised farm yields its stored documents plus the service account's rights into Active Directory, opening a path to domain resources, file shares, and any cloud connectors. Theft of machine keys lets an attacker forge trusted payloads and return even after the patch, turning one server into durable, farm-wide access rather than a contained single-host incident.
Mitigation
Patch
Install the July 2026 security update for your edition. This is the real fix, especially for 2016 and 2019 farms where the interim mitigation below is weaker.
| Product |
Fixed build |
KB |
| SharePoint Enterprise Server 2016 |
16.0.5561.1001 |
KB5002891 |
| SharePoint Server 2019 |
16.0.10417.20175 |
KB5002883 |
| SharePoint Server Subscription Edition |
16.0.19725.20434 |
KB5002882 |
Because attackers commonly steal ASP.NET machine keys during exploitation, patching alone may not evict an intruder who has already forged persistence. If you find evidence of compromise, rotate SharePoint machine keys (Update-SPMachineKey) and restart IIS after patching, then hunt for planted webshells and IIS modules.
Configuration mitigation
Microsoft's interim guidance is to ensure the Antimalware Scan Interface (AMSI) is integrated so SharePoint and IIS worker-process memory, including POST bodies, are scanned. AMSI needs an AMSI-capable antivirus such as Microsoft Defender. Full request-body scanning is only available on Subscription Edition 25H1 and later; 2016 and 2019 farms get header scanning only, so patching remains the real fix for those SKUs.
Activate AMSI integration for a web application:
Enable-SPFeature -Identity 4cf046f3-38c7-495f-a7da-a1292d32e8e9 -Url <web application URL>
Set AMSI request-body scan to Full (Subscription Edition 25H1+):
$webAppUrl = "http://spwfe"
$webApp = Get-SPWebApplication -Identity $webAppUrl
$webApp.AMSIBodyScanMode = 2 # 0 = Off, 1 = Balanced, 2 = Full
$webApp.Update()
# Iisreset # may be required when switching modes
Compensating controls
- Get on-prem SharePoint off the public internet. Front it with a VPN or reverse proxy that enforces authentication, since the entire value of this bug is unauthenticated network reach.
- Segment and least-privilege the service account. Constrain what the SharePoint app-pool identity can touch in AD and on file shares to cap lateral movement.
- Watch for the machine-key theft, not just the entry. Post-patch persistence rides stolen ValidationKey and DecryptionKey material, so treat key access as a high-value alert.
Detection (starter rules, validate before deploying)
These rules are AI-generated starter content. Test against your own telemetry and tune the false positives before deploying to production. The signals below draw on the publicly documented ToolShell exploitation pattern against on-prem SharePoint, which shares this CVE's unauthenticated profile; adapt them to your environment.
Network and log signals
- POST to
/_layouts/15/ToolPane.aspx?DisplayMode=Edit (or /_layouts/16/ToolPane.aspx) carrying a Referer of /_layouts/SignOut.aspx. This Referer-spoof plus ToolPane combination is highly abnormal in legitimate traffic.
- IIS
cs-uri-stem hits for newly appearing .aspx files under the LAYOUTS path (for example spinstall0.aspx, spinstall\d+.aspx, or short random-named .aspx) immediately after a ToolPane POST from the same source IP.
w3wp.exe (the SharePoint IIS worker) spawning cmd.exe, powershell.exe, cscript, or wscript. SharePoint should almost never fork a command interpreter from the web worker.- New or modified
.aspx / .ashx files written under the SharePoint hive (...\Web Server Extensions\15\TEMPLATE\LAYOUTS\ or ...\16\TEMPLATE\LAYOUTS\) by the app-pool identity, especially small files referencing MachineKey, ValidationKey, or DecryptionKey.
- Command lines under the SharePoint app-pool identity that read
web.config or reference System.Web.Configuration.MachineKeySection / GetApplicationConfig, plus follow-on schtasks.exe creation or new IIS module registration.
YARA
rule CVE_2026_56164_sharepoint_toolpane_webshell_starter
{
meta:
author = "CVE Brief - Detection Engineering"
description = "AI-generated STARTER rule. Flags suspicious ASP.NET (.aspx/.ashx) files dropped into the SharePoint LAYOUTS hive that harvest ASP.NET MachineKey material or expose command execution, behavior consistent with unauthenticated SharePoint RCE post-exploitation (CVE-2026-56164 / ToolShell-style). Validate before deploying; will not catch obfuscated/encrypted payloads."
reference = "https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/"
cve = "CVE-2026-56164"
confidence = "medium"
note = "Behavioral string match only, contains NO CVE-specific file hashes."
strings:
$aspx1 = "<%@ Page" ascii nocase
$aspx2 = "<%@ WebHandler" ascii nocase
$aspx3 = "Language=\"C#\"" ascii nocase
// Cryptographic key / MachineKey harvesting
$key1 = "ValidationKey" ascii nocase
$key2 = "DecryptionKey" ascii nocase
$key3 = "MachineKeySection" ascii nocase
$key4 = "GetApplicationConfig" ascii nocase
$key5 = "CompilationSection" ascii nocase
// Generic webshell / command-exec indicators
$cmd1 = "System.Diagnostics.Process" ascii nocase
$cmd2 = "ProcessStartInfo" ascii nocase
$cmd3 = "cmd.exe" ascii nocase
$cmd4 = "eval(" ascii nocase
$cmd5 = "Request[" ascii nocase
$cmd6 = "System.Reflection.Assembly.Load" ascii nocase
// SharePoint context (helps scope to the product)
$sp1 = "Microsoft.SharePoint" ascii nocase
$sp2 = "_layouts" ascii nocase
condition:
any of ($aspx*) and
filesize < 200KB and
(
(2 of ($key*)) or
(any of ($sp*) and 2 of ($cmd*))
)
}
Sigma
title: Suspicious Unauthenticated SharePoint ToolPane Access (CVE-2026-56164 Starter)
id: 8f3c1a94-2b7e-4d6a-9c11-56164ee0a1b2
status: experimental
description: >
AI-generated STARTER rule. Detects the unauthenticated-access pattern used against
on-prem SharePoint Server (CVE-2026-56164): a POST to the ToolPane.aspx admin endpoint
carrying a spoofed Referer of /_layouts/SignOut.aspx. This Referer-spoof against ToolPane
is highly abnormal and is the core exploitation signal. Requires IIS/web logs that record
the Referer (cs-referer) field. Validate in your environment before deploying.
references:
- https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/
author: CVE Brief - Detection Engineering
date: 2026/07/15
tags:
- attack.initial_access
- attack.t1190
- cve.2026.56164
logsource:
category: webserver
detection:
selection_method:
cs-method: 'POST'
selection_uri:
cs-uri-stem|contains: '/ToolPane.aspx'
selection_referer:
cs-referer|contains: '/_layouts/SignOut.aspx'
condition: selection_method and selection_uri and selection_referer
falsepositives:
- Legitimate SharePoint web-part editing is authenticated and does not normally carry a SignOut.aspx Referer, so genuine false positives are rare.
- Security scanners, vulnerability tools, or internal red-team exercises replaying the request.
- Custom SharePoint solutions or load-testing harnesses that post to ToolPane with unusual Referer headers.
level: high
Rule notes
The Sigma rule keys on the product-specific exploitation primitive (a POST to ToolPane.aspx with a spoofed /_layouts/SignOut.aspx Referer), so it is high-signal but depends on IIS logging the cs-referer field and can be evaded if the attacker changes the Referer. The YARA rule is purely behavioral (MachineKey harvesting or SharePoint-plus-exec strings in an .aspx) with no CVE-specific hashes, so scope it to the LAYOUTS directories and expect it to miss well-obfuscated webshells. Both are starting points for hunting, not turnkey production detections.
References