Everyone has likely heard of OpenClaw, previously known as \u201cClawdbot\u201d or \u201cMoltbot\u201d, the open-source AI assistant that can be deployed on a machine locally. It plugs into popular chat platforms like WhatsApp, Telegram, Signal, Discord, and Slack, which allows it to accept commands from its owner and go to town on the local file system. It has access to the owner\u2019s calendar, email, and browser, and can even execute OS commands via the shell.<\/p>\n
From a security perspective, that description alone should be enough to give anyone a nervous twitch. But when people start trying to use it for work within a corporate environment, anxiety quickly hardens into the conviction of imminent chaos. Some experts have already dubbed OpenClaw the biggest insider threat of 2026. The issues with OpenClaw cover the full spectrum of risks highlighted in the recent OWASP Top 10 for Agentic Applications<\/a>.<\/p>\n OpenClaw permits plugging in any local or cloud-based LLM, and the use of a wide range of integrations with additional services. At its core is a gateway that accepts commands via chat apps or a web UI, and routes them to the appropriate AI agents. The first iteration, dubbed Clawdbot, dropped in November 2025; by January 2026, it had gone viral \u2014 and brought a heap of security headaches with it. In a single week, several critical vulnerabilities were disclosed<\/a>, malicious skills cropped up in the skill directory, and secrets were leaked from Moltbook (essentially \u201cReddit for bots\u201d). To top it off, Anthropic issued a trademark demand to rename the project to avoid infringing on \u201cClaude\u201d, and the project\u2019s X account name was hijacked to shill crypto scams.<\/p>\n Though the project\u2019s developer appears to acknowledge that security is important, since this is a hobbyist project there are zero dedicated resources for vulnerability management or other product security essentials.<\/p>\n Among the known vulnerabilities in OpenClaw, the most dangerous is CVE-2026-25253<\/a> (CVSS 8.8). Exploiting it leads to a total compromise of the gateway, allowing an attacker to run arbitrary commands. To make matters worse, it\u2019s alarmingly easy to pull off: if the agent visits an attacker\u2019s site or the user clicks a malicious link, the primary authentication token is leaked. With that token in hand, the attacker has full administrative control over the gateway. This vulnerability was patched in version 2026.1.29.<\/p>\n Also, two dangerous command injection vulnerabilities (CVE-2026-24763 and CVE-2026-25157) were discovered.<\/p>\n A variety of default settings and implementation quirks make attacking the gateway a walk in the park:<\/p>\n OpenClaw\u2019s configuration, \u201cmemory\u201d, and chat logs store API keys, passwords, and other credentials for LLMs and integration services in plain text. This is a critical threat \u2014 to the extent that versions of the RedLine and Lumma infostealers have already been spotted with OpenClaw file paths added to their must-steal lists. Also, the Vidar infostealer was caught stealing secrets<\/a> from OpenClaw.<\/p>\n OpenClaw\u2019s functionality can be extended with \u201cskills\u201d available in the ClawHub<\/a> repository. Since anyone can upload a skill, it didn\u2019t take long for threat actors to start \u201cbundling\u201d the AMOS macOS infostealer into their uploads. Within a short time, the number of malicious skills reached the hundreds<\/a>. This prompted developers to quickly ink a deal<\/a> with VirusTotal to ensure all uploaded skills aren\u2019t only checked against malware databases, but also undergo code and content analysis via LLMs. That said, the authors are very clear: it\u2019s no silver bullet.<\/p>\n Vulnerabilities can be patched and settings can be hardened, but some of OpenClaw\u2019s issues are fundamental to its design. The product combines several critical features that, when bundled together, are downright dangerous:<\/p>\n It\u2019s worth noting that while OpenClaw is a particularly extreme example, this \u201cTerrifying Five\u201d list is actually characteristic of almost all multi-purpose AI agents.<\/p>\n If an employee installs an agent like this on a corporate device and hooks it into even a basic suite of services (think Slack and SharePoint), the combination of autonomous command execution, broad file system access, and excessive OAuth permissions creates fertile ground for a deep network compromise. In fact, the bot\u2019s habit of hoarding unencrypted secrets and tokens in one place is a disaster waiting to happen \u2014 even if the AI agent itself is never compromised.<\/p>\n On top of that, these configurations violate regulatory requirements across multiple countries and industries, leading to potential fines and audit failures. Current regulatory requirements, like those in the EU AI Act or the NIST AI Risk Management Framework, explicitly mandate strict access control for AI agents. OpenClaw\u2019s configuration approach clearly falls short of those standards.<\/p>\n But the real kicker is that even if employees are banned from installing this software on work machines, OpenClaw can still end up on their personal devices. This also creates specific risks for given the organization as a whole:<\/p>\n Depending on the SOC team\u2019s monitoring and response capabilities, they can track OpenClaw gateway connection attempts on personal devices or in the cloud. Additionally, a specific combination of red flags can indicate OpenClaw\u2019s presence on a corporate device:<\/p>\n A set of security hygiene practices can effectively shrink the footprint of both shadow IT and shadow AI, making it much harder to deploy OpenClaw in an organization:<\/p>\n If an organization allows AI agents in an experimental capacity \u2014 say, for development testing or efficiency pilots \u2014 or if specific AI use cases have been greenlit for general staff, robust monitoring, logging, and access control measures should be implemented:<\/p>\n A flat-out ban on all AI tools is a simple but rarely productive path. Employees usually find workarounds \u2014 driving the problem into the shadows where it\u2019s even harder to control. Instead, it\u2019s better to find a sensible balance between productivity and security.<\/p>\n Implement transparent policies on using agentic AI.<\/strong> Define which data categories are okay for external AI services to process, and which are strictly off-limits. Employees need to understand why something is forbidden. A policy of \u201cyes, but with guardrails\u201d is always received better than a blanket \u201cno\u201d.<\/p>\nKnown OpenClaw issues<\/h2>\n
OpenClaw vulnerabilities<\/h3>\n
Insecure defaults and features<\/h3>\n
\n
Secrets in plaintext<\/h3>\n
Malicious skills<\/h3>\n
Structural flaws in the OpenClaw AI agent<\/h3>\n
\n
OpenClaw risks for organizations<\/h2>\n
\n
How to detect OpenClaw<\/h2>\n
\n
Controlling shadow AI<\/h2>\n
\n
Secure deployment of agentic AI<\/h2>\n
\n
Corporate policies and employee training<\/h2>\n