Fourth Actively Exploited SharePoint Vulnerability CVE-2026-50522 (CVSS 9.8) Under Attack After PoC Release

SharePoint's fourth actively-exploited flaw in a month arrives with a persistence twist — applying the patch closes the door, but only rotating the IIS machine keys locks it.

SINGAPORE — Attack surface intelligence firm watchTowr reported on July 21–22, 2026 that CVE-2026-50522 — a critical remote code execution flaw in Microsoft SharePoint Server, rated CVSS 9.8 — is under active exploitation, with the first attempts reportedly landing within hours of public proof-of-concept (PoC) exploit code appearing. The vulnerability stems from deserialization of untrusted data (CWE-502) in Microsoft Office SharePoint, and Microsoft credited DEVCORE with reporting it.

What makes this one land harder for defenders is the follow-through: rather than treating a compromised server as a smash-and-grab, attackers reportedly steal the server's IIS machine keys, which can be used to forge trusted authentication and hold access even after the patch is installed. It is, by SecurityWeek's count, the fourth SharePoint Server flaw to come under active exploitation in roughly a month. This piece restates what the reporting documents in defender terms — patch verification and machine-key rotation — without reconstructing how the flaw is triggered.

What WatchTowr and Multi-Source Reporting Documented

According to watchTowr and reporting from The Hacker News, CVE-2026-50522 is a deserialization-of-untrusted-data vulnerability in Microsoft SharePoint Server that carries a CVSS score of 9.8 and can allow an unauthorized attacker to execute code over a network. Microsoft credited DEVCORE with reporting the flaw. watchTowr's honeypot sensors reportedly registered successful exploitation on July 20, 2026 — within hours of public proof-of-concept code being released — and the firm continues to observe attempts against internet-facing, on-premises SharePoint deployments.

The defender-relevant facts are the ones that shape this week's work, and they are worth isolating from the mechanics. The class of the flaw is deserialization of untrusted data; the severity is critical; the exposure is on-premises SharePoint Server rather than the cloud-hosted service; and the exploitation window opened almost immediately after a PoC became public. The CyberSignal is deliberately not reproducing how the flaw is reached — what a defender needs is not the exploit path but the confirmation that the patch is applied and that the credentials an intruder could carry away have been rotated.

One counting note is worth flagging so the framing travels accurately. SecurityWeek describes CVE-2026-50522 as the fourth SharePoint Server flaw exploited in the past month's wave; The Hacker News, using a narrower recent window, frames it as the third after CVE-2026-56164 and CVE-2026-58644. Both descriptions point at the same underlying reality — a sustained run of exploitation against on-premises SharePoint — and the exact ordinal depends on where each outlet starts counting.

Continuation Context: A Fourth SharePoint Flaw in a Month

This does not arrive in isolation. It is the latest entry in a month-long sequence The CyberSignal has tracked closely, beginning with the JWT authentication-bypass flaw CVE-2026-55040 and continuing through CISA's confirmation that three SharePoint vulnerabilities — two of them zero-days — were being actively exploited. Most recently the agency set a federal remediation clock with the CVE-2026-58644 KEV addition and its July 19 deadline.

The cadence is the point. On-premises SharePoint has become a repeat target because it sits at the intersection of high value — documents, identities, internal sites — and slow patch cycles, and because each new flaw arrives into an ecosystem where defenders are already behind on the last one. Rapid7's detection-focused deep dive on CVE-2026-58644 captured how quickly attention shifts from patching to hunting once a SharePoint bug is weaponized; CVE-2026-50522 extends that pattern, with the added wrinkle that the payoff this time is the machine key rather than a single session.

The IIS Machine-Key-Theft Angle and Required Post-Patch Rotation

The machine-key detail is what separates this from a routine critical-patch story, so it is worth translating plainly. A SharePoint farm's IIS machine keys are the secret validation and decryption keys ASP.NET uses to sign and protect trusted data. If an intruder obtains them, they hold a credential that outlives the vulnerability itself — the keys can reportedly be used to forge authentication material and re-enter the environment even after the underlying flaw is patched. In other words, the patch closes the entry point, but it does not invalidate a key that has already walked out the door.

That is why every advisory summarized here pairs patching with rotation, and why the two steps are not interchangeable. Applying Microsoft's update without rotating the machine keys leaves a patched-but-still-accessible server; rotating keys without patching leaves the door that let the keys out in the first place. Defenders who lived through earlier machine-key-abuse incidents will recognize the shape of it — the credential, not the exploit, is the persistence mechanism, and remediation is incomplete until the credential is replaced.

Defender Posture: Patch Verification and Machine-Key Rotation

The action list this week is short and sequential. First, verify — not assume — that Microsoft's current SharePoint Server updates are installed on every server in the farm, including secondary and web-front-end roles that are easy to miss; a single unpatched node keeps the farm exposed. Second, rotate the IIS machine keys using Microsoft's supported SharePoint tooling and restart the associated services so the new keys take effect across the farm. Third, treat any server that was internet-facing and unpatched during the exposure window as potentially key-compromised, and prioritize its rotation regardless of whether other evidence is present.

From there the work turns to assurance. Confirm the rotation actually propagated, review authentication and administrative activity for the period the server was exposed, and fold the sequence into change records so the next SharePoint disclosure — on current cadence, unlikely to be far off — meets a team that already knows the drill. The guardrail throughout is that this is a defender-posture exercise: patch verification and key rotation, not incident reconstruction.

What CISA-KEV Addition to Watch For

One near-term signal to monitor is whether CISA adds CVE-2026-50522 to its Known Exploited Vulnerabilities (KEV) catalog. At publication that is not confirmed, and The CyberSignal is not asserting it. Given documented active exploitation of a critical flaw, a KEV listing would be unsurprising — and it would matter operationally, because it converts “patch soon” into a binding federal remediation deadline under BOD 22-01, exactly as the CVE-2026-58644 KEV addition did with its July 19 cutoff.

For non-federal defenders a KEV entry is still a useful forcing function: it is the clearest public signal that a flaw is being used in the wild and belongs at the top of the queue. If the listing appears, expect the machine-key-rotation guidance to travel with it, since remediation that stops at the patch would leave the persistence angle unaddressed.

Open Questions

Several specifics remain unresolved at publication, and The CyberSignal is not filling them in. It is not confirmed which threat actors are behind the exploitation, how many on-premises SharePoint deployments have been affected, whether CISA has added CVE-2026-50522 to the KEV catalog, or how many exposed organizations have completed machine-key rotation. Where the reporting attributes a detail — the hours-after-PoC timing, the machine-key theft, the fourth-in-a-month framing — this article carries that attribution rather than restating it as settled fact.

The picture will sharpen as watchTowr, Microsoft, and independent responders publish more. Until then the defensible read is narrow and actionable: a critical SharePoint flaw is being exploited now, the exploitation reportedly harvests a credential that survives patching, and the remediation that matches the threat is patch verification followed immediately by machine-key rotation.

The CyberSignal Analysis

The reported facts above come from watchTowr's disclosure and its reporting; what follows is The CyberSignal's editorial reading. None of the judgments below are new reported facts.

Signal 01 — Patching Is Not the Finish Line When Keys Walk

The reflex with a critical CVE is to equate “patched” with “closed,” and this disclosure reportedly breaks that equation on purpose. Our reading is that the machine-key theft is the load-bearing detail: it turns a code-execution flaw into a persistence problem, because the credential an intruder carries away keeps working after the entry point is sealed. A team that patches and moves on has done half the job.

The consequence is a sequencing discipline that outlasts this specific CVE. Any SharePoint incident where machine-key exposure is plausible should trigger rotation by default, not as an optional extra. Organizations that build that reflex now will remediate the next machine-key-abuse story in one motion rather than discovering the gap after the fact.

Signal 02 — The Cadence Is the Real Headline

Whether this is the third or the fourth exploited SharePoint flaw in a month is a counting argument; the durable signal is that the question is even close. Our assessment is that on-premises SharePoint has entered a sustained-pressure phase, where each disclosure lands on defenders who are still catching up on the last, and where PoC-to-exploitation windows have compressed to hours.

That argues for a standing SharePoint response posture rather than a per-CVE scramble — a known inventory of internet-facing farms, a rehearsed patch-and-rotate runbook, and monitoring tuned for the aftermath. The organizations that treat SharePoint as a recurring beat, not a one-off emergency, will spend the next disclosure executing instead of improvising.

Signal 03 — Speed of Weaponization Is the Planning Assumption

Exploitation reportedly following a public PoC by hours is the operational fact worth internalizing. Our view is that the old mental model — a comfortable gap between disclosure and real-world attacks — no longer holds for high-value, internet-facing software, and planning that assumes days of runway is planning to be late.

The practical takeaway is to treat patch verification for exposed SharePoint as an emergency-change candidate the moment a PoC surfaces, and to pre-stage the rotation step so it is not being figured out under pressure. Speed of defense now has to match speed of weaponization, and that is a preparation problem to solve before the next PoC, not during it.

Sources