The vulnerability under active attack
This is not a theoretical advisory; the flaw is being exploited right now. On 17 July 2026 the US Cybersecurity and Infrastructure Security Agency added CVE-2026-58644, a critical Microsoft SharePoint Server vulnerability, to its Known Exploited Vulnerabilities catalog and ordered federal civilian agencies to patch it by 19 July. The bug is a deserialization of untrusted data with a severity score of 9.8 out of 10, which lets an attacker with no credentials run arbitrary code on the server.
It does not stand alone. A cluster of SharePoint Server flaws is being chained in the wild to bypass authentication, gain remote code execution and carry out follow-on activity. Self-hosted SharePoint has a long history here: since late 2021, regulators have flagged nearly a dozen of its vulnerabilities as exploited in attacks, and most of those were later used in ransomware.
Why a patch alone will not save you
The dangerous part is what the attackers take on the way in. During exploitation they are stealing the server's cryptographic machine keys, the secrets SharePoint uses to sign and validate the tokens that grant access. Once an attacker holds those keys, they can forge valid credentials at will, and they can do it against a server you have already updated.
That is the trap in this incident. Applying Microsoft's patch closes the hole the intruder came through, but it does nothing about the keys they already copied. A patched, fully updated SharePoint Server can still be walked back into with stolen keys, which is why remediation here is not patch-and-done. If you do not rotate the machine keys, you may believe you are safe while the door quietly stays open.
Who is actually exposed
This is an on-premises problem, not a cloud one. The vulnerability affects self-hosted SharePoint Server, the version an organisation runs on its own infrastructure. Microsoft 365 SharePoint Online, the hosted service, is not the target of these particular exploits. So the risk concentrates precisely in the deployments that many European mid-market firms, public bodies, law firms and finance houses keep in-house.
Often they keep it in-house for good reasons: data residency, sector rules, or a decision to hold sensitive documents on infrastructure they control. That choice is legitimate, but it also means the patching, key rotation and monitoring are entirely your responsibility. The convenience a cloud provider would have handled silently is, on-premises, a task with your name on it and a clock running.
What this means under EU rules
The US deadline is not binding on you, but the urgency is. The 19 July date applies to American federal agencies; a European operator has no legal obligation to it. Treat it instead as a public signal of how fast this is moving, because the same servers and the same exploit code do not stop at a border. National authorities such as Germany's BSI and the UK's NCSC issue their own advisories on exactly this kind of actively exploited flaw.
Under NIS2 and, for financial entities, DORA, a successful intrusion here is a reportable incident with tight notification windows and board-level accountability. A document store full of contracts, personal data and internal records is exactly the asset these rules exist to protect. Being slow to patch a known, exploited vulnerability is the kind of failure a regulator reads as negligence rather than misfortune.
What to do now
Move in order, and assume the worst where you cannot prove otherwise. Apply Microsoft's SharePoint Server updates immediately, then rotate the IIS machine keys so stolen keys become useless. Hunt for signs of compromise: unexpected web shells, unfamiliar files under the server directories, new or altered keys, and authentication events that do not match your users. Reduce the attack surface by taking any internet-facing SharePoint off the open internet where you can.
If your server was reachable and unpatched at any point since disclosure, treat it as breached and investigate on that footing rather than hoping it was missed. The cost of assuming compromise you did not have is a few hours of review; the cost of assuming safety you did not have is the incident itself.
Read next: Eleven Signed Bootloaders Can Bypass Secure Boot | 570 Windows Patches in One Day, Two Already Exploited
