CVE-2026-50522 SharePoint RCE Steals Keys Beyond the Patch

Threat Briefing

The novel mechanic here is the abuse of a legitimate feature. Rather than hiding a payload in build files, SANDWORM_MODE installs a rogue Model Context Protocol (MCP) server inside Claude Desktop, Cursor, VSCode and Windsurf, then instructs the AI assistant itself to quietly harvest credentials. Nothing in the dependency looks malicious to a signature scanner, because the theft is performed by a trusted local agent doing what MCP servers are designed to do — call tools and read context.

Propagation is where it earns its name. The worm uses stolen npm publish tokens, GitHub API tokens and SSH keys to push infected dependencies into downstream repos automatically, so a single compromised developer endpoint seeds the next wave through your CI/CD. Socket.dev found it spread across 19 malicious packages; CrowdStrike shipped 65% of the campaign's detections — meaning roughly a third of coverage depends on whatever else is in your stack.

Attack Surface Analysis

This makes MCP servers a first-class asset your inventory almost certainly doesn't track. The trust boundary isn't the package registry anymore — it's the AI agent's tool-call surface on every developer laptop and CI runner. Two failure modes compound: credential sprawl (dev accounts holding long-lived publish tokens) and unmonitored agent configs (no one audits which MCP servers are registered). Traditional SCA validates package contents; it does not validate agent behavior.

The dependency wasn't backdoored — the AI assistant reading it was told to steal, and your scanners only inspect the dependency.

Your Defense Playbook

1. Bring MCP server registrations into the asset inventory and treat unreviewed ones as untrusted code execution.
2. Shorten the life and scope of dev credentials — the worm's whole propagation model depends on long-lived publish tokens.

The smart move is to fold dev-fleet AI tooling under the same identity discipline you already apply to production service accounts: least privilege, rotation, and behavioral logging.

Threat Briefing

RFC 9207 added an issuer check built to stop redirect-flow OAuth mix-up attacks. CVE-2026-59208 documents where that check runs out: the protection was never extended to back-channel token exchange grants under RFC 8693, 7523, and 7522. The mechanism is specific. A token issued by one tenant can resolve to a same-named account in a different tenant, because the subject lookup is not scoped per issuer and keys are not partitioned by issuer.

This ranks above the individual n8n bug for a structural reason. Token exchange is how identity gets resolved in agent orchestration, MCP-style multi-issuer setups, and multi-tenant SaaS, which are also the systems being stood up on the shortest timelines. Any deployment in that set that trusts a subject claim without binding it to the issuing tenant inherits the same cross-tenant confusion.

Attack Surface Analysis

The day's other story rhymes with this one. ServiceNow publicly denies that its AI Platform unauthenticated sandbox-escape RCE is being exploited; threat-intel firm Defused reports otherwise, and which account holds has not been settled. The connecting logic is the same in both cases: a vendor's assurance, or an RFC's assumed coverage, is not a control. Where token exchange resolves identity, the working assumption should be that issuer scoping is absent until someone has verified it in the actual deployment.

Front-channel issuer checks do not cover back-channel token exchange.