OpenClaw Security Risks: What Researchers Found and What Changed

OpenClaw’s security risks fall into five classes, and each one has a documented incident: malicious skills, prompt injection through content the agent reads, internet-exposed gateways, bugs in OpenClaw itself, and broad access to the host because the sandbox is off by default. The project has shipped real controls since March. Most of them are off until you turn them on.

This post is current as of October 15, 2026, and ends with a risk-to-control table.

What are the main OpenClaw security risks?

OpenClaw is a self-hosted agent that runs tools on your machine and takes instructions through chat apps. For the basics, the advisory count, and the exposure figures, see what OpenClaw is and how it works.

One mechanism sits behind every class. The agent runs with the user’s files and logins, reads content the user does not control, and can send data out. The Hacker News reported that Palo Alto Networks called this combination a “lethal trifecta”, a term from researcher Simon Willison. My read: remove any one leg and an attack has much less to work with.

What did Cisco actually find?

A correction first. An earlier version of this post credited this research to Cisco Talos and described findings that are not in Cisco’s report. The research came from Cisco’s AI Threat and Security Research team, published on Cisco’s AI blog on January 28, 2026.

The team ran one third-party skill, “What Would Elon Do?”, against OpenClaw. Their open-source Skill Scanner returned nine findings: two critical and five high. The two critical findings were active data exfiltration, where the skill told the bot to run a curl command that sent data to a server the skill author controlled, and a direct prompt injection that forced the assistant to skip its safety guidelines and run that command without asking. The call was silent, so the user never saw it. High findings included command injection and tool poisoning, a malicious payload hidden in the skill file. Cisco’s verdict: “The skill we invoked is functionally malware.”

Two details matter more than the count. The skill had been inflated to rank number one in the repository, so its popularity was manufactured. And skills are local files loaded from disk, which Cisco stresses are still untrusted input.

Cisco’s reason enterprises should care: agents with system access “can become covert data-leak channels that bypass traditional data loss prevention, proxies, and endpoint monitoring.”

How bad was the ClawHub malicious skill problem?

Koi Security audited 2,857 ClawHub skills and flagged 341 as malicious, as The Hacker News reported on February 2. That is 11.9% of the skills audited. Of those, 335 belonged to one campaign Koi named ClawHavoc.

The trick was social. Koi researcher Oren Yomtov described a skill that looks legitimate, “maybe solana-wallet-tracker or youtube-summarize-pro,” with a “Prerequisites” section that says you need to install something first. On macOS, it told the user to paste a script from glot.io into Terminal, which fetched a binary consistent with Atomic Stealer. On Windows, it asked for a password-protected zip from GitHub that held a trojan with keylogging. Other skills hid reverse shells inside working code. One, rankaj, sent the bot’s credentials in ~/.clawdbot/.env to an outside webhook. Publishing only required a GitHub account at least one week old.

The project responded in stages. On February 7, OpenClaw announced that every skill published to ClawHub is scanned by VirusTotal, including its Code Insight analysis, with daily re-scans. Benign skills are approved, suspicious ones carry a warning, and malicious ones are blocked from download. The post is blunt: “this is not a silver bullet,” and “A clean scan doesn’t mean a skill is safe.”

By May, the project’s security roadmap described a broader pipeline: ClawScan, VirusTotal, static analysis, metadata checks, source provenance, and manual moderation. It says ClawHub can mark a release clean, suspicious, held, quarantined, revoked, or malicious, and that the ClawHub install path should refuse a release marked malicious and quarantined. The post says some of this is still in flight, so treat it as direction.

Decision rule: scanning catches known malware, not instructions. A skill not on your approved list does not get installed, whatever its scan says.

Why prompt injection is still unsolved

OpenClaw’s own docs say it plainly. The prompt injection page lists “Two caveats” that “keep this from being a solved problem”: adaptive human attackers still break models that do well on benchmarks, and smaller or older models are much easier to steer. It adds: “The content itself is a threat surface, not just the sender.” An email, a web page, or a pasted log can carry instructions even if only the owner can message the bot.

The project wraps external content in boundary markers and strips chat-template tokens so a page cannot fake a system message. The docs say that closes one bypass and does not replace allowlists, approvals, or sandboxing. Keep allowUnsafeExternalContent off on hooks and cron payloads.

One default deserves attention. According to the tool and agent permissions docs, agents with message-tool access can send across conversations and channel providers by default, because tools.message.crossContext.allowAcrossProviders defaults to true. In principle, an injected instruction in a web page could ask the agent to post what it knows into another chat. The same page recommends denying gateway, cron, sessions_spawn, and sessions_send for any agent that handles untrusted content.

More on the pattern: prompt injection in AI agents and indirect prompt injection.

Decision rule: an agent that reads untrusted content gets the deny list above, cross-provider messaging set to false, and no secrets. If a workflow needs untrusted input and secrets, split it into two agents.

Exposed gateways and one-click takeover

Early installs left the Gateway, OpenClaw’s control plane, reachable. SecurityScorecard’s STRIKE team reported on February 9 that favicon fingerprinting had confirmed 40,214 exposed instances, 23,505 of them showing active control panels. At the time, it said OpenClaw bound to 0.0.0.0:18789 out of the box, and it told security teams to block port 18789 at the perimeter. The current security docs say a regular host install binds to loopback, while container images default to an exposed bind that should be paired with authentication.

The same SecurityScorecard report lists CVE-2026-25253 (GHSA-g8p2-7wf7-98mq), rated CVSS 8.8: a crafted link steals the gateway auth token for one-click remote code execution, even when the gateway is bound to localhost. It also lists CVE-2026-24763, a Docker sandbox escape through PATH manipulation. Both were patched in 2026.1.29.

Governments noticed. On March 11, Reuters reported, citing two sources, that Chinese government agencies and state-owned enterprises had warned staff against installing OpenClaw on office devices. One source said some staff were told not to deploy it. The other said their agency warned staff but did not ban it. Reuters said the reach of the restrictions was unclear.

Decision rule: treat any install that ran a version before 2026.1.29 as vulnerable. Update it to the current stable release and rotate every token and key it held, since those keys may have been exposed. SecurityScorecard advised 2026.2.1 or later.

Bugs in OpenClaw itself: what the advisory record shows

The explainer has the count and severity split from an October 15 pull. The same 722 advisories, pulled from the repository’s security advisories page through the GitHub API, are grouped by type below. The grouping is my judgment.

Privilege escalation inside the Gateway. Of the 14 critical advisories, six describe a lower-privileged client gaining operator.admin, the Gateway’s top permission level. Several note this reached remote code execution on paired nodes. All six were published between March 12 and March 29. Example: GHSA-4jpw-hj22-2xmc, where a caller with only pairing rights could mint an admin token. It was fixed in 2026.3.11.

Sandbox escapes. Two more critical advisories, both from March 31, are sandbox bypasses: a race condition in the remote file bridge and a heartbeat path that inherited owner rights. In April, a high-severity advisory showed a symlink swap could redirect a write outside the OpenShell sandbox mount in versions through 2026.4.21.

Recurring themes. In a keyword scan of the 722 titles (categories overlap, so they do not sum), 84 mention paths, traversal, or symlinks, 58 mention tokens, credentials, or secrets, 47 mention the sandbox, and 29 mention SSRF.

Pace. February and March produced 424 advisories. Since May there have been 187, including 75 published on September 11 alone.

The lesson: scopes and sandboxes, the controls in the next section, are code too, and both had critical bugs this year. The roadmap describes an OpenGrep rulepack of 148 rules, each tied to a past advisory or finding, that runs on pull request diffs.

Decision rule: patch on a weekly cadence. If nobody owns patching for an install, it gets no company credentials.

What has changed since March?

Four controls matter for enterprise readers. Each has a default you need to check.

Sandbox modes. The sandbox settings offer three modes: off (the default), non-main (sandbox every session except the agent’s main session), and all. Scope defaults to one container per agent, with per-session and shared options. Docker is the default backend. Per the permissions docs, the default workspaceAccess of none keeps the agent’s real workspace out of the sandbox.

Operator scopes and named roles. Operator scopes gate what a client can do after it signs in, from operator.read up to operator.admin. Team gateways can bind people to named roles with a scope ceiling, an agent allowlist, and sandbox: "required", which sandboxes every new session that person creates even if the agent’s mode is off. The docs are clear about the limit: scopes are “a control-plane guardrail inside one trusted Gateway operator domain, not hostile multi-tenant isolation.” For real separation, run separate gateways.

Audit ledger. The Gateway now keeps a metadata-only audit ledger. Agent runs and tool actions are recorded by default. Message events and execution identity are off by default. It never stores prompts, message bodies, tool arguments, or results. Records are kept 30 days, capped at 100,000 rows. The docs warn: “Absence of a row proves nothing,” and it “is not a lossless compliance archive.” Export through OpenTelemetry if you need evidence.

Install policy and egress. security.installPolicy runs your own command to allow, warn, or block every skill and plugin install, including from ClawHub. The same docs note that OpenClaw does not run its own dangerous-code blocking during install, and that plugins run in-process, so treat them as trusted code. Separately, the roadmap describes Proxyline, which routes OpenClaw’s network traffic through a proxy you configure: “Proxyline routes. The proxy enforces.”

OpenClaw Enterprise, announced September 29, is still being developed before its 1.0 release, and the foundation describes it as something organizations “can use for internal pilot workloads.” Judge the build on the laptop, not the roadmap.

The risk-to-control table

This is my mapping, not a standard. Use it to review any OpenClaw install you find.

What to do if OpenClaw is already running

Start from Microsoft’s position. In February, its Defender research team wrote that OpenClaw should be treated as “untrusted code execution with persistent credentials” and that it “is not appropriate to run on a standard personal or enterprise workstation.” If you must evaluate it, Microsoft recommends a dedicated VM or separate physical system, dedicated non-privileged credentials, only non-sensitive data, and a rebuild plan.

My recommendation, in order:

1. Find every install. Search for openclaw, clawdbot, and moltbot, because early installs used the old names. The shadow AI agent inventory covers discovery sources.
2. Update every install to the current stable release. Rotate the keys on anything that ran a version before 2026.1.29.
3. Apply the table. Sandbox on, deny list on, cross-provider messaging off, approved skills only, port 18789 closed.
4. Move anything that touches company data onto a dedicated host. The AI agent sandbox guide compares isolation options.
5. Decide what to allow with the policy table in the explainer. See running OpenClaw in the enterprise for a team rollout and OpenClaw vs Claude Code vs ChatGPT to compare agents.

Bottom Line

OpenClaw’s risks are documented, not theoretical: malicious skills, prompt injection, exposed gateways, and a long advisory record.

The project has shipped sandbox modes, operator scopes, an audit ledger, and marketplace scanning. Most are off or unconfigured by default.

Find the installs, patch them, apply the risk-to-control table, and keep company credentials off any install nobody owns.

FAQ

Did Cisco Talos find the OpenClaw vulnerabilities?

No. The January 28 report came from Cisco’s AI Threat and Security Research team, published on Cisco’s AI blog. It tested one skill, “What Would Elon Do?”, and released the open-source Skill Scanner it used. The report is not a Talos publication.

Does VirusTotal scanning make ClawHub skills safe?

It lowers the risk from known malware. OpenClaw’s own announcement says scanning “won’t catch everything” and that a skill using plain language to instruct the agent “won’t trigger a virus signature.” Treat a clean scan as one input, then review the code.

Is the OpenClaw sandbox on by default?

No. The default sandbox mode is off. Setting non-main sandboxes every session except the main one, and all sandboxes everything. The sandbox has had its own escape bugs, so keep patching.

Can a team safely share one OpenClaw gateway?

Only people who trust each other. The operator scopes docs say to run separate gateways under separate OS users or hosts for strong separation. Within one gateway, a role with sandbox: "required" gets a separate sandbox per person, and a read/write workspace is cut to read-only for those sessions.

What does Cisco’s Skill Scanner check?

Per Cisco, it combines static and behavioral analysis, LLM-assisted semantic analysis, Cisco AI Defense inspection, and VirusTotal lookups. Results list file locations, severity, and guidance, so a team can adopt, fix, or reject a skill. It scans Claude and Codex style skill files, not only OpenClaw’s.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect