Understand the SharePoint RCE: Exploitations, Detections, and Mitigations
Executive summary
On July 19, 2025, Microsoft disclosed CVE-2025–53770, a critical vulnerability in the ToolPane.aspx component of on-premises Microsoft SharePoint Servers. This vulnerability can allow an unauthenticated attacker to achieve unauthenticated remote code execution (RCE) through improper filtering of HTTP request headers.
According to our data, more than 20% of observed environments are exposed to the SharePoint vulnerability.
Akamai is a Microsoft Active Protections Program (MAPP) partner, which allows us to deploy expedited protections for customers.
In this blog post, the Akamai Security Intelligence Group (SIG) provides an in-depth look at the vulnerability, the observed exploitation techniques, and our detection and mitigation strategies, including an Akamai Guardicore Segmentation Insight query.
An Akamai Adaptive Security Engine Rapid Rule is automatically providing protection for Akamai App & API Protector customers.
Akamai Hunt customers who were affected have already received detailed mapping of vulnerable assets.
Introduction
On July 19, 2025, an RCE vulnerability — dubbed ToolShell after the component in which the flaw lies — in on-prem instances of Microsoft SharePoint Server was made known (CVE-2025-53770, CVSS 9.8). The root cause is a combination of two bugs: an authentication bypass (CVE-2025-49706) and an insecure deserialization vulnerability (CVE-2025-49704). There have already been reports of ToolShell being exploited in the wild.
The vulnerability in the widely used collaboration platform was swiftly addressed by Microsoft and is fixed in the server versions 2016, 2019, and SharePoint Server Subscription Edition.
However, Microsoft has mentioned that end-of-service versions of SharePoint (2010 and 2013) will not receive patches and are therefore still at risk.
This is a clear example of a scenario where a “virtual patch” (such as segmentation) can make a critical difference. Even when official vendor patches are unavailable or delayed, organizations that use segmentation can still block exploitation attempts and minimize risk while maintaining business continuity.
What is SharePoint?
SharePoint is a widely used collaboration platform that offers a web‑based interface for storing and sharing documents, automating workflows, and providing robust enterprise search along with other productivity features. The platform’s ubiquity and deeply interconnected access amplifies the severity of the vulnerability and causes the potential for damage to skyrocket, which underscores the need for a swift response and remediation across all organizations that use SharePoint.
According to our observed environments, more than one-fifth of all organizations are currently unpatched and thus exposed to the SharePoint vulnerability. In nearly every case, each organization has multiple affected assets.
Vulnerability analysis
SharePoint’s ToolPane.aspx is a component responsible for assembling the UI side panel view. The exploitation of the vulnerability consists of two steps:
- Attackers can first perform an authentication bypass
- This bypass then allows them to exploit the second insecure deserialization vulnerability, leading to code execution on the server
Step 1: Exploiting the authentication bypass (CVE-2025-49706)
The first step in exploiting CVE-2025-49706 is to send a specially crafted POST request to the endpoint, manipulating the HTTP 'Referer' header. The attacker targets the endpoint value /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx with the crafted value /_layouts/SignOut.aspx to manipulate the system into trusting the request and its payload.
Step 2: Exploiting the deserialization vulnerability (CVE-2025-49704)
Once the authentication bypass is achieved, attackers can exploit the deserialization vulnerability to execute PowerShell code. In observed attacks, attackers deployed a malicious second-stage ASPX file designed to extract cryptographic keys that are signed (MachineKey) from web.config (which the server trusts), enabling stealthier follow-up exploitation (Figure 1).
Fig. 1: Malicious ASPX file to exploit CVE-2025-49704
This is a stealthy approach for a few reasons:
- The payloads appear legitimate to the application — they pass signature validation, so no alarms are triggered by viewstate tampering checks.
- The malicious code is executed within the normal SharePoint process (w3wp.exe), which blends in with legitimate activity.
- There’s no need to drop additional files or re-exploit authentication, reducing the forensic footprint.
This technique allows attackers to maintain access or escalate impact while avoiding many traditional detection mechanisms.
Remote code execution
By accessing the deployed malicious endpoint, attackers can extract the cryptographic secrets needed to sign serialized payloads (Figure 2).
Fig. 2: Example of the MachineKey value
The cryptographic information is then used to create a serialized C# code in a valid __VIEWSTATE payload based on the TypeConfuseDelegate gadget generator — a tool used to create an exploitable sequence of code that can be abused for deserialization attacks (Figure 3).
Fig. 3: Retrieving the __VIEWSTATEGENERATOR for malicious __VIEWSTATE payload signing
From that point, detecting malicious activity becomes significantly harder, as the payload executes within the legitimate w3wp.exe process.
Exploitation details
Multiple public proof-of-concept (PoC) exploits for CVE-2025-53770 have recently been seen on GitHub and other platforms. Threat actors are actively leveraging these PoCs to compromise unpatched SharePoint systems.
We observed active exploitation attempts targeting the SharePoint endpoint ‘/_layouts/15/ToolPane.aspx’ across multiple hostnames, originating from various IP addresses (Figure 4).
Fig. 4: Sample scanning activity for /_layouts/15/ToolPane.aspx POST requests
Analysis of Akamai Secure Internet Access Enterprise customer traffic showed DNS connections to one of the IPs associated with the campaign 96.9.125[.]147, which resolved to dynastyjusticecollective[.]site. This was independently mentioned by researcher @raffaele_forte, which supports our assumption that it’s malicious activity rather than benign scanning.
Indicators of compromise
107.191.58[.]76
104.238.159[.]149
96.9.125[.]147
dynastyjusticecollective[.]site
Detecting vulnerable applications
For Akamai Guardicore Segmentation customers, the following Insight queries can be used to detect vulnerable SharePoint applications (Figure 5) and remnants of successful exploitation (Figure 6).
SELECT name, version, publisher, install_date, install_location
FROM programs
WHERE REGEX_MATCH(name, '^Microsoft SharePoint Server (?:2010|2013|2016|2019|Subscription Edition)(?: Core)?$', 0) IS NOT NULL
Fig. 5: Akamai Guardicore Segmentation Insight query to detect vulnerable SharePoint installations
SELECT filename, path, datetime(mtime, 'unixepoch') AS modified_time, datetime(ctime, 'unixepoch') AS created_time, mode, uid, gid, type, size
FROM file
WHERE path IN ("C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\15\TEMPLATE\LAYOUTS\spinstall0.aspx", "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx", "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\debug_dev.js")
Fig. 6: Akamai Guardicore Segmentation Insight query to detect exploitation artifacts
Mitigation details
Mitigation by segmentation
If you are running SharePoint instances that are at the end of service or you have not been able to patch yet, segmentation and Zero Trust Network Access (ZTNA) can act as a virtual patch to prevent exploitation and lateral movement.
Akamai Guardicore Segmentation customers are strongly encouraged to add a block rule to deny traffic to vulnerable applications and deny attempts at exploitation and lateral movement.
- Restrict access to SharePoint servers
- Restrict SharePoint access to trusted entities, such as predefined labels in your microsegmentation policy or approved IP address ranges
- Deny all other unsolicited inbound traffic to the SharePoint service ports
- Contain lateral movement
- Ringfence your SharePoint servers to deny lateral movement attempts to other areas of your network in case of a compromise
Mitigation by Zero Trust Network Access
Akamai’s ZTNA solutions can significantly reduce the attack surface for CVE-2025-53770 by enforcing least-privilege access — even when systems can't be immediately patched.
Restrict access: Enforce identity-aware access policies (multi-factor authentication, device posture, role-based access) for SharePoint applications
Isolate vulnerable instances: Block direct network/VPN access to legacy SharePoint servers; route all access through ZTNA gateways
Monitor and alert: Enable access logging and monitor for unusual access patterns to vulnerable paths (e.g., /ToolPane.aspx)
Minimize exposure during rollouts: Disable external access to unpatched systems via ZTNA until updates are applied
Mitigation via Akamai App & API Protector
In response to SharePoint remote code execution (CVE-2025-49704, CVE-2025-53770), Akamai’s web application firewall (WAF) Threat Research Team released a new Rapid Rule on July 21, 2025, with a default action set to “Alert” (Figure 7).
3000969 - SharePoint Remote Code Execution Detected (CVE-2025-49704, CVE-2025-53770) v.1
Fig. 7: New WAF rule to address CVE-2025-49704/CVE-2025-53770
After confirming that the rule is accurate, the recommended Rapid Rule action was set to default action of “Deny” on July 22, 2025.
Summary
Organizations using on-premises Microsoft SharePoint servers should take immediate action to mitigate CVE-2025-53770.
- Start by applying official Microsoft patches where available
- For unsupported versions (2010 and 2013), implement virtual patching through segmentation to reduce exposure
- Review your environment for signs of exploitation using the provided detection queries
- Block known exploitation paths using segmentation and WAF rules
- Finally, ensure that SharePoint servers are properly isolated to prevent lateral movement in the event of a compromise
Final note
The Akamai SIG will continue to monitor and report on threats such as these for both our customers and the security community at large. To keep up with more breaking news from the Akamai SIG, check out our research home page and follow us on social media.
