The Watch

Threat Briefing

CVE-2026-50522 is not a routine patch item. The flaw is unsafe deserialization on on-prem SharePoint, and it yields unauthenticated RCE. The operationally dangerous part comes after. A single request extracts the ASP.NET validationKey and decryptionKey, the keys that sign and encrypt ViewState and authentication tokens. Lift them once and an attacker forges trusted tokens against that server indefinitely. watchTowr has confirmed in-the-wild exploitation, and a public PoC is already circulating. Microsoft's July 2026 update closes the RCE. It does nothing about keys already gone.

7-Zip's XZ decompression heap overflow is the same lesson from a different angle. A malicious archive gets an attacker RCE. 7-Zip ships with no auto-update mechanism, which means the patch that exists never reaches endpoints unless someone pushes it. The fix is available. Delivery is the open question.

Attack Surface Analysis

Both defeat a patch-centric SLA. On SharePoint, remediation is not complete until every internet-exposed instance has rotated its keys and been swept for web shells and forged tokens. On 7-Zip, remediation does not begin until endpoint tooling forces the version, because user self-update will not happen.

Defense Playbook

1. Treat any internet-exposed SharePoint as presumed key-compromised: patch, rotate, restart, hunt, in that order.
2. Enumerate 7-Zip installs, including unmanaged and developer machines, and push the patched build centrally.

Patching SharePoint without rotating the machine keys changes the locks after the burglar has already been handed a spare.

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.