In the past few days, the AI community has been taken back by a new AI assistant that stands out due to its native, seamless integration with an enormous number of messaging services.

The promise is simple: picture yourself riding a motorcycle across South America and stopping to read a new Telegram message from your assistant saying: “Hey, just finished your dream website. Want me to do anything else?”. One persistent assistant, available anywhere, with the ability to carry out real work directly on your own machines. You can connect with this agent at any time, anywhere, by a plethora of different apps. That’s what Clawdbot promises.

The possibilities are endless.

Which means.

The possibilities are endless.

Clawdbot (now Moltbot) is an open source, self-hosted control plane for running a personal assistant on your infrastructure, but with the UX of “just DM it like a friend.” The agent has many capabilities and features, integrations with many apps, and full system access.

With promises of performance and overall social media hype, many people rushed to deploy their own instance of Clawdbot. And that’s where things started to go south. Tons of instances running on public servers, ports wide open, "temporary" configs that never get changed, and control panels accidentally turned into public dashboards, and this was widely discussed on X:

@theonejvo’s article talking about Clawdbot’s security issues

This scratched our interest. And so we thought: “Can an AI hack another AI system? Can a hackbot hack Clawdbot?”So we put Hackian, our AI pentester, to the test. We deployed a Clawdbot instance and launched it against the URL, following black-box approach.

The Vulnerability

Hackian was able to find a one-click account takeover to remote code execution (RCE) in approximately 1 hour and 40 minutes. A victim would simply need to visit an attacker-controlled website, which would leak the authentication token from the Gateway Control UI, which is enabled by default, via a websocket channel and then an arbitrary command will run, even if the victim is hosting locally. Here’s a first overview of the vulnerability, allowing for account takeover (ATO):

00:00

00:00

Keep in mind Hackian did this fully autonomously. And the steps it took are detailed below.

Recon

Hackian started off much like any other security researcher would: reconnaissance, reconnaissance and more reconnaissance. From this, it was able to pinpoint some interesting exploration paths:

The generated script successfully extracted sourcesContent from the leaked source map. By grepping for specific protocol patterns, it identified that the client manages states for a WebSocket Gateway. Most importantly, it located the logic for buildToolStreamMessage, which indicates the application is designed to execute "tools" via the socket connection.

After several rounds of recon work, Hackian presented us with a neat summary of the most interesting quirks it identified:

The investigation confirmed that the application’s security relies heavily on client-side logic and message-layer authentication. By exposing its source maps and allowing cross-origin WebSocket upgrades, the target has provided all the necessary primitives to attempt a session takeover or unauthorized execution.

JavaScript source code and websocket analysis

After an overall recon of the application, Hackian decided to zero in on the most promising areas of exploration: JavaScript source code and WebSocket analysis. The objective is simple: reconstruct the source code and find functionalities that may not require authentication.

gatewayUrl override and token leakage

After the analysis of the source code and WebSocket communications, Hackian notices a curious behaviour: URL parameters can be provided to the application. One of them is the WebSocket gateway URL. This is where Hackian strikes gold:

Hackian noticed that setting the gatewayUrl via the query parameters of a GET request automatically triggered a connection to said URL, overriding the previous value. This poses as a classic CSRF scenario as a simple GET request affects directly the data integrity of the Clawdbot Gateway Dashboard. Furthermore, Hackian noticed that the token that was originally stored in the local storage was instantly exfiltrated to the newly set gatewayUrl, compromising the confidentiality of the data saved in the victim’s browser.

After attaining a successful PoC of the vulnerability, Hackian hands off the potential finding to the Verifier, which ensures that this is really exploitable. When confirmation arrives, Hackian reports the vulnerability:

Pwning local instances

Pwning remote Clawdbot instances is cool but most people are actually deploying Clawdbot Gateway locally. This greatly reduces the attack surface but since we do have a 1-click exploit that targets an exposed gateway via the victim’s browser, does it really need to be exposed publicly?

Well, the short answer is no, it does not. The long answer is that we found a way to turn the victim’s browser into being our own exploit assistant so that we can pivot into the victim’s local network the easy way around.

In normal HTTP requests CORS exists to forbid browsers from communicating with origins that do not explicitly allow for incoming requests and most importantly to read outgoing responses. However, Hackian discovered that the main API is not built on top of HTTP but instead it communicates over WebSockets. There is no mechanism similar to CORS for WebSockets and the Clawdbot gateway server fails to validate the origin of the WebSockets connection.

As of the writing of this blog post, the current stable build of Google Chrome is v144 and does not ship with the Local Network Access flag enabled by default which means that our exploit does not need to prompt for this permission (but this may change soon).

If we start joining the pieces of the puzzle, the path that we will follow to build such exploit becomes trivially simple: we have a way to leak the gateway token, we can reach the localhost interface via browser issued WebSockets requests and there are no special permissions that need to be set in order to do so. Sweet!

Let me walk you through the exploit then:

• First off we need to set up a WebSockets server that will listen for incoming requests and save the Clawdbot gateway token to be served on the later stages of our exploit
• Then we will serve the first stage of our exploit which will consist of a page that will open a window to the second stage of the exploit and redirect the current window to the Clawdbot Gateway Dashboard setting the gatewayUrl parameter pointing to the exploit server triggering the vulnerability and leaking the token to the WebSockets server set up in step 1.
• During the second stage of the exploit we will fetch the token from the attacker server and implement the signature algorithms to validate the token against the Gateway server, allowing us to open a session.
• Finally, we are ready to send a message to the Clawdbot agents and ask them politely to run our commands, allowing full exfiltration of the results to the attacker-controlled server.

Implementation details and the full exploit source code are available here. Running the exploit should look something like this:

00:00

00:00

Patch

This has been patched in commit 8cb0fa9. Please update now.

Thanks @tyler6204 for analyzing our pull request with the fix.

Timeline

• January 26: 1:21 PM UTC - Hackbot starts pentesting a live Clawdbot gateway instance
• January 26: 3:05 PM UTC - Hackian confirms the vulnerability
• January 26: 6:02 PM UTC - Vulnerability reported to Clawdbot maintainers 🦞
• January 27: 5:12 PM UTC - Opened pull request
• January 28: 9:32 PM UTC - Fixed in main branch

Final remarks

I think we can all agree technology is moving faster than ever. It’s not yet been 20 years since the first iPhone, and we’re talking about installing brain-computer interfaces and creating AI systems built on the “entire knowledge of humanity”.

This ultra-fast speed is often used as a justification for throwing caution out of the window. We believe that instead of lamenting the new rhythm, we should focus on building security tools that can keep up with the pace. When AI builds faster than ever, AI should test more than ever.

In under 2 hours, Hackian found a 1-click account takeover to RCE, in a product that is being mass adopted by AI enthusiasts all over. **This time, we were the ones that found it, reported it, and prevented harm to come to trusting users. But make no mistake. AI is here for everyone, not just the good guys. **This is not a new story, and certainly won’t be the last. But maybe, by leveraging AI to perform ethical hacking, we might begin to close the gap that widens everyday. At least, that’s what we hope for, and work for, everyday.

Stay safe,

Henrique Branquinho

Bruno Mendes

André Baptista