“ClawJacked” Vulnerability Allows Malicious Websites to Take Control of OpenClaw

Oasis Security discovered a vulnerability in the popular OpenClaw agentic AI software that allows websites to silently bruteforce access to a locally running instance and take it over.

OpenClaw (previously known as Clawdbot and then MoltBot) is an AI agent that runs locally on your computer and performs tasks for you, such as sending messages, handling your calendar, even browsing for you.

In order to perform these functions, it needs access to your system. You can grant it full system access or sandbox it to reduce the potential damage of an exploit.

OpenClaw already has had issues with over 1,000 malicious skills discovered in OpenClaw’s community marketplace known as ClawHub, the #1 most downloaded skill being crypto-stealing malware.

However this vulnerability affects the core system, no user-installed plugins needed.

OpenClaw runs a gateway that handles authentication, and generally manages the AI agent. The gateway works using a WebSocket server. Authentication is handled by either a token (a long random string) or a password. The server treats local access to the server as inherently trusted, and for some reason it doesn’t apply the same rate limiting rules as with external connections.

A malicious website can simply open a WebSocket of its own via JavaScript and connect to localhost, which is allowed. The website can then bruteforce the password at hundreds of attempts per second.

Once the site is authenticated, it can be approved as a trusted device and issue commands to the gateway. There’s no user prompt for localhost device pairings.

The attacker now has full control of OpenClaw and can dump data, perform actions, whatever they want.

The attack seems so simple that it’s a wonder no one noticed it before now.

There seem to be a few failures here: for one, why aren’t localhost connections subject to the same rate limiting as other ones, and why isn’t there a user prompt when a local connection tries to authenticate authenticate itself as a trusted device?

Why are WebSockets allowed full access to localhost without any restrictions?

There was a similar issue in browsers before, in which websites could access devices on localhost, and that got patched by blocking requests to 0.0.0.0. Perhaps something similar should be done with WebSocket to prevent websites from accessing local services running on your machine.

OpenClaw needs to enforce the security mechanisms it already has for all connections, including localhost. It’s a bit bizarre that they removed rate limiting and the user prompt for new devices, but kept the password. It seems like they reduced the security for almost no gain, since you still have to type the password anyway.

Careless mistakes like this one highlight the dangers of agentic AI: there’s a lack of serious consideration for security on these agents that has taken years for operating systems and browsers to develop.

Many people seem all too happy to give a random AI agent carte Blanche access to their machine with very little in the way of sandboxing or restrictions.

It’s reminiscent of the early days of browsers where there was very little in the way of security and malicious websites could take over your computer without much effort.

I fear AI agents will need to undergo a similar trial-by-fire where developers learn how to secure them properly over the course of years before they can be considered secure.