Malicious Packages Targeting AI Agent Frameworks

Malicious packages built for AI agent frameworks aren't a side effect of the AI boom. They're a direct exploit of the trust model the boom runs on, and the numbers back that up: public code registries went from around 55,000 confirmed malicious packages in 2022 to roughly 454,600 by 2025, with a jump in 2023 around GPT-4's release and a sharper climb still in 2025. Google's Threat Intelligence Group, citing OpenSSF figures, put the year-over-year rise in identified malicious open-source packages at over 1,400% between 2024 and 2025. npm malware more than doubled in 2025 and now makes up close to 90% of all open-source malware ReversingLabs finds. Wiz's cloud threat report found supply chain attacks jumped from about 10% of significant customer incidents to 25%, more than doubling in a single half-year. None of that is abstract risk. It's a measurable redirection of attacker effort toward the exact systems developers now plug into their agents without a second thought, and the industry's response so far has been slower than the attackers deserve credit for.

Three structural trust assumptions that make agent frameworks distinctively vulnerable

Agent frameworks didn't invent supply chain risk. But they stack three trust assumptions on top of each other in a way that older software rarely did, and the first is the worst offender: the belief that a community registry equals a curated one.

Platforms like ClawHub, the public skill registry built for the OpenClaw agent framework, and marketplaces like skillsmp.com make skills broadly available with no verified mandatory security review attached. Compare that to skills.rest, which applies a security review process before skills go live, in contrast to registries that offer no such check. Without that check, a platform's reputation becomes the only signal a developer has to go on, and reputation is cheap to fake when nobody's actually looking under the hood. Most registries are betting on volume over vetting, and that bet is what these campaigns are priced to win.

The second assumption is that plugin and skill architectures can run with implicit trust. Agent skills are modular packages, bundles of instructions and executable code that extend what an agent can do, loaded at runtime with barely any vetting, running with the full privileges of whatever process hosts them. Filesystem access, environment variables, network calls: all open by default. Most MCP clients run JavaScript or TypeScript servers directly through npx, and Python servers through uvx or pipx, so the server inherits host-level privileges the moment it starts. Claude Code, Codex CLI, and Gemini CLI all support metadata-rich instruction files with bundled scripts attached. The plain-language instructions themselves become an attack surface right alongside the code, and most security teams still aren't watching it.

The third assumption treats serialization formats as inert data, just bytes on disk waiting to be read. Serialization formats are not inert data, not just bytes on disk waiting to be read; Python's pickle format, still the dominant way ML model weights get stored and shared, executes arbitrary Python code embedded in the file the moment it loads, before anything in the loaded object can... Python's pickle format, still the dominant way ML model weights get stored and shared, executes arbitrary Python code embedded in the file the moment it loads, before anything in the loaded object can be inspected. JFrog found that roughly 95% of the malicious models it identified used pickle-based formats. safetensors is the safer option, avoiding the arbitrary code execution risk that pickle carries by design, but adoption across the practitioner community still isn't complete, and that gap is the whole story. PickleScan, a widely used open-source tool for catching pickle-based threats, had three zero-day bypass vulnerabilities disclosed in December 2025, each rated CVSS 9.3. Anyone leaning on that tool alone had months of exposure they didn't know about.

These three assumptions don't sit in isolation. An attacker who finds a crack in one can step sideways into the next. A poisoned skill doesn't have to drop a payload at the OS level; it can just instruct the AI system directly to do something malicious, using the very language interface the framework was built to trust.

Engineering the first confirmed malicious MCP server to evade detection

The first confirmed case of a malicious MCP server shows how patient this kind of attack can be. postmark-mcp version 1.0.16 went up on npm on September 17, 2025, published by a developer using the handle "phanpak," and it impersonated a legitimate Postmark Labs library closely enough to pass casual review.

Versions 1.0.0 through 1.0.15 ran clean. They mirrored the official repository's code line for line, executed API calls the way they were supposed to, and set off zero alerts across fifteen sequential releases. Building a long enough track record to clear automated sandbox checks and whatever tracking a registry runs, then flipping the switch once nobody's watching closely anymore, is a deliberate strategy, not an accident. It's a strategy: build a long enough track record to clear automated sandbox checks and whatever tracking a registry runs, then flip the switch once nobody's watching closely anymore.

Version 1.0.16 flipped it. The update quietly forwarded every email sent through the package to a server the attacker controlled. By the time Koi Security (since acquired by Palo Alto Networks) caught the change at the end of September 2025, the malicious version had already been live for more than a week and racked up 1,643 downloads before it came down. Fifteen clean releases bought the attacker trust that no scanner thought to question, and that's the actual lesson here: a clean history is not evidence of a clean package, it's evidence of a patient attacker.

The campaign landscape: how attackers escalated from MCP servers to agent skill registries and coding assistant pipelines

What started with single poisoned MCP servers scaled fast into full campaigns hitting agent skill registries and coding assistant pipelines directly.

The ClawHavoc campaign put 335 malicious skills into the ClawHub marketplace, each one built to drop the AMOS credential stealer. Separately, Koi Security turned up 341 malicious skills sitting in the ClawHub agent skill registry in February 2026, distributing Atomic Stealer malware aimed squarely at cryptocurrency tools and trading infrastructure. Around the same window, Ethiack demonstrated remote code execution in the OpenClaw skill runtime, earning CVE-2026-25253, the first CVE ever assigned to an agentic AI system. The exploit used a crafted URL to trigger authentication token exfiltration through WebSocket hijacking, and the proof-of-concept repository picked up 75 stars within days of going public. The target has shifted. Static model weights aren't the main risk anymore. A registry exploit here can make the agent itself misbehave, not merely run a malicious system command on the side.

The Sandworm_Mode campaign went after AI coding assistants directly, weaponizing npm typosquatting to target Claude Code, Cursor, and Windsurf. Malicious packages mimicking popular utilities installed rogue MCP servers, which then exfiltrated developer secrets and credentials through the rogue MCP servers they installed.

TrapDoor is the most inventive technique in the 2024 to 2026 corpus, full stop. It injected hidden instructions into AI coding assistant configuration files using zero-width Unicode characters, invisible to a human reviewing the file but fully readable by the assistant parsing it. A developer's own coding assistant became the exfiltration mechanism, running what looked like a routine "security scan" that was actually harvesting secrets in the background. The campaign opened pull requests against browser-use/browser-use, langchain-ai/langchain, langflow-ai/langflow, run-llama/llama_index, FoundationAgents/MetaGPT, and OpenHands/OpenHands, all in an effort to spread the poisoned configs into widely used projects. In the same week, the operation hit three separate ecosystems at once: 34 malicious packages and more than 384 versions spread across npm, PyPI, and Crates.io, each with its own tailored execution path. These weren't hijacked legitimate packages. They were fakes from the start, named to sound exactly like the kind of utility a crypto or AI developer would install without a second thought.

Then there's Shai-Hulud, also tracked as Miasma, a worm that compromised more than 500 npm packages and exposed secrets at 487 organizations. Trust Wallet lost a substantial sum after exposed credentials let attackers poison its Chrome extension. The worm later spread to PyPI through the Python.pth startup file mechanism, infecting over 100 packages across both ecosystems combined, with the PyPI wave alone touching somewhere around 19 to 29 packages. Separately, a GitHub Actions attack hijacked AsyncAPI's CI pipeline and backdoored packages with several million weekly downloads. The malicious releases carried provenance signatures that appeared legitimate, because the attacker controlled the CI identity issuing them. The signature was valid. It just signed the wrong thing.

Framework-level vulnerabilities that convert prompt injection into host-level code execution

Microsoft's Semantic Kernel disclosures show, in unusually clear terms, how a prompt injection becomes a code execution problem once a framework fails to keep language and execution separated. Two vulnerabilities, CVE-2026-25592 and CVE-2026-26030, both since fixed, let an attacker reach unauthorized code execution by targeting agents built on the framework.

CVE-2026-26030 came down to a parsing choice. Agents using the Python semantic-kernel package before version 1.39.4, paired with the In-Memory Vector Store, parsed a filter_str argument into an abstract syntax tree and then evaluated it, with attacker-controlled input flowing straight through, unsanitized. That's a textbook injection sink, dressed up in framework plumbing instead of a web form. Framework developers had already anticipated some version of this risk and built an AST-based blocklist validator to catch it, but CVE-2026-25592 showed that blocklist could be bypassed anyway. That says something bigger than "this fix had a bug." Blocklist-style filtering, bolted on after the fact, is the wrong shape of defense for this class of problem, full stop. One prompt, properly built, was enough to run arbitrary code on the machine hosting the agent. No browser exploit needed, no malicious attachment, no memory corruption bug to chain.

Semantic Kernel isn't a niche library. It has over 28,000 stars on GitHub and sits underneath a large number of production agents as core infrastructure. A single flaw in how it maps AI model outputs onto system-level tool calls doesn't stay contained to one application. It travels to every application built on that mapping.

A related case, MCP Inspector's CVE-2025-49596, rated CVSS 9.4, let attackers run arbitrary commands on a developer's own machine by exploiting unauthenticated MCP Inspector proxy endpoints through a browser-based attack, chaining the so-called "0.0.0.0 Day" flaw along the way. The victim only had to visit a malicious website. This is a tooling-layer bug beneath the application layer, so no amount of careful application-side coding would have stopped it. The NSA's advisory on this class of issue makes the shape plain, showing that some MCP implementations let attacker-controlled input reach execution environments with no real constraints in place, and arbitrary code execution follows wherever user-provided logic or code runs without a check in between.

The failure of conventional supply chain defenses to catch these attacks in time

Static analysis and signature scanning, the backbone of most supply chain security programs, weren't built for attackers who play a long game, and that's the core failure here, not a minor gap. In 2025, popular npm packages including chalk and debug were compromised through maintainer account takeovers, with attackers slipping in obfuscated JavaScript that standard scanners failed to flag. Standard scanners missed all of it, because nothing in the code's static shape looked wrong until it ran.

postmark-mcp's fifteen clean releases before the payload dropped expose the real weakness in reputation-based trust: any system that scores a package higher because of its history produces a false negative the moment an attacker plays for the long game instead of the quick win. The malice arrives after trust is already earned, not before, which runs exactly backward from what most detection logic assumes.

Provenance attestation, often pitched as the fix for exactly this problem, isn't enough on its own either. The AsyncAPI CI pipeline hijack proved that malicious releases could carry provenance signatures that appeared fully valid, because the attacker had control of the CI identity that signed them. The cryptographic chain of custody worked perfectly. It just attested to the wrong actor's intentions.

And the tools built to catch the older threat, model file poisoning through pickle, carry their own blind spots. PickleScan's three zero-day bypass vulnerabilities, each CVSS 9.3, meant organizations leaning on it as their only line of defense went months without knowing they were exposed. A scanner is software too, and software has its own attack surface. Treating any single tool as sufficient on its own, whether it's a static scanner, a provenance signature, or a pickle detector, is the exact assumption these campaigns are built to exploit. That's the pattern across every incident in this piece: not a failure of any one tool, but a failure to assume that one tool was ever going to be enough.