Github’s viral AI assistant Moltbot is a step away from a massive breach

Moltbot AI became viral overnight, but researchers warn that the “vibe-coded” tool might be leaking your credentials.

Moltbot, formerly Clawdbot, is an open-source local AI agent that, according to its tagline, is the “AI that actually does things.” It is designed to act on a user’s behalf across real services like Gmail, WhatsApp, Telegram, Slack, calendars, browsers, and local files.

Starting as a personal tool for one developer to handle personal tasks, it went viral within weeks of its launch, amassing more than 44,200 stars on GitHub and having over 300 contributors.

The buzz around the new AI agent is a real thing, as Cloudflare shares jumped 14% in premarket trading on Tuesday. Renewed social media excitement reignited investor interest in Cloudflare’s infrastructure, widely used by developers to run Moltbot locally on their devices.

However, OX security researchers are pointing out obvious vulnerabilities and a lack of guardrails that might allow attackers to exploit the viral AI agent. They identified more than 1,200 Moltbot instances publicly reachable on the internet, many of them in the United States.

“While these are only public instances, we infer there are tens of thousands – possibly hundreds of thousands – of private deployments running locally on personal machines and inside private organizations,” says researchers.

Based on download patterns, researchers estimate that between 300,000 and 400,000 people may already be using Moltbot without knowing the risks.

OX Security disclosed its findings to the creator of Moltbot, Peter Steinberger. In response, Steinberger described the project as a “tech preview” and a “hobby,” adding that security issues could be addressed once the project becomes ready for production or commercial use.

Credentials are not secured

According to OX researchers, Moltbot stores credentials, API keys, and environment variables locally in cleartext files under a directory called ~/.clawdbot. The data is not encrypted at rest, meaning any malware, infostealer, or unauthorized local user could read it without exploiting Moltbot itself.

“Moltbot does not treat credentials as protected secrets. Any process or user with access to the local filesystem can read them directly, without exploiting Moltbot or bypassing application-level controls,” researchers say.

Even more concerning, researchers found that credentials users believe they have deleted can persist in backup files. Moltbot automatically keeps up to five rotating .bak copies of its configuration files. When a user removes an API key through the interface, that secret may still exist in one of the backups on disk.

“Infostealers can collect API keys and credentials even after users believe they have removed them, just by reading the data from the backup files inside the same directory,” warns the Ox team.

Over 300 contributors increase risks

Moltbot’s popularity has drawn in more than 300 contributors, many of whom commit code regularly. Collaboration is a key to open-source projects and helps fuel AI agents’ rapid growth. Still, it introduces risks.

OX researchers warn that it takes only one malicious commit from an attacker or a compromised developer account, and a backdoor could be introduced into the tool. As it is already deployed at a massive scale, this might pose a huge risk to users.

Similar attacks have played out before in the open-source ecosystem, particularly through hijacked NPM packages.

“Because Moltbot is gaining popularity so quickly, we project that in the following weeks, attackers will be able to find new attack vectors and zero-days exploiting Moltbot and potentially exfiltrating user information,” explained the team.

Vibe-coded with no guardrails

OX Security describes much of Moltbot’s codebase as “vibe-coded.” This, according to researchers, is a huge security risk.

“Moltbot doesn’t hide the fact that it’s been vibe-coded most of the time – much of the project is vibe-coded with the use of AI coding tools – and it goes even a step further by actively encouraging contributors to submit vibe-coded pull requests,” OX researchers say.

Their analysis found widespread use of risky patterns, including frequent use of eval and execSync, unsanitized HTML rendering, and unsafe command execution paths.

This puts users at risk of remote code execution, cross-site scripting, denial-of-service attacks, and path traversal vulnerabilities.

OX Security also observed dozens of security issues being disclosed publicly in Moltbot’s GitHub issues instead of private reporting channels.

There is also no formal security patching or update process. Many early adopters are likely running the first version they installed, leaving them exposed even after issues are identified.

Vulnerable to indirect prompt attacks

Moltbot integrates with external systems and is also exposed to indirect prompt injection attacks.

An attacker doesn’t need direct access to the tool itself. In some scenarios, sending a carefully crafted email, message, or document to an account connected to Moltbot could be enough.

For example, a malicious prompt hidden inside a PDF or email could instruct Moltbot to exfiltrate files, secrets, or configuration data.

Researchers found that Moltbot does not consistently warn users or request confirmation before following instructions fetched from external sources.

Use Moltbot with caution

For now, OX Security recommends caution:

• Check your Moltbot configurations to ensure you are not allowing any automated command execution on your machine that is overly permissive.
• Don’t add platforms you are not going to use actively – when you decide to stop using them, make sure to remove unused integrations and delete them afterwards from the configuration files.
• Manually delete backup files in ~/.clawdbot (note that you also need to remove backup files from ~/clawdbot if you want the information to be fully removed from your machine).
• Make sure Moltbot is not connected publicly to the internet – avoid exposing Moltbot to the public internet.
• If public exposure is required by design, mitigate access by blocking unknown IP addresses and restricting access by IP allow-listing.
• Update regularly and monitor for security advisories, as attackers keep searching for weaknesses and vulnerabilities. A continuous updating routine will make your environment much more secure.

Unlock more exclusive Cybernews content on YouTube.