One Click. Full Compromise. How OpenClaw's Marketplace Became AI's First Supply Chain Crisis.

I have a folder on my machine called openclaw-weekly. There are 31 files in it. I started it when the first advisory dropped on February 3rd, and at some point it stopped being a CVE tracking exercise and turned into something bigger. I think this is the first marketplace-scale supply chain event in the AI agent ecosystem, and I want to put the full picture in one place because nobody else has.

The bug

The vulnerability is almost too simple. OpenClaw's Control UI reads a gatewayUrl parameter from the browser's query string. There's a function called applySettingsFromUrl() that takes that value and rewires the running instance to point at whatever gateway server the URL specifies.

No validation on the URL. No confirmation dialog. No warning banner.

Five steps, maybe three seconds end to end. I read the disclosure and had to go back through it twice because I kept assuming I was missing something. A confirmation prompt, a domain allowlist, literally anything. There was nothing.

By the time the CVE was assigned, roughly 40,000 OpenClaw instances were internet-facing. 63% of those were assessed vulnerable. And because OpenClaw has no auto-update mechanism — it's self-hosted, you pull the patch yourself — those numbers decay slowly. I have a Shodan saved search for this. As of the week I'm writing this, I still see vulnerable instances. I pulled a few to check version strings and stopped when I realized I was looking at what appeared to be production deployments with agent credentials still live.

ClawHub is the bigger problem

The CVE is a bug. Bugs get patched. ClawHub — OpenClaw's public skill marketplace — is the system working exactly as designed, and that's what makes it worse.

Any developer could publish a skill. Skills ran with the agent's full permission set: filesystem, network, credentials, tool invocation. No sandbox. No capability manifest. No runtime boundary between "this skill can read files" and "this skill can do everything the agent can do." The permission model was flat.

Reco's first scan in February flagged 335 malicious skills. Koi Security's follow-up six weeks later found 820+. That's a 140% increase in absolute count.

I spent a weekend pulling payloads from the flagged listings. The techniques were not sophisticated. That's the point — they didn't need to be:

• Command injection through skill parameter substitution. Basic, effective.
• Credential exfiltration disguised as "helpful" cloud-config readers. One of them had 200+ installs.
• WebSocket hijack skills that sat dormant for days before activating. Classic time-delayed payload.
• A privilege-escalation chain that triggered only when specific environment markers were present — it checked for AWS_LAMBDA_FUNCTION_NAME before doing anything.

This is the part I want people to actually sit with. In the npm ecosystem, a malicious package still has to fight a process sandbox. It has to do something observably weird — open a socket, spawn a child process, write to disk. You can catch it if you're watching.

A malicious ClawHub skill doesn't have to fight anything. It runs with whatever permissions the agent has, and the agent's entire job is to call tools and pass credentials to them. At the network layer, a malicious skill making API calls looks identical to the agent doing its job. There's no signal at the process level that distinguishes "skill doing what the user asked" from "skill exfiltrating your AWS keys."

The npm comparison is generous

I keep seeing takes that frame this as "the npm event-stream incident, but for AI agents." I've been thinking about this for a few weeks now, and I think the comparison undersells how bad the structural situation is. Three reasons.

Permissions are flat. npm packages run in Node's sandbox. There's --ignore-scripts, there's --no-scripts, there are process boundaries. AI agent skills have none of this. The skill runs with the agent's permissions, full stop. There is no equivalent of --no-scripts for an agent skill.

Behavior is opaque. A malicious npm package eventually has to do something observable at the system level — open a network socket, write a file, spawn a process. You can instrument for that. A malicious agent skill can exfiltrate through the agent's normal channels: API calls, tool invocations, output tokens. It uses the agent's own communication path. The exfiltration is the normal behavior.

Trust is transitive and unbounded. Several of the ClawHub skills I looked at fetched "configuration" from a remote endpoint at runtime. The static listing on ClawHub was clean. The runtime behavior pulled a second-stage payload from an attacker-controlled server. Any analysis that only looks at skill code at publish time misses this entirely.

The numbers are misleading in both directions

I keep seeing "12% of ClawHub is malicious" cited everywhere. That number is from Reco's February scan: 335 flagged out of ~2,800 skills total. Koi's March numbers tell a different story: 820 flagged out of ~10,700.

The ratio dropped from 12% to 7.7%. That sounds like improvement, but it isn't. The registry grew nearly 4x in six weeks. The absolute count of malicious skills more than doubled. The needle got smaller because the haystack got massively bigger.

The thing I haven't seen anyone else report: the median age of flagged malicious skills was approximately 17 days at time of scan. These aren't stale leftovers from the early days. Someone is actively publishing new malicious skills, every week, and has been for the duration of the tracking period.

I got this wrong initially, by the way. When I first saw the Reco numbers in early February, I assumed this was a one-time dump — some opportunist uploaded a batch and moved on. The Koi data six weeks later proved that wrong. This is sustained, ongoing activity.

The MCP ecosystem has the same structural problem

OpenClaw isn't an isolated case. Between January and February, researchers filed 30+ CVEs against MCP servers. 38% of scanned public MCP servers had no authentication at all. The WhatsApp MCP Server fell to tool poisoning — I wrote that one up in detail in the tool poisoning post. Anthropic's own MCP Inspector shipped with an RCE.

The pattern, if you strip away the product names:

• Ship a tool or skill registry
• Give skills agent-level privileges by default
• Skip sandboxing because it slows down the demo
• Treat behavioral monitoring as a "v2 thing"
• Hit 100k users before anyone asks hard questions about any of this

OpenClaw is just the first one big enough to make the news. It won't be the last. If you're running any agent platform with a marketplace or community plugin system, the same structural problems apply. The specific CVE is OpenClaw's. The architecture is everyone's.

What I'd actually do Monday morning

I've written the generic version of this before — "inventory your supply chain," "apply least privilege." It's not wrong. It's also not specific enough to act on before standup. Here's the compressed version.

Scan for exposed instances, yourself. Don't ask the team if they're running OpenClaw. Go check. Run the Shodan query, scan your IP ranges, look at your DNS records. Our own recon turned up two self-hosted OpenClaw installs we didn't know existed. Nobody was hiding them — they just weren't in any inventory.

Kill every skill you can't attribute. Literal rule. If nobody on the team can name the author of ghost-translator-v2 or explain why it's installed, remove it. You can always add it back.

Pin skill versions and hash the manifest. Auto-update on skills is a footgun. Treat them like locked dependencies. If a skill updates, someone should review the diff before it goes live.

Monitor what skills do at runtime. This is the one that actually matters. Even if your supply chain hygiene is perfect, the only signal that catches a skill that was clean last week and malicious today is behavioral monitoring. What endpoints did it call? What data did it touch? Did it do anything the user didn't ask for?

Write your incident playbook now. Specifically: "an agent skill exfiltrated data." Most teams don't have this playbook. If the answer to "what happens if an AI skill leaks our production credentials" is a long pause and a glance at the SRE, you're not ready.

The regulatory clock is ticking

EU AI Act high-risk enforcement starts 2 August 2026. That's roughly four months from now. If you deploy AI agents in production and you can't produce a supply chain inventory, a risk assessment, and an audit trail, this is exactly the kind of incident regulators will point to when they evaluate "reasonable foreseeability" under Article 9. I wrote up what Article 9 actually requires here.

The OpenClaw crisis is, in a sense, a gift. It happened before enforcement. The teams that use it as a forcing function to build their audit trails now will be in a defensible position by August. The teams that treat it as someone else's problem won't.

Sources

• Dark Reading — Critical OpenClaw Vulnerability
• Reco.ai — The AI Agent Security Crisis Unfolding Right Now
• Hunt.io — Hunting OpenClaw Exposures: CVE-2026-25253
• SonicWall — OpenClaw Auth Token Theft Leading to RCE
• NVD — CVE-2026-25253
• MCP Security 2026: 30 CVEs in 60 Days
• Shodan — OpenClaw Search
• npm event-stream incident postmortem (2018)

I'm hamza in the Quint Discord. If you're auditing your own agent supply chain and want to compare notes — especially if you've got sanitized scan data — I'd like to hear from you.