Is MoltBot / ClawdBot Safe? Security Risks Every User Must Know (2026 Update)

If you’re considering using MoltBot or ClawdBot (now rebranded as OpenClaw), here’s the deal: These AI tools are powerful but come with serious security risks. They can perform tasks on your system, like running commands, managing files, and accessing sensitive data. However, poor configurations, exposed admin panels, and plaintext credential storage make them vulnerable to attacks.

Key Risks:

• Exposed Instances: Over 4,500 setups were found online, leaving sensitive data like API keys and WhatsApp credentials accessible.
• Plaintext Storage: Credentials are stored without encryption, making them easy targets for malware.
• Unvetted Skills: 26% of third-party skills analyzed had vulnerabilities, some acting as malware.
• User Oversight: 22% of companies reported employees using these tools without IT approval.

How to Stay Safe:

• Restrict admin panel access to 127.0.0.1 and enable authentication.
• Use containers or virtual machines to isolate the bot.
• Regularly rotate API keys and store them securely.
• Vet third-party skills before installation.

While updates in 2026 addressed some issues, like mandatory authentication and safer default settings, core problems like plaintext credential storage remain unresolved. If you use these tools, treat them as high-risk and enforce strict security measures.

you should NOT install Clawdbot (moltbot)

sbb-itb-212c9ea

Security Risks and Vulnerabilities

The security challenges tied to MoltBot and ClawdBot are well-documented and actively exploited. Before incorporating these tools into your workflow, it's crucial to understand the risks involved.

Exposed Instances and Admin Panel Risks

Misconfigurations, such as setting gateway.bind to "0.0.0.0" instead of 127.0.0.1, have left over 4,500 MoltBot instances exposed. These improperly configured dashboards provide unauthorized access to sensitive data, including conversation histories, API keys, file exchanges, and even WhatsApp numbers.

Security researcher Jamieson O'Reilly revealed a particularly alarming case:

"Someone [...] had set up their own Signal (encrypted messenger) account on their public-facing clawdbot control server – with full read access."

This oversight allowed anyone to view Signal device linking URIs and QR codes, opening the door for attackers to pair their own devices with victims' encrypted accounts. Straiker STAR Labs researchers further demonstrated how a simple WhatsApp prompt could extract the creds.json file from a MoltBot instance. This file contains metadata such as real-time contact numbers and caller IDs. Additionally, SOCRadar identified over 1,000 instances exposed via the default port 18789.

Plaintext Credential Storage and Infostealer Threats

MoltBot stores critical data - like OpenAI API keys, Anthropic tokens, and WhatsApp credentials - in plaintext files such as ~/.clawdbot/.env and creds.json, without encryption or protective containerization. This makes them easy targets for malware. Malware families like RedLine, Lumma, and Vidar have been exploiting these vulnerabilities, enabling attackers to harvest API keys and session tokens from compromised hosts.

In one case, an attacker consumed 180 million Anthropic tokens after gaining access to an exposed instance, resulting in potentially thousands of dollars in unauthorized charges.

Unmoderated Skill Libraries and Supply Chain Risks

The ClawdHub registry allows community uploads without moderation, which creates opportunities for supply chain attacks. Malicious skills can inject commands, exfiltrate data, or execute unauthorized actions without user awareness.

In January 2026, the Cisco AI Threat and Security Research team analyzed a third-party skill called "What Would Elon Do?" Using their Skill Scanner tool, they found nine security issues, including two critical ones. The skill functioned as malware, using direct prompt injection and silent curl commands to steal user data.

Pentester Jamieson O'Reilly highlighted another risk by publishing a seemingly harmless "ping" skill on the MoltHub registry. By inflating its download count, he made it appear trustworthy. Within eight hours, 16 developers across seven countries had downloaded it. A broader review of 31,000 agent skills revealed that 26% had at least one security vulnerability.

"AI agents, by design, 'tear all of that down.' They require holes to be punched through every security boundary to function, effectively turning a helpful tool into a high-powered backdoor."

• Jamieson O'Reilly, Security Researcher

Skills also pose dependency risks by installing packages from sources like npm or PyPI. These packages could be tied to compromised maintainer accounts, include malicious code, or turn harmful after gaining widespread adoption. Amy Chang, Leader of Threat & Security Research at Cisco, cautions:

"Granting an AI agent high-level privileges enables it to do harmful things if misconfigured or if a user downloads a skill that is injected with malicious instructions."

The next section will explore documented incidents and expert insights that further illustrate these vulnerabilities.

Documented Incidents and Expert Analysis

Exposed MoltBot Instances on the Web

In January 2026, both Shodan and SOCRadar flagged alarming numbers of exposed MoltBot deployments - 4,211 by Shodan and 1,000 by SOCRadar. SOCRadar's findings were especially concerning, as these instances were accessible via the default port 18789 and lacked any form of authentication. In one case, attackers exploited exposed API keys, consuming 180 million Anthropic tokens, which led to substantial financial losses for the affected user. These breaches actively drained resources, showcasing how vulnerable the system was to exploitation.

Rebranding and Persistent Risks

Even after a rebranding effort, security issues persisted. Automated bots took advantage of the abandoned @clawdbot handle on X, using it to promote fraudulent cryptocurrency wallet addresses. Despite the rebranding, fundamental flaws in the platform's security architecture remained unaddressed. Issues like plaintext credential storage and insecure default settings were still part of the core codebase. These oversights left the platform exposed to repeated attacks, proving that cosmetic changes couldn't compensate for deeper vulnerabilities.

Expert Warnings on Security Gaps

Vlad Constantinescu from Bitdefender pointed out the heightened risks involved:

"The combination of persistent access, stored credentials and operational autonomy greatly raises the stakes compared to traditional web app breaches"

Similarly, the Cisco AI Threat and Security Research Team emphasized the platform's lack of built-in security:

"Security for OpenClaw is an option, but it is not built in"

This underscores how convenience took priority over secure default configurations. Further research revealed that around 22% of enterprise customers had employees using MoltBot without approval from their IT departments. This practice created unmonitored backdoors, leaving corporate networks vulnerable. These expert observations make it clear that robust security measures are not optional - they are essential.

How to Reduce Security Risks

Minimizing Privileges and Securing Admin Panels

To secure your instance, start by limiting admin panel access. Change the gateway.bind setting from 0.0.0.0 to 127.0.0.1 (loopback), and enable authentication methods like JWT, passwords, or tokens to block unauthorized access. If remote access is unavoidable, avoid public ports or port forwarding. Instead, use secure tunneling tools like Tailscale or Cloudflare Tunnels to establish encrypted connections without exposing your instance to the open internet.

Run MoltBot with the least privileges possible. Create a dedicated non-root service account and deploy the agent in a hardened Docker container. Use a non-root user, a read-only filesystem, and disable unnecessary Linux capabilities.

For tool access, follow the principle of least privilege. Explicitly allow actions like GMAIL_FETCH_EMAILS to limit the bot's capabilities and prevent harmful operations. Use credential brokering middleware, such as Composio, to manage OAuth handshakes, ensuring the bot handles only reference IDs instead of raw API keys. Restrict the agent's network access to an allowlist of essential API domains (e.g., OpenAI, Anthropic) to reduce the risk of data leaks.

Regularly run moltbot security audit --deep --fix to enforce strict file permissions. Additionally, manage credentials carefully and thoroughly vet any external skills to reduce vulnerabilities.

Credential Management and Skill Vetting

If your instance has ever been exposed, rotate all API keys and tokens immediately. Revoke any secrets stored in .env or configuration files and generate new credentials.

Switch to scoped, read-only, or short-lived tokens instead of full-access administrative keys. For production environments, use secret management tools like HashiCorp Vault or AWS Secrets Manager instead of storing credentials in plaintext locally.

Third-party skills from registries like ClawdHub can introduce supply chain risks. Research shows that 26% of analyzed agent skills contained at least one security vulnerability. Before installing any third-party skill, use tools like Cisco's "Skill Scanner" to perform static and behavioral analysis.

For example, in January 2026, Cisco researchers analyzed a skill called "What Would Elon Do?" and found nine security issues. Two of these were critical: the skill executed silent curl commands to exfiltrate data and used prompt injection to bypass safety rules.

Restrict high-risk tools like exec, browser, and web_fetch to trusted agents only. Require explicit user approval for any destructive actions. When dealing with untrusted content, such as emails or web pages, use a "reader agent" with tools disabled to summarize the data before passing it to your primary agent.

Monitoring and Isolation Strategies

Isolating the deployment environment is key to limiting the impact of potential breaches. Run MoltBot in a dedicated VM or Docker container to ensure that any compromise is confined to a disposable environment, not your entire system. For Docker, disable network access using network: "none", set memory limits (e.g., 512m), and use a read-only root filesystem to prevent permanent changes.

For VM deployments, disable shared folders, clipboard sharing, and drag-and-drop features to block "VM escape" vulnerabilities. On Linux, apply system-level restrictions like read-only filesystems and disabling privilege escalation.

Enable sandbox mode by updating moltbot.json to set sandbox.mode to "non-main" and sandbox.scope to "session". This confines the agent to a single disposable directory instead of your entire home folder. Use session.dmScope: "per-channel-peer" to isolate conversations between users and prevent cross-user data leaks.

Set up monitoring alerts for suspicious activity, such as authentication failures, rate limit triggers, or pairing requests from unknown IDs - common signs of a breach. Enable logging.redactSensitive: "tools" to automatically remove API keys and secrets from logs. Schedule weekly moltbot security audit --deep scans to catch misconfigurations like exposed admin panels or weak file permissions.

Whenever possible, use higher-tier models like Claude Opus 4.5 for tool-enabled agents. Smaller models are more prone to prompt injection and instruction hijacking. Additionally, set your DM policy to dmPolicy: "pairing" to require manual approval before the bot interacts with new users. Combining isolation measures with regular audits provides a solid defense against security threats.

2026 Security Update: What's Fixed and What's Not

Fixed Vulnerabilities: Progress in 2026

In early 2026, several critical security flaws were addressed, starting with a gateway binding issue. The system now defaults to binding only to 127.0.0.1, preventing the admin dashboard from unintentionally binding to external interfaces like Tailscale IPs. This "loopback-first" approach is automatic unless explicitly configured otherwise.

"Fixed by making gateway bind: auto loopback-first and adding an explicit bind: tailnet mode for tailnet-only listening."

• Peter Steinberger, Creator of Moltbot/OpenClaw

Additionally, authentication is now mandatory for gateway connections. WebSocket connections are refused if no token or password is configured, eliminating the risk of an open dashboard. Another major improvement came from Microsoft, which removed a malicious Visual Studio Code extension that had been spreading remote access malware (ConnectWise ScreenConnect).

The project also underwent several rebrandings - from Clawdbot to Moltbot, and finally to OpenClaw by January 2026 - to settle trademark disputes. While these updates have tackled some major vulnerabilities, several critical risks remain.

Unresolved Issues and Current Recommendations

Despite the progress made, some issues continue to pose serious risks. One of the most glaring problems is the plaintext storage of credentials. If an attacker gains access to your system, they can immediately take control of all secrets stored by the bot.

The MoltHub skill registry (formerly ClawdHub) is another weak point. It still lacks formal code review or vetting processes. In January 2026, a proof-of-concept malicious skill was downloaded over 4,000 times in just eight hours, highlighting how easily supply-chain attacks can proliferate. Cisco researchers found that 26% of the 31,000 agent skills they analyzed contained at least one security vulnerability.

Another issue is the sandbox mode, which is available but not enabled by default. Users must manually configure it, leaving the bot with full privileges by default. This means it can access, modify, or delete any file your user account can.

"Don't run Clawdbot [Moltbot]."

• Heather Adkins, Founding Member, Google Security Team

To mitigate these risks, rotate all API keys immediately if there's any sign of exposure. Store credentials using external secret management tools instead of relying on local storage. Before installing third-party skills, use tools like Cisco's Skill Scanner to detect hidden commands or injection vulnerabilities.

Pre-2026 vs Post-2026: Risk Status Comparison

Risk Factor	Pre-2026 Status	Post-January 2026 Status
Gateway Binding	Could bind to any interface (e.g., Tailscale), exposing the dashboard	Defaulted to "loopback-first" binding; explicit tailnet mode added
Admin Dashboard	Frequently unauthenticated and publicly exposed	Authentication required by default; fail-closed connections
Malicious Extensions	Active malware found on VS Code Marketplace	Identified and removed by Microsoft
Credential Storage	Plaintext storage in ~/.clawdbot/	Unresolved: Still stored in plaintext; requires manual rotation and external secret management
Sandboxing	No default isolation	Unresolved: Sandbox exists but not enabled by default; requires user configuration
Skill Vetting	Unmoderated community uploads	Unresolved: MoltHub remains unmoderated; 26% of skills contain vulnerabilities

While the updates in 2026 have reduced some risks, the core design flaws of the bot remain problematic. A survey revealed that 22% of enterprise customers had employees using the bot without IT approval. If you decide to use MoltBot or ClawdBot, treat it as a high-risk tool that requires constant monitoring and strict security measures.

Conclusion: Making an Informed Decision

Key Takeaways for Users

MoltBot and ClawdBot (now known as OpenClaw) represent a significant evolution in how AI tools interact with systems. These bots can execute commands, manage files, and control browsers - features that, while powerful, pose serious security risks.

The main concerns remain: exposed admin panels, storing credentials in plaintext, and an unregulated skill library where 26% of analyzed skills show security flaws. These vulnerabilities have already led to real-world consequences, including notable financial losses from compromised setups. Addressing these risks requires proactive measures.

If you choose to use these tools, treat them as high-risk and supervise them closely. Run them in a Docker container or dedicated virtual machine, limit the gateway to 127.0.0.1, and carefully review every third-party skill before installation. Use the built-in command clawdbot security audit --deep --fix as a first step after setup. If you suspect any exposure, rotate all API keys immediately and move credentials from plaintext files to environment variables or secure secret managers.

Final Thoughts on Safety and Security

Given these challenges, users must enforce strict control measures to minimize risks. Updates in 2026 addressed some major flaws, such as mandatory gateway authentication and loopback-first binding. However, the core design - granting system-level access to an AI agent - makes security your responsibility rather than a built-in feature.

"We need to stop treating agents like chat toys and start treating them like junior employees with root access: helpful, fast, occasionally wrong, and absolutely not to be given unrestricted access without guardrails."

• Chris Sevilleja, Director of Developer Relations, Auth0

In enterprise settings, around 22% of companies already have employees using MoltBot without IT approval. If you're in IT leadership, now is the time to create clear policies. Either ensure proper isolation and monitoring or block these tools until you can deploy them securely. The real question isn't whether these tools are useful - it’s whether you're equipped to handle the risks they bring to your infrastructure.

FAQs

What steps should I take to secure MoltBot or ClawdBot from potential risks?

To maintain the security of MoltBot or ClawdBot, start by ensuring your network access settings are configured correctly. Avoid exposing control panels to public IP addresses without proper authentication. Instead, bind them to the local address (127.0.0.1) and implement secure authentication methods, such as passwords or tokens. For remote access, consider using secure tunnels like Cloudflare Tunnel to add an extra layer of protection.

Protecting sensitive information is equally critical. This includes API keys, credentials, and conversation data. Store this data securely, encrypt it whenever possible, and rotate keys regularly to minimize risks. Additionally, restrict access to configuration files and keep control panels out of unnecessary exposure to reduce potential attack vectors.

Lastly, keep an eye out for unusual activity by monitoring your system regularly. Having a well-thought-out response plan will help you act quickly if a security breach occurs. These practices can go a long way in preventing unauthorized access and safeguarding your data.

What are the best practices for safely managing credentials with MoltBot?

To keep your credentials safe while using MoltBot, here are some practical tips to follow:

• Store credentials on your device: Keep sensitive information like API keys and tokens stored locally. Avoid using cloud storage unless the data is encrypted.
• Leverage environment variables: Instead of embedding credentials directly into scripts, use environment variables. This minimizes the risk of accidental exposure.
• Restrict access: Only allow trusted individuals access to your device or files. Use strong, unique passwords and enable multi-factor authentication whenever possible.
• Regularly update credentials: Periodically update API keys and tokens. Revoke any credentials that are no longer in use or might have been compromised.

These measures can help protect your credentials from unauthorized access or potential data breaches while using MoltBot.

What security risks should I know about when using third-party skills with MoltBot or ClawdBot?

Using third-party skills with tools like MoltBot or ClawdBot can introduce serious security risks, especially if the setup isn’t handled carefully. Some of the most common vulnerabilities include exposed API keys, OAuth tokens, and improperly secured configuration files. These weak points can open the door to unauthorized access - or worse, full system takeovers. Attackers often exploit misconfigured control panels or open ports that lack proper authentication to run commands or steal sensitive credentials.

Third-party integrations bring additional challenges, such as increasing the likelihood of data leaks, prompt injection attacks, and even remote code execution. Systems with poor security measures are particularly at risk, making it critical to take proactive steps to safeguard your setup.

Here’s how you can mitigate these risks:

• Ensure proper configuration: Double-check all settings to avoid leaving vulnerabilities open.
• Use strong authentication methods: Implement robust passwords, two-factor authentication, or other secure login practices.
• Segment your network: Limit access between different parts of your system to contain potential breaches.

Taking these precautions can help you minimize the dangers associated with third-party skills, keeping your system more secure and resilient.