SharePoint attackers stealing keys — rotate credentials now

Confirmed reporting by watchTowr and Defused via BleepingComputer, 2026-07-21. Attackers exploiting CVE-2026-50522 in Microsoft SharePoint Server are stealing machine keys during the intrusion. Those keys let them forge valid authentication tokens later. Applying the July patch does not evict them. If you were exposed, you have to rotate.

The one sentence to take away

Patching CVE-2026-50522 stops the initial deserialization RCE. It does nothing about a key an attacker already walked out with — and that key keeps working until you change it.

The honest timeline

• 2026-07-14. Microsoft ships the July Patch Tuesday updates, including CVE-2026-50522. Per BleepingComputer, Microsoft’s advisory flagged “increased likelihood of being leveraged” but did not initially mark the flaw as actively exploited.
• 2026-07-17. Early-warning firm Defused reports detecting an undocumented SharePoint deserialization vector under active use. Confidence: high, per Defused’s own labeling in the BleepingComputer piece.
• 2026-07-20. watchTowr identifies public proof-of-concept code. Their honeypot networks capture successful compromises within hours.
• 2026-07-21 morning. watchTowr’s active-exploitation determination goes public. Coverage: SharePoint CVE-2026-50522 exploited after public PoC.
• 2026-07-21 afternoon. BleepingComputer publishes the machine-keys angle — attackers are staging for long-term access, not smash-and-grab.

Seven days from patch to observed exploitation. Twenty-four hours from active-exploitation determination to confirmed persistence tradecraft. That is the compressed window every incident response conversation this week has been about.

Why patch-alone is the wrong ending

BleepingComputer, citing watchTowr, describes the persistence path in class terms: attackers are exfiltrating the SharePoint server’s machine keys, then using them to mint valid authentication tokens that impersonate users and unlock SharePoint resources on demand. The delivery method — a malicious .NET BinaryFormatter payload arriving as a cookie via a forged WS-Federation sign-in response to SharePoint’s /_trust/default.aspx endpoint — is reported as-observed by watchTowr; readers who need the mechanics should go to their write-up and Microsoft’s MSRC entry directly. Nothing here reproduces the payload.

The important part for defenders: those tokens are cryptographically valid. Your patched server has no way to tell them from real ones until the key that signed them is gone.

What to actually do, in priority order

If your SharePoint Server was internet-reachable at any point between July 14 and now — and especially if it was reachable before July 17 — treat it as compromise-adjacent. That is not paranoia. It is what watchTowr is telling defenders in plain language: rotate credentials on any asset that may have been exposed.

Concrete order of operations:

1. Confirm you are on the July 2026 SharePoint security update. If you are not, that is the first job. MSRC’s CVE-2026-50522 entry is authoritative.
2. Rotate the SharePoint machine keys and farm passphrases. Microsoft’s own runbook for post-compromise SharePoint recovery is the reference — do not roll new keys by editing web.config by hand on a production farm without following it. Coordinate rotation with an IIS restart across all servers in the farm so the old keys stop validating tokens everywhere at once, not just on the server you touched.
3. Invalidate active sessions. New keys make forged tokens fail, but real sessions signed under the old key also fail — plan for the sign-in disruption instead of getting surprised by it.
4. Rotate any service-account or app-only credentials the SharePoint server held. Anything with access to the server’s process memory is in the blast radius. That includes SQL connection strings, any secrets in the Secure Store Service, and any OAuth client secrets your farm brokered.
5. Hunt for what the keys already got used for. Anomalous WS-Federation sign-ins, unexpected token audiences, and post-July-17 authentication events that do not match your normal user patterns are the tells. If you have SIEM coverage of your ADFS / identity provider, that is where the signal lives.

The priority call

If you have one hour tonight, it goes into step 1 and step 2 — patch, then rotate — on any SharePoint Server that was public-facing since Patch Tuesday. Everything else in the list is next-morning work.

Do not stop at “we patched.” That is exactly the ending the attackers are counting on.