Should organisations isolate public SharePoint servers or focus first on patching?

Why the answer is not patch or isolate, but sequence them correctly

For an internet-facing SharePoint server, the practical question is not whether patching matters, it does. The issue is whether the environment is already exposed to active exploitation. If exploit activity is underway, the first priority is to reduce live attacker access, confirm whether compromise has already occurred, and then close the vulnerability window with patching.

Patching reduces future exposure, but it does not automatically remove an attacker who already has a foothold. Public isolation, tighter access controls, and immediate hunting reduce the chance that a compromised server can still be used as a bridge into internal systems while patching and recovery are being carried out.

What isolation actually changes on a public SharePoint server

Isolation is valuable because it changes attacker reachability. A public SharePoint server is often a high-value entry point, especially when the service is exposed directly to the internet and connected to internal resources. CISA's Known Exploited Vulnerabilities Catalog is a useful reminder that confirmed exploitation should be treated differently from theoretical exposure.

In practice, isolation can mean removing the server from public access, restricting it to trusted networks, placing it behind tighter filtering, or temporarily disabling the exposed service if business continuity allows. That reduces the attacker’s ability to continue probing, re-entering, or pivoting while responders assess whether the host has already been compromised.

ToolShell SharePoint exploitation 2025 illustrates why this matters: patching alone may not be enough if attackers have already stolen keys or established persistence. Once that happens, the server can remain dangerous even after the original bug is fixed.

Why patching still matters, and why hunting comes before reopening access

Patching is the durable control. It closes the known vulnerability, lowers the chance of repeat exploitation, and helps eliminate the original entry path. But when exploitation is already active in the wild, patching is only one step in a broader containment and recovery sequence.

The safer sequence is to first contain, then investigate, then remediate, then restore. That is because an unpatched server can be attacked again, while a patched but already-compromised server can still be used for persistence, credential theft, or lateral movement. Hunting for web shells, suspicious accounts, abnormal authentication patterns, and outbound connections helps determine whether the host is still trusted enough to re-expose.

Authoritative vulnerability tracking helps with prioritisation, but not with sequencing alone. NIST's National Vulnerability Database helps teams confirm the affected software and understand severity, while FIRST EPSS can help prioritise which issues are most likely to be exploited. When exploitation is already observed, however, the operational question becomes containment first, not just scoring.

What good practice looks like during active exploitation

When a public SharePoint server may already be under attack, good practice is to reduce exposure quickly, preserve evidence, and make restoration conditional on verification. That usually means limiting external access, checking logs and filesystem indicators, reviewing privilege changes, and confirming whether any linked credentials, tokens, or keys were exposed during the intrusion.

It also means treating the server as a potentially contaminated trust boundary until proven otherwise. If there is evidence of code execution, stolen secrets, or post-exploitation activity, the decision to restore public access should depend on whether the team can explain how the attacker entered, what they changed, and what was done to remove persistence.

Practitioner takeaway: If exploitation is actively unfolding, do not frame the decision as “patch or isolate”, isolate and hunt first, because patching without containment can leave an already-compromised server online long enough to be reused or to pivot deeper into the network.

Related resources from NHI Mgmt Group

• Should organisations validate patching or focus on awareness first?
• Should organisations prioritise patching or retiring outdated applications first?
• Should organisations prioritise patching or identity hardening first after active exploitation is detected?
• What should public sector organisations do first when they need to balance transparency with privacy and security?