OpenClaw

The OpenClaw Story

In January 2026, an open-source project called Clawdbot appeared on GitHub. Built by Peter Steinberger—founder of PSPDFKit, a well-known mobile software company—it was a personal AI agent that could write code, manage your calendar, control smart home devices, and interact across WhatsApp, Telegram, Slack, and a dozen other platforms. Within weeks it had over 157,000 GitHub stars—eventually surpassing 250,000, more than React—making it one of the most popular open-source projects in the world.

Then things got complicated. Anthropic sent a trademark complaint—the name was too close to "Claude." Steinberger renamed it to Moltbot, then two days later to OpenClaw. A companion product, Moltbook, followed the same path. The drama made headlines everywhere from CNBC to TechCrunch. Three names in five weeks. The internet couldn't look away.

But it was a quote from Steinberger that crystallized the real conversation. In a widely-read Pragmatic Engineer interview, he said:

"I ship code I don't read."

He had made over 6,600 commits in January 2026 alone—almost all generated by AI agents. The quote became a lightning rod. Supporters saw it as the logical conclusion of vibe coding: if AI can write code, why read it? Critics saw something more dangerous: autonomous software running on your machine with access to everything you have access to.

On February 15, 2026—just weeks later—Steinberger joined OpenAI. Sam Altman announced it personally. OpenClaw moved to an independent open-source foundation to continue without him.

What OpenClaw Actually Is

OpenClaw isn't a coding tool in the way that Replit or Claude Code are coding tools. It's a full personal automation platform. At over 430,000 lines of code, it does everything:

• Connects to WhatsApp, Telegram, Slack, Discord, and 15+ messaging platforms
• Manages your calendar and email
• Controls smart home devices
• Writes, tests, and deploys code
• Runs 24/7 on your machine with persistent memory across sessions

It's model-agnostic—it can run on Anthropic's Claude, OpenAI's models, or open-source alternatives like Kimi 2.5. This flexibility means OpenClaw inherits whatever safety guardrails (or lack thereof) the underlying model provides.

The ambition is staggering. So is the attack surface.

What Went Wrong

Here's what makes agents like OpenClaw fundamentally different from a chatbot like ChatGPT or Claude.ai: they run on your machine.

When you use ChatGPT in a browser, it can only see what you paste into it. When you run OpenClaw on your laptop, it can see everything your machine can see:

• Your ~/.zshrc or ~/.bashrc—where many developers store API keys
• Your .env files—where applications store secrets
• Your ~/.ssh directory—the keys that grant access to every server you manage
• Your environment variables—which may include tokens for cloud services, databases, and healthcare systems
• Your browser cookies and saved credentials, depending on how much access you grant

This isn't a theoretical concern. It's the design. OpenClaw needs access to your messaging apps, your calendar, your filesystem to do what it promises. The question is: what guardrails exist?

Within 48 hours of going viral, security researchers had their answer. OpenClaw installations were found storing API keys in plaintext configuration files accessible to anyone on the network. Third-party "skills"—community-contributed plugins—contained credential stealers and backdoors. Users were giving a 430,000-line program they'd never audited access to their most sensitive accounts.

[March 2026] ClawHavoc: The Supply Chain Gets Worse

In late February 2026, the malicious skills problem on ClawHub—OpenClaw's community plugin marketplace—escalated dramatically. Researchers tracking the "ClawHavoc" campaign found that the number of malicious skills had jumped from roughly 341 to over 1,184.

More concerning than the numbers is what the skills now do. According to Trend Micro, 335 skills now install Atomic Stealer (AMOS)—a commodity macOS info-stealer available for $500–$1,000 per month on criminal marketplaces. AMOS harvests keychain passwords, browser credentials, SSH keys, and API keys, then exfiltrates them silently.

The key shift is in the attack model. Earlier malicious skills relied on the user to run them. The newer skills manipulate the AI agent itself as a trusted intermediary—embedding instructions that cause the agent to install the malware on the attacker's behalf. The user sees the agent working normally. The agent doesn't know it's been compromised. The malware runs with the user's full permissions.

[March 2026] New Critical Vulnerabilities

Two new CVEs have added to OpenClaw's growing vulnerability catalog (now tracked at github.com/jgamblin/OpenClawCVEs):

• CVE-2026-28446 (CVSS 9.8, Critical)—A pre-authentication remote code execution flaw in OpenClaw's voice-call extension. An attacker needs no credentials to exploit it. Approximately 42,000 publicly exposed OpenClaw instances were found vulnerable—up from roughly 1,000 just weeks earlier. Fixed in v2026.2.1.
• CVE-2026-28458 (CVSS 7.5, High)—The WebSocket endpoint used for real-time communication lacks authentication, allowing an attacker to steal session cookies across browser tabs. This means a malicious webpage open in one tab could hijack your OpenClaw session in another.

[March 2026] Rapid Security Hardening

To its credit, the OpenClaw project has responded with a burst of security-focused releases. Versions v2026.2.17 through v2026.2.25 shipped transport security improvements, session cleanup fixes, and WebSocket authentication lockdowns. The WebSocket vulnerability was patched within 24 hours of public disclosure. The onboarding experience now warns that OpenClaw is "personal-by-default" with a single trusted operator boundary—an acknowledgment that multi-user or public-facing deployments were never the intended use case.

These are positive steps. But they also underscore the fundamental tension: a project moving at 6,600 commits per month will always be patching vulnerabilities faster than most users can update.

And it wasn't just OpenClaw. Across the broader AI agent ecosystem:

• EchoLeak: A zero-click vulnerability in GitHub Copilot allowed data exfiltration without any user interaction. An attacker could send an email with hidden instructions; Copilot would ingest the malicious prompt and silently extract sensitive data.
• IDE vulnerabilities: Security researcher Ari Marzouk disclosed over 30 vulnerabilities across popular AI coding tools—Cursor, Windsurf, Copilot, and others—in what he called the "IDEsaster" disclosures.
• Prompt injection: Malicious code comments or documentation can redirect an agent's behavior. An agent reading a compromised README file could be instructed to exfiltrate your .env file to an external server—and you'd never see it happen.

Why This Hits Healthcare Harder

If you're a clinician building tools with AI—even personal prototypes—your machine may contain credentials that connect to healthcare systems. An API key for a clinical database. OAuth tokens for an EHR sandbox. Test credentials for a HIPAA-covered service.

A leaked API key on a personal project is embarrassing. A leaked API key that grants access to patient data is a HIPAA violation—with penalties that start at $100 per record and scale to millions.

Hallucinated Dependencies: A New Attack Vector

There's another risk specific to AI-generated code that connects directly to security. When coding agents recommend installing software packages, roughly one in five recommended packages doesn't actually exist. The agent hallucinated the name.

Normally, that just means an error message. But attackers have figured out something clever: they register malicious packages using the fake names that AI models commonly hallucinate. Security researchers call this "slopsquatting." When an agent recommends a hallucinated package and then installs it—the malicious version runs on your machine with whatever permissions the agent has.

This is especially dangerous with autonomous agents that install dependencies without asking. A coding agent that auto-installs packages is one hallucination away from executing malicious code.

[March 2026] The Broader Agentic AI Threat Landscape

OpenClaw's vulnerabilities are not isolated. They are symptoms of a broader security crisis as autonomous AI agents proliferate across every industry. Several developments in early 2026 illustrate how quickly this landscape is evolving.

State-Level Actors Are Using AI Agents Offensively

Chinese state-affiliated group GTG-1002 has been documented using AI agents to execute 80–90% of attack lifecycle steps autonomously—from reconnaissance to exploitation. This is not theoretical; it represents a fundamental shift in how adversaries operate. When attacks are automated by AI, they scale faster and cost less to execute than human-driven campaigns.

Shadow AI Costs Are Quantifiable

Data breaches involving unauthorized "shadow AI" tools now cost organizations an average of $670,000 more than standard security incidents. Palo Alto Networks has called AI agents "2026's biggest insider threat"—not because the agents are malicious, but because they operate with broad permissions and minimal oversight inside enterprise networks.

Healthcare AI Is Already Being Exploited

In March 2026, researchers demonstrated that Doctronic, a healthcare AI system used for clinical decision support, could be jailbroken via prompt injection—the same attack class that affects OpenClaw skills. Researchers were able to triple recommended OxyContin doses by manipulating the system's instructions. This is the direct clinical consequence of the security patterns we see in the agent ecosystem.

Consumer AI Browsers Are Vulnerable Too

Perplexity's Comet browser was found to contain zero-click exploits: a malicious calendar invite could silently exfiltrate files from the user's machine with no interaction required. This reinforces a pattern: any tool that combines AI capabilities with local system access creates an attack surface that traditional security models were not designed to handle.

Safer Alternatives to OpenClaw

OpenClaw's security problems sparked a wave of alternatives designed to prove you don't need 430,000 lines of unauditable code to build a useful AI agent.

NanoClaw launched in late January 2026 as a direct response to OpenClaw's vulnerabilities. Its entire core logic is roughly 500 lines of TypeScript—a developer (or a second AI) can audit it in under ten minutes. The key innovation is containerization: the agent runs inside isolated Docker containers with no access to your host filesystem or environment variables. Your API keys, SSH keys, and credentials stay walled off by default.

Nanobot, from the University of Hong Kong, takes minimalism further: approximately 4,000 lines of code, 45MB of memory, boots in under a second. A senior developer can read the entire source code in an afternoon and verify every action it takes.

Protecting Yourself

Whether you use OpenClaw, a lighter alternative, or any AI agent, the same principles apply. Use them the way you'd use any powerful tool in medicine: understanding the risks and applying appropriate safeguards.

1. Separate Your Secrets

The single most impactful thing you can do: don't store API keys where agents can read them.

• Use a dedicated secrets manager (1Password, Bitwarden, or your OS keychain) instead of .env files or shell profiles
• If you must use environment variables, load them only in the specific terminal sessions that need them—not globally
• Never store healthcare-related credentials on the same machine where you run experimental AI tools
• Treat your ~/.ssh directory as crown jewels—restrict agent access to it

2. Use Permission Systems

Choose agents that ask before acting. Claude Code's permission modes let you require approval before file writes or command execution. Its hook system can block specific actions entirely—for example, preventing any write to files matching *.env or *credentials*.

NanoClaw's containerization approach goes further: the agent physically cannot access files outside its designated directory. Even if it's compromised, the blast radius is contained.

3. Verify Before You Install

When a coding agent recommends a package or dependency, verify it exists and is legitimate before installing. Check the package registry directly. Look at download counts and publication dates. A package with 3 downloads published yesterday is not the same as one with 3 million downloads maintained for years.

4. Review Before You Push

"I ship code I don't read" makes for a great headline. It's a terrible security practice. Before any code leaves your machine:

• Run git diff and actually read what changed
• Search for hardcoded secrets: grep -r "API_KEY\|SECRET\|PASSWORD\|TOKEN" .
• Check that no .env files are staged for commit
• Look for unfamiliar package imports you didn't request

5. Understand What You're Connecting

Before giving any agent access to a messaging platform, cloud service, or database, ask yourself: what's the worst thing that could happen if this agent were compromised? If the answer involves patient data, financial records, or privileged system access—reconsider, or add additional safeguards.

Resources

The OpenClaw Story

Security Research

March 2026 Updates

Safer Alternatives

Podcasts

Healthcare & Shadow AI

Conclusion: The OpenClaw Lesson

OpenClaw isn't a cautionary tale about a bad product. It's a well-built platform created by an experienced developer that attracted 250,000 stars for good reasons. The problem isn't OpenClaw specifically—it's what OpenClaw represents: a new category of tool that blurs the line between "software you use" and "software that acts on your behalf with your credentials."

Steinberger shipping code he didn't read was a choice about his own risk tolerance. But when 250,000 people install that same agent—many of them less technical, some of them handling sensitive data—the risk calculus changes. The agent that's a productivity miracle for one person is a security incident waiting to happen for another.

The answer isn't avoidance. AI agents are genuinely useful, and they're not going away. The answer is choosing tools with appropriate guardrails for your situation. If you're a clinician experimenting with AI tools, the question isn't "should I use agents?" It's "does this agent have the security controls my situation demands?"