A SharePoint Flaw Turns One Request Into a Key That Outlives the Patch

CVE-2026–50522 is a deserialization flaw that ends in code execution on an on-premises SharePoint server. That part a patch fixes. What it does not fix is the thing attackers actually take once they are in: the server's machine keys — the cryptographic secret that lets them forge their own way back in, on a fully patched box, indefinitely.

An on-premises SharePoint server is a document store, an intranet, and — because it is wired into the organization's identity plumbing — a set of keys to a great deal more. For the past week, a critical flaw in it has been used not to smash a window once, but to walk out with the master key.

On July 14, 2026, Microsoft patched CVE-2026–50522 in its monthly updates. It was not flagged as under attack. By July 20, a public proof-of-concept existed and watchTowr's honeypot network was recording successful compromises within hours; by July 22 the exploitation was public knowledge. It is the fourth SharePoint flaw drawn into an active attack wave in a single month.

Read the vulnerability on its own and it is a familiar shape: unauthenticated deserialization, remote code execution, CVSS 9.8, patch available. Alarming, but tractable — apply the update and move on. That reading is exactly the trap, because the code execution is not the objective. It is the delivery van.

The RCE is how they get in once. The machine key is how they get in forever.

The facts

• CVE-2026–50522 — deserialization of untrusted data (CWE-502) in Microsoft SharePoint Server. CVSS 9.8. Microsoft's advisory describes a Site Owner privilege requirement, but the CVSS vector is unauthenticated, and the exploitation observed in the wild — a single request carrying no authentication material — is unauthenticated in practice. Treat it as pre-auth; that is how it is being used.
• The mechanic — a malicious .NET BinaryFormatter payload is delivered inside a forged SecurityContextToken, wrapped in a WS-Federation sign-in response and POSTed to the SharePoint sign-in endpoint /_trust/default.aspx. If the vulnerable deserialization path processes it, the payload runs as code on the server.
• The payload after the payload — once code runs, attackers pull the server's IIS machine keys. watchTowr's summary is blunt: "Attackers are pulling SharePoint machine keys via a single request."
• Affected — all supported on-premises SharePoint Server: Subscription Edition, 2019, and 2016. SharePoint Online (Microsoft 365) is not in scope.
• Fixed — Microsoft's July 14, 2026 security updates. No supported configuration change substitutes for the patch, and — the point of this issue — the patch alone does not close the exposure.
• Credit — DEVCORE researcher "splitline" reported the flaw; it was demonstrated earlier at Pwn2Own Berlin. A public PoC was published by researcher "Janggggg" on July 20. Exploitation was observed by Defused and watchTowr.

How the attack actually works

SharePoint accepts a federated sign-in at /_trust/default.aspx — the endpoint that processes a token asserting "here is who I am, signed by a party you trust." Handling that token means deserializing it: turning bytes on the wire back into live objects in memory.

Deserialization of attacker-controlled data is one of the oldest sharp edges in .NET, because BinaryFormatter can be steered into constructing objects whose very creation runs code. CVE-2026–50522 is that edge, reachable at the sign-in endpoint. The public PoC forges a SecurityContextToken, hides a BinaryFormatter gadget chain inside it, and posts it in. The server unpacks the token, the gadget fires, and the attacker is executing code — having presented no valid credential at all.

That alone would be a serious unauthenticated RCE. But the operators using it are not stopping at a shell. In the same motion, they read out the server's machine keys — the validationKey and decryptionKey that ASP.NET uses to sign and encrypt the tokens and ViewState the application trusts.

One request in. One secret out. The lock's own combination.

The key outlives the patch

Here is the part a "critical RCE, patch now" headline throws away.

The patch closes the code path. It does not revoke the secret.

A machine key is not a foothold. It is a cryptographic secret the server uses to decide what is authentic. Anyone holding it can mint tokens and ViewState payloads the server will accept as its own — forge a valid identity, impersonate any user, and reach code execution again. None of that touches the vulnerable deserialization path a second time. It does not need to. The forged token is legitimate by construction, because it is signed with the server's real key.

So walk the timeline of a naive remediation. The server is compromised on Monday. The machine keys are exfiltrated on Monday. The patch is applied on Wednesday. On Thursday the attacker returns — not through CVE-2026–50522, which is now closed, but through a token they signed with the key they took on Monday. The server waves them through, because as far as it can tell, it signed that token itself.

Patching closes the code path. It does not revoke the secret. That is why every serious writeup on this flaw carries the same second sentence after "patch": rotate your machine keys. watchTowr put the operational bottom line plainly — patching is not enough; rotate credentials on anything that may have been exposed. The urgency of this CVE is not only that the door is open. It is that every hour the door is open, a permanent key is being copied, and the patch you are racing to apply will never change the lock.

This is not a novel failure mode. It is the exact playbook from the 2025 "ToolShell" SharePoint wave, where the same machine-key theft turned single intrusions into durable ones. The lesson did not stick because the lesson is uncomfortable: for this class of bug, remediation is not an event, it is a sequence, and the patch is only step one.

Hours after the PoC

The dates are worth laying side by side, because they show how little time the "just patch" window actually bought.

Microsoft shipped the fix on July 14 and did not list the flaw as exploited. On July 17, the threat-intelligence firm Defused recorded activity it now attributes to this CVE — meaning exploitation likely began after the patch but before any public exploit, against servers that had not yet updated. On July 20, a working PoC went public; within hours, watchTowr's global honeypots logged successful compromises using it. By July 22 it was widely reported.

The exposure was never a missing patch. It was the gap between a patch existing and a patch installed.

A patched-but-unupdated server is the whole target population here. The fix existed for six days before the PoC made exploitation trivial, and the servers breached in that window are, by definition, the ones that had not applied a fix that was already available. The exposure was never a missing patch. It was the gap between a patch existing and a patch being installed — and attackers live in that gap.

The signal was soft

There is a smaller lesson sitting next to the big one, and it is about how the risk was labelled.

At release, Microsoft's assessment was "Exploitation More Likely" — its forward-looking flag — not "Exploitation Detected." Reasonable on its face. Less reasonable in context: the flaw had been demonstrated at Pwn2Own Berlin, where a working exploit was handed to the vendor directly. ZDI's Dustin Childs flagged the oddity at Patch Tuesday — a bug with a known working exploit, carrying a maturity signal that read softer than the facts. Within a week, the field caught up with reality and the flaw was under active attack.

The takeaway is not that Microsoft mis-scored anything. It is that a vendor's exploited-yet-or-not flag is a lagging indicator by design — it records what has been confirmed, not what is coming. A 9.8 unauthenticated RCE on an internet-facing box with a public Pwn2Own demo does not become urgent when the flag flips. It was urgent at publication. Waiting for "Exploitation Detected" is waiting for the incident to name itself.

The fourth in a month

CVE-2026–50522 does not arrive alone. It is the fourth SharePoint flaw pulled into active exploitation in roughly a month. CISA has warned of attackers chaining multiple on-premises SharePoint vulnerabilities, and ordered federal agencies to patch three of them the week before this one surfaced. The post-exploitation pattern across the wave is consistent: reach code execution, deserialize, steal machine keys, persist, deploy malware.

The reason on-premises SharePoint keeps drawing this attention is structural, and stating it is not piling on. These servers are typically internet-facing, they hold the documents an organization considers sensitive, and they are integrated with the identity systems around them. A machine key lifted from SharePoint is rarely a key to SharePoint alone. That is a real pattern about this product's exposure — it is not evidence about the intent behind any single one of these four CVEs, and it should not be read as though it were.

What's established, and what isn't

Established. The flaw is real and patched. In-the-wild exploitation is confirmed by multiple independent firms — Defused, watchTowr — and a public PoC exists. Machine-key theft as the post-exploitation goal is confirmed and consistent across reports. The affected versions are the supported on-premises editions.

Not established. There is no public attribution and no reliable victim count; "active exploitation" is a confirmed fact, not a number. The advisory's Site-Owner privilege wording sits in tension with the unauthenticated single-request exploitation being observed — worth flagging rather than resolving from the outside. And the CVE's status in CISA's KEV catalog is a moving target: the earlier SharePoint trio drew a federal deadline, and whether this one has been added by the time you read this is worth checking, not assuming.

Patching is not the whole job

This is the sentence the auto-generated advisories skip, and it is the entire point of this flaw: apply the update and then assume the update did not save you.

A server compromised before it was patched is a patched, still-owned server if its keys walked out the door. So on any on-premises SharePoint that ran an unpatched build across this window:

• Hunt before you rotate. Look for the intrusion first — suspicious POSTs to /_trust/default.aspx, unexpected child processes off the SharePoint worker, anomalous PowerShell, outbound connections from the server, modified web.config files, new administrators or altered permissions.
• Then rotate the machine keys. Rotating before you have evicted the intruder just hands them the new key too. Rotate after cleanup, across the farm.
• Review authentication. Forged tokens are the whole prize here — look for sign-ins and token activity that do not match any real user.
• Enable AMSI for SharePoint if it is not already on, so deserialization payloads have a chance of being caught at execution.

Treat a confirmed hit the way you would treat a stolen signing key, because that is precisely what it is.

The response

Inventory first. Every on-premises SharePoint farm — production, staging, disaster recovery, and the legacy 2016 box someone stood up in 2018 and stopped thinking about. The internet-facing server nobody owns is the one being keyed.

Patch and verify. Apply Microsoft's July updates across all farms and confirm the running build, not the installer's intent.

Rotate keys after hunting, per above. Patching without rotation leaves the persistent path wide open; rotation without hunting arms the intruder with the replacement.

Prioritize by exposure. The exploitation is unauthenticated and internet-facing servers are reachable directly, so those are not merely first — they are the ones an outside attacker can key without any other foothold.

Scope

This is not a SharePoint Online problem. Microsoft 365 tenants are not affected, and saying so matters — most SharePoint usage today is cloud, and the cloud population can read this and move on.

But the on-premises footprint that remains is precisely the high-value, hard-to-move kind: regulated organizations, government, large enterprises with data or integrations they will not migrate. And the asset being stolen scopes wider than the box it comes from. A machine key is a skeleton key to whatever trusts tokens that key signs — which, for a server wired into an organization's identity fabric, is rarely just one application. A smaller installed base holding forged-identity material for the network behind it is not a smaller problem than a larger one holding less. For the organizations concerned, it is a worse one.

The lesson here is not that a CVSS 9.8 deserves urgency. That takes care of itself; nobody argues with unauthenticated code execution on an internet-facing server.

The lesson is what "remediated" means. You can patch this flaw perfectly, verify the build, and close the ticket — and still be owned, because the attacker's objective was never the door you just fixed. It was the key hanging behind it, and they photographed it on the way through.

Patch the server. Then rotate the key — because the version you fixed is not the thing they took.