ToolShell and SharePoint RCE show why patching is not enough

At a glance

What this is: This is an analysis of the ToolShell SharePoint RCE and the warning that patching alone does not remove attacker presence or stop spread.

Why it matters: It matters to IAM and security teams because vulnerable collaboration platforms can become a fast path into high-value systems if access, segmentation, and monitoring are weak.

By the numbers:

• CISA has added CVE-2025-53770 to the Known Exploited Vulnerabilities catalog, which makes it a required fix under Binding Operational Directive 22-01.
• The vulnerability impacts SharePoint 2019 and Subscription Edition deployments.

👉 Read Illumio's analysis of the ToolShell SharePoint RCE and containment risk

Context

ToolShell is a remote code execution vulnerability in on-premises SharePoint that can let an attacker run arbitrary code with elevated privileges and no user interaction. In plain terms, a vulnerable collaboration platform becomes an entry point, and if that platform sits inside a trusted network, the access problem quickly turns into a containment problem.

For identity and access teams, the key issue is not only whether a patch exists but whether compromised systems can still reach other systems after exploitation. That is where shared trust, overbroad connectivity, and weak segmentation turn an application flaw into a broader identity and infrastructure incident.

Key questions

Q: What fails when a patched application can still reach privileged internal systems?

A: Patch success does not equal incident containment. If a compromised server can still communicate with administrative services, file stores, or sensitive workloads, the attacker may retain a path for lateral movement even after the vulnerable code is fixed. That is why reachability and segmentation must be treated as part of the control environment, not an optional hardening layer.

Q: Why do on-premises application vulnerabilities create identity and access risk?

A: Because the attack often lands on a trusted internal system that already has access to data, services, and sometimes service accounts. Once that system is compromised, the attacker can abuse the trust relationships around it, which is why identity scope, service permissions, and network paths all matter in the response.

Q: How do security teams know if patching has actually contained an exploit?

A: They do not know from version numbers alone. Teams need to confirm that no persistence remains, no abnormal outbound connections continue, and no unexpected identity or process activity is present on affected hosts. If the system still shows suspicious behaviour after remediation, containment is incomplete.

Q: Which frameworks apply when a server compromise can spread across the environment?

A: NIST CSF, Zero Trust guidance, and control frameworks such as NIST SP 800-53 all become relevant when one compromised system can still move through the network. The practical test is whether access paths, privileges, and communication routes are constrained enough to keep the incident local.

Technical breakdown

How SharePoint RCE becomes an internal foothold

Remote code execution means the attacker can run commands on the target system as if they had local access. In this case, SharePoint vulnerability exposure matters because the application often sits close to sensitive content and internal workflows, so an exploit can bypass the usual user-facing authentication path. Once code execution is achieved, the attacker no longer needs to rely on phishing or credential theft to continue the intrusion. The compromise shifts from external exploitation to internal control of a trusted server.

Practical implication: treat internet-facing collaboration platforms as possible internal footholds, not just patch targets.

Why patching does not remove post-exploitation risk

A patch closes the vulnerable code path, but it does not automatically remove payloads, persistence mechanisms, or stolen session material already planted during exploitation. If defenders only fix the software version, they may leave attacker-controlled processes, scheduled tasks, or lateral movement routes intact. This is why CISA pairs remediation with log review and abnormal activity checks. The operational question is whether the environment was merely exposed to exploitation or was also used as a staging point for further access.

Practical implication: pair patching with forensic review, persistence hunting, and identity log correlation.

How segmentation limits blast radius after exploitation

Segmentation limits who or what a compromised workload can talk to. In zero trust terms, the goal is to remove implicit trust between systems so a server compromise does not become a network-wide event. For SharePoint, that means narrowing inbound and outbound paths, especially to privileged services, file stores, and administrative systems. This matters because the attacker’s next move is often discovery and lateral movement, not immediate exfiltration. The control failure is excessive reachability, not only the original vulnerability.

Practical implication: restrict east-west paths from vulnerable workloads to the minimum required communication set.

Threat narrative

Attacker objective: The attacker wants reliable internal foothold access that can be used to expand control, stage further activity, and persist inside the environment.

1. Entry occurs through an actively exploited SharePoint RCE vulnerability that requires no user interaction and no social engineering.
2. Escalation follows when the attacker executes arbitrary code with elevated privileges on the compromised on-premises server.
3. Impact emerges when the attacker uses that foothold to move laterally, stage additional payloads, or persist beyond the patched vulnerability.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Patch velocity is not a containment strategy. The article reinforces a control reality that many programmes still underweight: fixing the vulnerable application does not necessarily neutralise the incident. Once an attacker has executed code on a trusted server, the decisive question becomes what that server can still reach. For identity and access teams, this is a reminder that access scope and network reachability are part of incident resilience, not only operational convenience.

SharePoint exposure becomes a governance problem when trusted internal paths stay open. The vulnerability matters because collaboration platforms often sit inside the same trust fabric as file stores, administration tools, and mission systems. If those paths are not tightly constrained, a single exploit can bridge from application compromise to privileged lateral movement. That is where segmentation, access policy, and service account governance intersect.

Blast-radius control is the named concept this incident sharpens. The breach pattern is not simply vulnerability exploitation, but the rapid conversion of one compromised system into a launch point for broader access. That means identity governance cannot stop at authentication and patch compliance. It must also account for which identities, services, and workloads can be reached after the first foothold, especially in environments that still assume internal trust.

This kind of event validates Zero Trust as an operating model, not a slogan. The article’s core warning is that exploitation can happen before defenders finish remediation, and the environment still needs to resist spread after compromise. That aligns with NIST CSF and Zero Trust thinking: limit trust, verify continuously, and make lateral movement expensive. Practitioners should treat containment as a first-class control objective, not a post-incident afterthought.

For identity programmes, the hidden risk is often service reachability rather than human login failure. Shared administrative access, broad service permissions, and implicit network trust can all turn an application compromise into a wider identity incident. The practitioner conclusion is straightforward: if a compromised workload can still talk to privileged services, the control plane is already too open.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a broader breach pattern: The 52 NHI Breaches Analysis shows how exposed credentials and weak lifecycle control turn one incident into repeated access.

What this signals

Patch-and-pray will keep failing in environments where trust paths stay wide open. The practical programme shift is toward containment engineering, where segmentation, service isolation, and identity-aware access paths are designed before the next exploit lands. That is especially relevant in mixed human and machine identity estates, where service access often outlives the patch window.

Standing access is the hidden amplifier in many post-exploit incidents. Where servers, service accounts, and admin tools still have broad reach, one compromised workload can become a platform for escalation. That is why NHI governance, service account review, and least-privilege enforcement are part of breach resilience, not just identity housekeeping.

Blast radius is now a measurable security objective. Programmes should test whether a vulnerable workload can still reach privileged services after compromise and use that result to drive segmentation priorities. The operational benchmark is not only whether the patch is applied, but whether the attack has anywhere left to go.

For practitioners

• Tighten network reachability from SharePoint servers Restrict inbound and outbound communication so a compromised SharePoint host cannot contact privileged systems, file stores, or administrative endpoints unless explicitly required.
• Correlate patching with forensic log review Review authentication, process, and endpoint telemetry for signs of post-exploitation activity, including unusual child processes, new outbound connections, and unexpected service creation.
• Validate segmentation around mission systems Test whether a compromised collaboration server can reach classified, sensitive, or mission-critical resources and remove unnecessary east-west paths before the next exploit window opens.
• Hunt for persistence after remediation Check scheduled tasks, startup items, scripts, and newly created identities on affected systems, because a patched vulnerability can still leave attacker persistence in place.

Key takeaways

• ToolShell shows that a patched vulnerability can still leave an attacker foothold if persistence and reachability are not checked.
• The meaningful risk is not only initial compromise, but whether a trusted server can still move laterally after exploitation.
• Containment, segmentation, and forensic validation are the controls that determine whether this kind of incident stays local or spreads.

Key terms

• LLM Remote Code Execution: A condition where a large language model integration causes arbitrary code to run on the host or backend system. The model is usually not the direct vulnerability. The failure appears when attacker-shaped model output is parsed, trusted, and handed to a dangerous execution path.
• Blast Radius: Blast radius is the amount of damage an attacker can cause after an initial compromise. It is shaped by segmentation, privilege scope, and trust relationships. Smaller blast radius means a single foothold cannot easily spread to other systems, services, or sensitive data stores.
• East-West Traffic: East-west traffic is communication between internal systems inside the same environment, such as server-to-server or workload-to-workload connections. It matters because attackers often use these paths after initial compromise to move laterally, discover targets, and reach privileged services that were never meant to be broadly accessible.

What's in the full article

Illumio's full blog post covers the operational detail this post intentionally leaves for the source:

• Illumio Insights examples for identifying abnormal workload-to-workload communication after a SharePoint compromise
• Segmentation policy examples for limiting east-west traffic from vulnerable collaboration servers
• Practical containment guidance for reducing blast radius in hybrid federal-style environments
• Discussion of how their approach fits a Zero Trust operating model without replacing patching

👉 Illumio's full post covers the patching caveats, detection signals, and segmentation response in more detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity with a focus on practical control design. It is suitable for practitioners who need to connect identity governance to resilience, containment, and access control decisions.