Your On-Prem SharePoint Is the Attacker's Front Door: A Post-CVE-2026-56164 Hardening Guide

A manufacturing firm in Derby called us on a Tuesday morning because their intranet was "running slow". Twenty minutes into the investigation, we found a web shell sitting on their SharePoint server, quietly harvesting credentials. The firm had roughly forty staff, no dedicated security team, and a SharePoint box that had been happily serving documents for six years. Nobody had thought about it in months. That is exactly the sort of target attackers love, and it is exactly the sort of target now in the crosshairs of CVE-2026-56164.

If you still run SharePoint Server on your own hardware — 2016, 2019, or Subscription Edition — this one is not optional reading. It is being exploited right now, in the wild, against real UK businesses.

Why the CVSS score is lying to you

The first thing you will notice about CVE-2026-56164 is that its base CVSS score looks almost reassuring. It sits below the level that usually triggers panic. Plenty of IT managers glance at that number, decide it can wait until the next patch cycle, and move on.

That is a trap.

CVSS measures the theoretical severity of a single vulnerability in isolation. It does not measure how attackers actually behave. In the real world, this flaw is being chained with other weaknesses to achieve remote code execution and, worryingly, to steal the cryptographic machine keys that SharePoint uses to sign and validate requests. Once an attacker has those keys, patching the original hole does nothing. They can forge trusted tokens and walk straight back in through a door you thought you had locked.

That is the pattern we saw with the ToolShell exploitation wave against SharePoint in 2025, and CVE-2026-56164 follows the same playbook. A modest score on paper, a devastating outcome in practice. The number tells you about the lock; it says nothing about the burglar who already has a copy of your key.

Why on-prem SharePoint is such an attractive front door

SharePoint servers are unusually valuable to attackers for a few reasons.

They are almost always internet-facing, because the whole point is that staff reach them from home, from client sites, from their phones. They sit inside your network, often with generous permissions, connected to Active Directory. And they hold exactly the documents an attacker wants: contracts, HR records, finance spreadsheets, that folder marked "passwords" that somebody swears they will tidy up one day.

Compromise the SharePoint box and you have a foothold on the inside, a directory of who works where, and a shortcut to the crown jewels. From there, ransomware or data theft is a short hop. This is why the National Cyber Security Centre and CISA keep flagging SharePoint specifically rather than as one item on a long list.

The CISA deadline, and why it matters even if you are not American

CISA has added CVE-2026-56164 to its Known Exploited Vulnerabilities catalogue and set a firm remediation deadline for US federal agencies. If your reaction is "I'm a plumbing supplier in Mansfield, why do I care what the Americans say" — fair question, but the deadline is a useful signal.

CISA only sets these deadlines for vulnerabilities it has confirmed are being actively exploited. The clock is a public statement that this is not hypothetical. UK regulators and cyber insurers watch the KEV catalogue closely. If you suffer a breach through a vulnerability that was on the KEV list, and you failed to act within a reasonable window, expect an awkward conversation with your insurer about whether they will pay out. "We didn't get round to it" is not a defence that ages well.

Treat the CISA date as your date too.

The hardening checklist

Here is what to do, in order. Patch first, then harden, then verify. Do not skip the verification step, because with this class of attack a patch alone is not enough.

1. Apply the security update immediately

Install the latest Microsoft security updates for your specific SharePoint version. Check the version number carefully — updates for 2019 will not install on 2016, and Subscription Edition has its own track. After installing, run the SharePoint Products Configuration Wizard or the equivalent PowerShell command. A shocking number of "patched" servers are still vulnerable because someone downloaded the update but never completed the post-installation step.

2. Enable AMSI integration

The Antimalware Scan Interface (AMSI) lets your endpoint protection inspect what SharePoint is being asked to run before it runs. For this attack chain, AMSI in Full Mode is the single most effective mitigation, because it can catch the malicious payloads even when other layers fail.

In Central Administration, go to Security, then Manage antimalware settings, and enable AMSI. For older builds you may need to enable it through PowerShell. Set it to Full Mode, not the more permissive default, and confirm you have a compatible antivirus engine — Microsoft Defender works, and so do most reputable third-party products. AMSI without a real scanning engine behind it does nothing.

3. Rotate the machine keys — this is the step people forget

Because this exploit steals cryptographic keys, patching does not evict an attacker who already has them. After patching and enabling AMSI, you must rotate the ASP.NET machine keys and then restart IIS.

Run Update-SPMachineKey for the affected web applications, then iisreset. If you have any suspicion the server was already compromised, rotate the keys again after your investigation, because keys stolen during the incident remain valid until you replace them. This is the difference between closing the door and changing the locks.

4. Get it off the open internet

Ask a blunt question: does this server genuinely need to be reachable from the entire internet? For most SMEs the honest answer is no. Staff can reach it through a VPN or a Zero Trust access broker instead. Putting SharePoint behind a VPN removes it from the scanning tools attackers use to find fresh targets. You cannot be exploited through a door nobody outside can see.

If public access is truly required, put it behind a web application firewall and restrict inbound traffic to known IP ranges where you can.

5. Hunt for what may already be there

Assume nothing. Check the SharePoint LAYOUTS directory and other web-accessible folders for suspicious .aspx files, particularly ones with random names or recent timestamps. Review IIS logs for odd POST requests to authentication or ToolPane endpoints. Look at scheduled tasks and new local accounts. If you do not have the in-house skill to do this confidently, bring someone in who does — a quiet compromise is worse than an obvious one because it lasts longer.

6. Reduce your exposure for good

Apply least privilege to SharePoint service accounts. Keep your antivirus definitions current. Turn on logging and actually send it somewhere you will look. And put a reminder in the diary to check for SharePoint updates every single patch Tuesday, because there will be a next one.

The bigger question

Every time we clean up after an incident like the one in Derby, the same thought surfaces: why is this business running its own SharePoint server at all? For a forty-person firm, keeping a public-facing server patched, hardened, and monitored is a genuine burden — and a single missed step, as we have seen, can undo everything.

For many SMEs, SharePoint Online in Microsoft 365 removes the patching problem entirely, because Microsoft carries it. That is not a decision to make in a panic mid-incident, but it is worth putting on the agenda once the immediate fire is out.

For now, though, patch it, enable AMSI in Full Mode, rotate those machine keys, and get the thing off the open internet. Attackers are already knocking. If you are not sure whether your SharePoint server is exposed or already compromised, get in touch — we would far rather help you check than help you clean up.