DEV Community

Cover image for OpenClaw’s Security Nightmare: Lessons in Agentic Engineering Era
Nicolas Francisquelo Tacca
Nicolas Francisquelo Tacca

Posted on

OpenClaw’s Security Nightmare: Lessons in Agentic Engineering Era

#ai #opensource #security #programming

AI agents didn't introduce new security problems. They just made the old ones terrifyingly effective.

173,000 GitHub stars. Two million visitors in a week. And twelve percent of its marketplace skills were malware.

This is the story of OpenClaw — but it's really the story of every developer tool you installed this month without thinking twice.

Quick Context: What's OpenClaw?

OpenClaw — formerly Clawdbot, then Moltbot (renamed twice after trademark issues and branding decisions) — is an open-source autonomous AI agent built by Peter Steinberger. It connects chat apps like WhatsApp, Telegram, and Discord to AI models, letting you automate everything from DevOps to smart home control through natural language.

It exploded in January 2026. 34,168 GitHub stars in 48 hours. Currently sitting at 173,000. Clearly, it hit a nerve — people want agentic tools that connect to the services they already use.

It's open source. It's free. It's use-at-your-own-risk. Like every open source tool in your stack right now.

And that last part is the whole point of this post.

I've been building in the Claude Code ecosystem since day one, and I run A2AX, a monetization marketplace for agent plugins. So I think about supply chain integrity and marketplace trust probably more than is healthy. What happened with OpenClaw hit close to home — not because it was surprising, but because none of it should have been.

What Happened, and Why It Matters Beyond OpenClaw

In late January and early February 2026, a series of security issues surfaced around the OpenClaw ecosystem. I'm not here to do a post-mortem on the project — the security researchers who found these issues wrote excellent reports (linked at the bottom), and the maintainers responded fast. That's open source working as intended.

What I want to talk about are the patterns. Because none of this is new. We've seen all of it before. We just forgot, because AI agents made everything feel so smooth that we stopped thinking about the things underneath.

"It Works" Doesn't Mean "It's Safe"

CVE-2026-25253 was a one-click remote code execution vulnerability (CVSS 8.8). The short version: an unvalidated URL parameter plus a WebSocket connection that didn't check origin headers meant an attacker could steal auth tokens with a single crafted link. Patched quickly.

But here's the real question — how many of us actually check for CVEs on the tools we use daily? Not the security team. You. Me. The developer who installed three new CLI tools last week and moved on.

We know we should check. We've always known. We just... don't. And that was already a problem before AI agents had access to our terminals.

When Anyone Can Publish, Anyone Will

Koi Security audited the skills on ClawHub (OpenClaw's skill marketplace) and found 341 malicious ones out of 2,857 total. Roughly 12%. Most traced back to a coordinated campaign distributing credential-stealing malware disguised as crypto trading tools.

This is not news. This is the npm story. The Chrome extension story. The VS Code marketplace story. The PyPI story. Every time we build a low-friction publishing system — which is great for creators — we also build a low-friction attack surface. We've known this for a decade.

The barrier to publishing on ClawHub was a GitHub account older than 7 days. Sound familiar? npm's barrier isn't much higher. Neither is PyPI's.

When I wrote about skills last time, I showed how simple the structure is: a folder, a SKILL.md, maybe some scripts. That simplicity is what makes skills great. It's also what makes them easy to weaponize. That's not a design flaw — it's a tradeoff we've seen in every ecosystem, and we already know the playbook for dealing with it. We just haven't applied it yet to agent skills.

Your .env File Is a Liability Now

Multiple reports flagged plaintext credential storage in the OpenClaw ecosystem. API keys and tokens sitting in plain text files.

We all know this is bad practice. We've known since forever. But let's be honest — most of us have test API keys and dev tokens scattered across .env files and config files right now. We tell ourselves "it's just a test key" or "I'll rotate it later." Usually fine. Usually harmless.

The difference now is that AI agents amplify the blast radius. They have access to your filesystem, your terminal, sometimes your network. A test key in a plain text file used to be a minor hygiene issue. Now it's a door that anything with read access to your home directory can walk through. Same habit, wildly different consequences.

Same Bugs, Wildly Different Blast Radius

This is the part I can't stop thinking about.

None of the security issues around OpenClaw were novel attack vectors. Input validation failures, plaintext secrets, unvetted marketplaces, missing origin checks — we've dealt with all of this before. There are entire OWASP checklists about it.

What's different is the amplification.

Before AI agents, a compromised npm package could mess with your build pipeline or inject code into your app. Bad, but scoped. A compromised agent skill can access your filesystem, read your credentials, execute terminal commands, make network requests, and do it all while you think the agent is just "helping you code." The attack surface went from "your app" to "your entire dev environment."

Before AI agents, a leaked API key in a repo meant someone could run up your AWS bill. A leaked API key in an environment where an agent has persistent memory and filesystem access means the key can be exfiltrated silently, used immediately, and you might not notice until the invoice hits.

Before AI agents, you had to manually install a malicious package. Now, an agent can install one on your behalf — especially if it hallucinated the package name. Aikido Security documented exactly this: LLMs hallucinating plausible names like react-codeshift (a blend of jscodeshift and react-codemod that doesn't actually exist). Those hallucinated names spread through skill files via copy-pasting and forking. Then attackers publish real packages with those exact names. 237 GitHub repositories referenced react-codeshift. Agents trying to install it would get whatever the attacker uploaded.

SafeDep analyzed 31,132 skills across major marketplaces and found 26.1% contained at least one vulnerability. That's not an OpenClaw stat — that's across the ecosystem. More than a quarter.

Same old vulnerabilities. Massively amplified consequences. That's the shift.

Things We Already Know But Need to Actually Do

I'm not going to pretend I discovered some new security framework. Everything here is something we already know. The OpenClaw situation just reminded me — painfully — that knowing and doing are different things.

Know what you're running. Pin your dependencies — not requests, but requests==2.31.0. Unpinned dependencies are how deferred supply chain attacks work. We learned this from event-stream. We learned it again from ua-parser-js. We'll keep learning it until we actually do it. And when it comes to agent skills, the bar for review is lower than you think. These are usually small, readable markdown files and short scripts. Five minutes scanning a SKILL.md before you install it is not unreasonable. Check who published it. Check if the code matches the description. Check if there's a git history or if everything appeared in one commit.

Treat your dev environment like production. We've always been more careful with prod credentials than dev ones. "It's just a test key" has been our collective excuse for years. But when an agent has the same filesystem access as you do, the distinction between "test environment" and "real environment" gets blurry fast. Use a secrets manager. Rotate regularly. Don't leave things lying around in plain text even if you think they're throwaway — because the agent doesn't know the difference.

Sandbox everything, trust nothing. If the tool you're using offers sandboxing, turn it on. If it doesn't, run it inside Docker or a VM. The technology exists. We've just been lazy about using it because the tools felt trustworthy. And while you're at it — check for CVEs on your entire toolchain. Not just your app dependencies. Your dev tools. Your CLI agents. Your MCP servers. Everything that runs on your machine with your permissions. We've been diligent about npm audit for our projects and completely blind about the tools that build them.

None of this is new knowledge. It's just newly urgent.

OWASP Already Mapped This Out

If you want a structured way to think about all this, OWASP released their Top 10 for Agentic Applications in December 2025, built by 100+ industry experts. Worth bookmarking and reading in full.

The items that map most directly to what we've been talking about: agent goal hijacking via prompt injection, supply chain vulnerabilities through compromised skills and plugins, unexpected code execution from agents generating unsafe code, and human-agent trust exploitation — users blindly trusting agent output. The full list covers everything from memory poisoning to cascading failures across multi-agent systems.

Read that list slowly. Most of these map directly to problems we've solved (or at least understood) in traditional software. Input validation. Least privilege. Supply chain verification. Trust boundaries. The concepts aren't new. The context is.

Who's Watching the Plugin Store?

Every new marketplace — ClawHub, skills.sh, community registries — faces the same fundamental tension: low friction for publishing (good for adoption) vs. quality gates (good for security). Most are landing heavily on the low-friction side right now. We've seen how that movie ends.

The npm ecosystem learned these lessons the hard way over years — typosquatting, dependency confusion, event-stream. Agent skill marketplaces are speedrunning those same growing pains, except the stakes are higher because skills run with agent-level permissions: filesystem, terminal, network, credentials.

This is exactly what I'm trying to address with A2AX — a marketplace where skills stay in creators' private repos, with a curation and trust layer between creator and consumer. If you're building quality skills and care about this stuff, I'm onboarding the first creators now.

The Point

OpenClaw is a genuinely cool project. Open source, community-driven, clearly solving a real need — 173K stars don't happen by accident. The security issues it faced are the same issues every fast-growing tool faces, and the maintainers responded the way you'd hope: patching CVEs within days, adding mandatory authentication, partnering with VirusTotal for skill scanning.

But the broader lesson isn't about OpenClaw. It's about what happens when we bring old habits into a new era.

We've always cut corners on dev environment security. We've always been a little too trusting of open source packages. We've always left test credentials in places we shouldn't. For the most part, we got away with it because the blast radius was small.

AI agents changed the blast radius. Same habits, exponentially bigger consequences.

The good news is we don't need to learn new things. We just need to actually do the things we already know.

The boring stuff. The stuff we've been telling junior devs to do for years while quietly not doing it ourselves.

Time to practice what we preach.

Resources

Top comments (0)