Initial undocumented attack activity detected: July 17, 2026 — three days before public proof-of-concept code (Source: BleepingComputer (July 21, 2026), citing security firm Defused)
A Patch That Doesn't Close the Door
On July 21, 2026, BleepingComputer reported active exploitation of CVE-2026-50522, an unauthenticated deserialization vulnerability in on-premise Microsoft SharePoint Server that lets attackers achieve remote code execution. What makes this disclosure notable for budget-signers isn't the RCE itself — it's what attackers do once inside: they extract the server's machine keys, the cryptographic material SharePoint uses to sign and validate authentication tokens. With a copied machine key, an attacker can forge a valid login for any user, on that server, indefinitely. Applying Microsoft's patch closes the entry point. It does not invalidate a key that was already copied.
Why a Patch Alone Doesn't End the Incident
This is an architecture problem, not just a software bug. SharePoint, like other ASP.NET-based enterprise platforms, trusts machine keys as a standing credential rather than issuing short-lived, per-session proof. That design choice is efficient — it's also why remediation here requires two separate actions that are often treated as one: patching the deserialization flaw, and rotating every machine key on every server that was exposed before the patch landed. Skip the second step and a fully patched, fully up-to-date SharePoint server can still authenticate an attacker who never touches the vulnerability again.
Where This Intersects the Machine Web
SharePoint document libraries are increasingly a retrieval source for AI agents and copilots operating inside enterprises — systems that query content and act on a user's behalf using the same identity layer machine keys underpin. A forged token doesn't just open a human session; it opens whatever an agent acting under that identity is permitted to read, summarize, or forward. As more workflows delegate document access to automated agents rather than a person clicking through a login page, the cost of a silently persistent forged credential rises with the number of systems willing to trust it without a second look. This is the same structural pattern WebPulse has tracked across other categories of enterprise web software: the vulnerability gets a patch date, but the trust chain underneath it does not reset on its own.
Outside WebPulse's Tracked Sample — By Design
WebPulse's 466K+ site sample tracks around 30 frameworks detectable via public HTML and HTTP signatures — the open web that AI crawlers and agents encounter directly. SharePoint's on-premise deployments sit behind enterprise authentication and largely outside that public surface, so this incident isn't reflected in WebPulse's detection data, and it shouldn't be forced to be. The reason it belongs in the same conversation is architectural, not statistical: any platform that authenticates users through long-lived server-side secrets rather than short-lived, rotation-friendly tokens carries this exact persistence risk after a disclosed flaw, whether it's a framework WebPulse scans directly or an enterprise system behind a login wall. For organizations running affected SharePoint versions, the operational takeaway from Microsoft's and researchers' guidance is straightforward: patching resolves the entry point; key rotation resolves the exposure. Treating the two as one step is the gap attackers are currently using.
