SharePoint CVE-2026-58644 is now used by ransomware gangs — what it means for your on-prem estate

13 August 2026 7 min read 1386 words

On 11 August 2026, CISA confirmed that CVE-2026-58644 (CVSS 9.8, unauthenticated remote code execution via deserialisation in on-prem Microsoft SharePoint Server) is now actively used in ransomware attacks — not only for initial access.

Scale is large: more than 148 organisations affected globally (as of 11.08.2026, cumulative). Attackers do not only enter — they steal IIS machine keys (ValidationKey / DecryptionKey), which lets them forge authentication tokens and keep access even after the patch is applied. It turns a one-shot RCE into a persistent backdoor and a chain: first ToolShell (July 2026, surveillance), now ransomware escalation in the same vector. The campaign chains CVE-2026-50522 / 32201 / 56164 / 58644 listed by CISA.

For B2B firms and manufacturing running on-prem SharePoint: priority is (1) patch CVE-2026-58644 immediately, (2) rotate IIS machineKey after patching (patch alone is not enough), (3) detect post-exploitation (anomalous w3wp.exe processes, suspicious .aspx files, elevated ADFS operations).

Key facts

CVE-2026-58644 is an unauthenticated RCE in Microsoft SharePoint Server (on-prem: SE/2019/2016), exploited before Microsoft published the patch; CISA added it to KEV on 16.07.2026 with a 3-day remediation deadline (mandatory for US federal agencies, used as a supply-chain benchmark).
Scale: 148+ organisations affected globally (Shadowserver / Eye Security telemetry reported by BleepingComputer 11.08.2026).
Entry: combination of several CVEs in chain — CVE-2026-32201 / 45659 / 56164 / 50522 / 58644 — enabling RCE plus post-exploitation (IIS machine-key theft, deserialisation).
Post-exploitation: attackers steal ValidationKey + DecryptionKey from IIS, forge ViewState tokens, install webshells (spinstall0.aspx and similar) and dual-use tooling (modified whoami/cmd in SharePoint directories).
Ransomware escalation: from ToolShell (July 2026, surveillance) to ransomware (August 2026 — encryption + double extortion). Linked to CISA AA26-222A (Gunra ransomware) as a follow-up in the same vector.
Data: SharePoint in B2B/manufacturing stores project documentation, HR data, customer data, and Power Platform integrations (Power Automate, SharePoint lists as LOB backend) — compromise equals IP leak and lateral movement to connected systems (mimikatz on SQL / ADFS).
Persistence (post-patch): stolen IIS keys remain valid even after the patch is installed, unless the administrator rotates machine keys.
Sector: cross-sector, hardest hit: public institutions, government, B2B enterprise, manufacturing (where on-prem SharePoint is kept alongside cloud M365 for regulatory or sensitive-data reasons).

Decision table

Area	What we know	What it means for B2B / manufacturing	Recommended action 30 days	Recommended action 90 days
Exploited vulnerability	Unauthenticated RCE, CVSS 9.8, KEV 16.07.2026	Any internet-facing on-prem SharePoint is potentially exposed	Inventory all on-prem SharePoint farms, validate build version vs. Microsoft advisory	Implement a standing CISA KEV SLA (3 days as US-federal benchmark)
Post-exploitation (IIS machine keys)	Attackers steal `ValidationKey`/`DecryptionKey` and forge ViewState tokens	The patch alone is not enough — attackers can keep access for months after patching	Rotate IIS `machineKey` on all farms, restart the service, validate new config	Monitor `machineKey` config changes (SCW/SSC), alert in SIEM
Webshells and dual-use tooling	Delivered as `.aspx` in SharePoint directories (`_layouts/15/`, `ISAPI/`)	Signals active post-exploitation — do not scan only for vulnerabilities, check for compromise indicators	File Integrity Monitoring (FIM) on SharePoint directories + IoC scanning (YARA / CISA/Microsoft signatures)	Deploy EDR on SharePoint hosts + telemetry integration into SIEM
Ransomware (escalation)	From surveillance (ToolShell) to encryption (August 2026)	Incident does not end with data theft — next step is encryption + DLS	Test offline, immutable backups (repeat restore drill), verify 3-2-1	VLAN segmentation + isolation backup, run ransomware tabletop quarterly
NIS2/KSC lens	Incident affects confidentiality + integrity; 24h/72h reporting	For essential/important entities: CSIRT NASK early warning obligation	Verify reporting channel to CSIRT/NASK, define critical incident template	Run ransomware scenario with board + external IR retainer
Supply chain lens	SharePoint often hooked into ERP / CRM / Power Platform	SharePoint breach = side door into M365 (Power Automate, Azure AD)	Audit application permissions (service principals), disable unnecessary integrations	Migrate integrations to workload identity with MFA, disable legacy auth

Perspective — Marcin Białczyk

— I do not have a public client case study on this topic yet; I will gladly describe a concrete deployment after the client consents. That said, below is the operational framework I use when assessing SharePoint on-prem exposure.

What is actually important here, and what gets lost in headlines. Most articles on CVE-2026-58644 focus on patching. That is necessary but not sufficient. The mechanism that distinguishes this incident is IIS machine-key theft (ValidationKey + DecryptionKey). The vector is similar to older ASP.NET WebForms / ViewState attacks, but in 2026 it returned in updated form, specifically in SharePoint. Until the administrator rotates those keys, post-patch access remains viable. That means companies that patched on 17.07.2026 and did nothing else remain exposed — even though their dashboard reads green. This is exactly the silence in which ransomware matures.

Why cross-sector and why manufacturing. On-prem SharePoint is usually kept in environments where regulation (sensitive data processing, medical data, automotive Tier-1) requires in-house DC or private cloud hosting. This creates a population of internet-connected systems with long patch-management cycles (regression testing, farm-scale, SAP/ERP integrations). In that population the vulnerability stays exploitable for weeks — which is what we see in the Shadowserver data. For anyone auditing such environments, the question worth asking is: when did we last rotate machineKey, and where do we have .aspx files in TEMPLATE\LAYOUTS\15\?

What I would do in the first 30 days if I managed 5+ farms.

Inventory and prioritisation: full list of on-prem SharePoint farms with internet-facing footprint (ports 443, NTLM/Kerberos, ADFS). Classification by sensitive data (PHI, PII, IP, financial).
Patching + key rotation (sequentially or in a planned maintenance window) + service restart.
IoC scanning: check for webshells in known locations (_layouts/15/spinstall0.aspx, TEMPLATE\LAYOUTS\*.aspx from the last 30 days), anomalies in w3wp.exe, process dumps in c:\windows\temp.
Post-patch access: audit the last 180 days of IIS/SharePoint logins for unusual sources (countries, ISP, ASN).
Backups: verify offline + immutable backup procedure + test restore from a selected farm.

In 90 days — a continuity programme: regular key rotation, FIM, EDR on SharePoint hosts, SIEM integration, ransomware tabletop drill. This is the scope in which CHORS NIS2/KSC Continuous Readiness has practical application for such clients — not as "certification", but as building operational continuity with real drills and evidence.

Frequently asked questions

Does CVE-2026-58644 affect SharePoint Online (Microsoft 365)?

No. The vulnerability only affects on-prem SharePoint Server (Subscription Edition, 2019, 2016). Microsoft 365 SharePoint Online managed by Microsoft is not affected — but integrations that read from on-prem SharePoint (hybrid configurations, Power Automate, on-prem data gateways) are.

Does the Microsoft patch from 14.07.2026 fully eliminate the risk?

No, if your farm was exploited. The patch closes the vulnerability, but stolen IIS machine keys remain valid. Rotation of machineKey and IoC scanning for post-exploitation are required.

Do I need EDR on SharePoint servers?

From this incident's perspective — yes. Dual-use tools (mimikatz, modified cmd/whoami), .aspx webshells and anomalies in w3wp.exe are easier to detect via EDR than via IIS log auditing. EDR on SharePoint front-ends is a programme element in our CHORS NIS2/KSC Continuous Readiness.

Is this incident within NIS2/KSC scope?

Yes — confidentiality, integrity, and after ransomware escalation also availability. Essential/important entities with on-prem SharePoint should consider early warning to CSIRT NASK within 24h of detection, in line with NIS2 Art. 23. Exact incident-class classification requires evaluation in your own organisation — legal interpretation should be confirmed by a law firm working with CHORS.

How CHORS.NET helps

CHORS.NET supports the technical-operational side: passive exposure assessment, configuration verification, evidence packs and NIS2/KSC readiness support. See: Services, About CHORS.NET and Contact.

Boundaries and assumptions

We are not a 24/7 SOC and we do not guarantee detection of every incident. This article describes the mechanism and observations from publicly available sources; it is not a guarantee for any specific environment.
We do not certify NIS2/KSC compliance — CHORS NIS2/KSC Readiness is a review and continuity-building service (BCP/DR, governance, exercises), not a certification audit. We do not issue a standalone legal opinion.
Results reflect the state at the time of this article (2026-08-11). CISA, Microsoft, and third parties publish updates; we recommend tracking KEV and Microsoft bulletins.
For legal interpretation (including incident classification, reporting, 24h/72h thresholds) CHORS works with law firms.
The material is informational and technical; it is not legal advice.

Precyzyjna wiedza
o ciemnych systemach.