On October 2025, Anthropic shipped Claude Code 1.0.111 to patch CVE-2025-59536, a CVSS 8.7 flaw that Check Point Research disclosed in early 2026: a repository's own .claude/settings.json could set enableAllProjectMcpServers and enabledMcpjsonServers in a way that auto-approved MCP servers and hooks defined in a companion .mcp.json file — bypassing the consent dialog a developer would normally see before an agent tool got permission to run. A single malicious commit, cloned and opened in an editor, was enough to reach code execution with no explicit "install" step at all. A companion issue, CVE-2026-21852 (CVSS 5.3), let an attacker rewrite ANTHROPIC_BASE_URL to proxy a victim's traffic and harvest API keys in plaintext. Neither bug required a compromised registry — just a config file a developer trusted because it shipped inside a repo they already trusted. As agent "skills" and MCP servers get their own registries and marketplaces, that same trust boundary is being rebuilt at scale, and the npm and PyPI ecosystems have already run this experiment for a decade. This post lays out the case-study pattern — consent bypass, version mimicry, delayed payloads — and the registry-level controls that actually stop it.
What does the Claude Code MCP vulnerability tell us about skill trust models?
It shows that the dangerous step isn't installation — it's configuration inheritance. CVE-2025-59536 didn't require a victim to run npm install or click "allow" on a new tool; the nested settings file did the approving on the victim's behalf the moment the project was opened. That's structurally different from a classic malicious-package flow, and worse: most registry security models (code scanning at publish, signature checks at download) assume a discrete install event they can gate. When trust is inherited transitively through a config file that a tool reads implicitly, there's no single gate to instrument. Check Point's research and the parallel reporting from The Hacker News (Feb 2026) both frame this as a consent-bypass class of bug specific to agent tooling, distinct from the traditional "malicious dependency" problem — which is exactly why skill registries need controls beyond what package registries already do.
How have attackers already weaponized name confusion to get malicious code installed?
The npm ecosystem shows the mechanics attackers will reuse against skill registries almost unchanged. In October–November 2024, The Register reported on a campaign — citing research from Socket, Phylum, and Checkmarx — that published more than 287 typosquat packages impersonating popular libraries with tens of millions of weekly downloads, including names like pupeter and pupetier mimicking Puppeteer. Post-install scripts were obfuscated, fingerprinted the host OS, and fetched a platform-specific second-stage binary; the campaign resolved its command-and-control IP address through an Ethereum smart contract specifically to survive takedown requests against any single domain or host. None of this required breaking npm's infrastructure — it exploited the fact that name similarity and version-string matching are the only signals most developers and automated tools check before trusting a new dependency. A skill registry with fuzzy-matched names ("web-search-skill" vs "websearch-skill") and no publisher verification inherits the exact same blind spot.
Do registry-scale campaigns still work in 2026, or has tooling caught up?
They still work, and they've gotten faster. Microsoft's Security Blog documented a campaign on May 28, 2026 in which a single threat actor published 14 typosquat npm packages mimicking OpenSearch and Elasticsearch tooling within a four-hour window, targeting cloud and CI/CD secrets specifically — AWS IMDS credentials, Secrets Manager values, Vault tokens, and npm publish tokens. The compressed timeline matters: most registries still rely at least partly on community reporting or delayed automated scanning to catch malicious publishes, and a four-hour window is enough for CI pipelines that auto-pull "latest" on every build to ingest the payload before any human notices. Agent skill registries, many of which are younger than npm's abuse-detection tooling by a decade, are publishing with even less scrutiny today — which means the time-to-detection gap that let this campaign succeed is, if anything, wider for skills than for packages right now.
What makes a "skill" a higher-privilege artifact than an average package?
A skill or MCP server is typically installed specifically because it needs to act — read files, call external APIs, execute shell commands, or hold credentials — which means the abuse case isn't "unexpected code ran," it's "code ran with exactly the permissions the developer intended to grant, just to the wrong actor." A typosquatted logging library might exfiltrate one environment variable; a typosquatted "git-commit-helper" skill likely already has shell access and repo write scope by design. That elevated baseline means the same install-time scanning techniques that catch npm post-install scripts — obfuscation detection, egress-pattern matching, credential-path access to ~/.aws, ~/.ssh, or ~/.npmrc — need to run against skill manifests and hook definitions too, not just against traditional package code, and they need to run before a skill is granted its requested permissions, not after.
What registry-level controls actually stop this pattern?
The controls that work are the ones that treat every publish as untrusted until proven otherwise, rather than trusting a name, a version bump, or a prior clean history. That means artifact signing with a transparency log so a consumer can verify a skill came from its claimed publisher; install-time static and behavioral scanning that runs before code executes, not after a report comes in; version and hash pinning so "latest" can't silently swap in a malicious release; least-privilege scoping so a skill only gets the specific tool permissions it declares needing; and explicit re-consent whenever a config change (like CVE-2025-59536's nested settings) would expand what a project can auto-approve. Just as important is retroactive re-scoring: when a new indicator or technique is identified, registries need to re-evaluate everything already installed, not just new publishes, since campaigns like the 2024 npm one ran for weeks before public disclosure caught up.
How Safeguard helps
Safeguard's Eagle classifier scores exactly the indicator classes these campaigns rely on — install-script and post-install behavior, obfuscated payloads, egress patterns matching known C2 infrastructure, credential-path access, typosquat similarity to top packages, and metadata anomalies like a brand-new publisher with an aggressively versioned release — across npm, PyPI, and other ecosystems at publish time. The Gold Registry admits no artifact Eagle scores above 30, and when Eagle is updated it re-scores the full historical corpus automatically, so a skill or dependency reclassified as malicious after the fact surfaces as a finding within seconds rather than waiting for a developer to notice. The same install-time and CI enforcement points that block a malicious PyPI or npm publish today are the right foundation for skill and MCP-server registries as they mature — the failure mode CVE-2025-59536 exposed is a reminder that consent and permission boundaries need the same scrutiny as the code itself.