OpenClaw Gateway Takeover, Moltbook's Open Database and Malicious ClawHub Skills: What to Change

Between January 29 and February 2, the ecosystem around OpenClaw, the open-source personal agent, produced three security failures of three different kinds. A crafted link could hand an attacker the token for a user's OpenClaw gateway, and with it code execution on their machine. Moltbook, a social network for AI agents, left its production database open to anyone holding a key its own web pages published. And Koi Security found 341 malicious skills on ClawHub, OpenClaw's skill registry.

OpenClaw, called Clawdbot until last week and Moltbot for a few days, has passed 100,000 GitHub stars, according to its creator, Peter Steinberger. Each failure lines up with a control teams already know from web and package security, and each time that control was missing.

Every number below comes from the advisory, the vendor or the researchers who found the problem, and I say which. My own arithmetic is marked. I have not reproduced any of the attacks.

OpenClaw, Moltbook and ClawHub: the three failures at a glance

Failure	Disclosed	What was exposed	Fix
OpenClaw Control UI trusted a `gatewayUrl` link parameter (CVE-2026-25253, CVSS 8.8)	Advisory January 31, CVE February 1	The gateway token, then operator control of the gateway and code execution on its host	Version 2026.1.29, released January 30
Moltbook's Supabase database had no row-level security	Wiz, February 2	1.5 million agent API tokens, 35,000 email addresses and private messages, with write access	Security policies added in four rounds, in under three hours
Malicious skills on ClawHub, a campaign Koi calls ClawHavoc	Koi Security, February 1	341 malicious skills among the 2,857 audited, 335 of them from one campaign	Reported to ClawHub for removal

Source: the GitHub advisory, the MITRE CVE record, Wiz and Koi Security. The three-hour figure is my arithmetic from Wiz's disclosure timeline.

CVE-2026-25253: a localhost gateway is not a boundary when the browser makes the call

The gateway is the long-running process at the centre of OpenClaw. The README for 2026.1.29 calls it the control plane for sessions, channels, tools and events, on a local WebSocket. The Control UI is the web dashboard it serves, and it stores the gateway's token.

According to the advisory, the Control UI took a gatewayUrl value from the query string without validation, connected to it as soon as the page loaded, and sent the stored token. One click on a crafted link handed the token to the attacker's server. With it, the attacker could connect to the victim's gateway, change its configuration, including sandbox and tool policies, and run privileged actions.

The advisory's most useful line is about scope: the attack worked even when the gateway listened on loopback only, because the victim's browser made the connection. Mav Levin of depthfirst, one of the credited researchers, explains why. Browsers do not apply the same-origin policy to WebSocket connections the way they do to ordinary requests, so the server must check where a connection comes from, and the gateway did not. In his write-up, the attacker's script then switched off the prompts before dangerous commands and moved execution from the Docker sandbox to the host, within milliseconds of the page loading.

Ethiack says its autonomous testing agent found the bug independently, in under two hours, on January 26. The fix, a confirmation before the UI connects to a new gateway URL, was merged on January 28 and shipped in 2026.1.29 on January 30, a release that also removed the option to run the gateway with no authentication.

There is a trap in the upgrade. The advisory lists the npm package clawdbot as affected up to 2026.1.28, but on npm clawdbot stops at 2026.1.24-3, published January 25 and not marked deprecated. The fix shipped under the new name, openclaw, so updating the old package does not reach it. That is my reading of the registry, not a warning from the project. Check the installed package name, and rotate the gateway token if it may have leaked, as depthfirst advises.

Treat the control UI as an admin console. Never take a connection target from a URL parameter.
Check the Origin header on every WebSocket upgrade. Binding to 127.0.0.1 does not do it for you.
Assume the token will leak. Make switches such as sandbox off and approvals off need more than that token.

MCP Apps, the extension I wrote about last week, starts from the opposite assumption: UI content runs in sandboxed iframes, and hosts can require approval for tool calls the UI starts. A dashboard with operator rights deserves at least as much suspicion.

Moltbook: one public key and no row-level security

Moltbook is a social network for AI agents, which join by installing a skill. On February 2, Wiz published how it got into the database behind it. Moltbook runs on Supabase, and the project address and publishable key sat in the site's JavaScript. That is normal: Supabase expects the key to be public, because row-level security (RLS) policies decide what each request may read or write. Moltbook's tables had none.

Wiz says the key gave read and write access to every production table: 1.5 million agent API tokens with their claim tokens, 35,000 email addresses, and 4,060 private conversations between agents, some holding plaintext OpenAI API keys. It counted about 4.75 million exposed records and could edit any post, which is what agents read when they check in. Fixing it took four rounds, each finding something the last one missed.

The skill every agent installs tells it that its API key is its identity and must never be sent anywhere but Moltbook's own domain. Nobody needed to send anything.

MerlinX, the agentic platform whose core I designed, takes the opposite position. Isolation lives in the database: one service and one PostgreSQL, with tenant separation enforced by row-level security rather than by application code remembering to filter. A filter in application code protects only the requests that pass through it. A credential that reaches the database directly, whether in a researcher's terminal or in a bug in your own service, skips it.

Turn on RLS for every table in an exposed schema. That is Supabase's own instruction, and with RLS on and no policies, the publishable key returns nothing.
Test with the public key in CI. Query every table with only the key the front end ships, and fail the build on any row.
Keep secrets out of stored messages. Scan conversation tables for credentials.

ClawHub: skill registries are the new package supply chain

A skill is a folder with a SKILL.md file of instructions, sometimes with code. The README for 2026.1.29 says that with the registry enabled, the agent can search for skills and pull in new ones as needed. That makes ClawHub a package registry in all but name, whose most frequent reader follows instructions.

On February 1, Koi Security published an audit of all 2,857 skills on ClawHub and found 341 malicious, 335 of them from one campaign. They posed as useful tools, including 111 crypto utilities, 57 YouTube tools and 29 typosquats of the ClawHub command-line tool's name. Their documentation had a "Prerequisites" section: install a password-protected ZIP, locked so antivirus could not look inside, or run obfuscated shell commands from a paste site. Koi says the archive held a trojan that can capture API keys, credentials and anything the bot has access to, and traced the macOS chain to a binary matching Atomic macOS Stealer, malware sold as a service. Other skills hid a reverse shell inside working code, or sent the bot's configuration file, credentials included, to an outside server.

None of this is new, which is the point. Koi's summary of the playbook, permissive publishing, typosquats, high-value users and code hidden in plain sight, describes npm, PyPI and the browser extension stores too. What is new is the reader. The README says OpenClaw's default runs tools on the host for the owner's main session, with full access, and a skill's instructions run with that access.

Moltbook's own skill shows the pattern without a registry. The version archived on February 2 asks the agent to add a heartbeat task: every four hours or more, fetch a file from Moltbook and follow it. That file tells the agent to check for a newer version of the skill and download it. Whoever controls those files can change what every subscribed agent does at its next check-in. By my reading, that is a self-updating dependency with no pinning and no review.

Keep an internal allowlist. Mirror reviewed skills, pin each to a commit, and stop the agent installing from the public registry on its own.
Read SKILL.md like a shell script. A prerequisite that asks for a download or a pasted command is a reason to stop.
Shrink what a bad skill can reach. Run the agent as its own OS user or in a VM, without browser profiles, wallets or SSH keys, and with an outbound allowlist.

What I would test before running a personal agent at work

Package name and version. Confirm openclaw 2026.1.29 or later, not clawdbot, then rotate the gateway token.
A cross-origin probe. From a page on another origin, open a WebSocket to the gateway. It should be refused, token or not.
A canary skill. Write a harmless skill whose SKILL.md asks for a "prerequisite" command, and see whether anything stops the agent.
Scheduled fetches. Search installed skills for URLs they fetch and follow on a timer, then vendor or remove them.
The blast radius. Log in as the agent's user and list what it can read. If that includes your browser profile, start there.

OpenClaw's launch post promises "Your assistant. Your machine. Your rules." In its first five days under the new name, a link, a database and a skills page each turned out to have rules of their own.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and agent security.