March 30, 2026
March 28, 2026
March 23, 2026
OpenClaw – Security
A Security Analysis of OpenClaw
From a security perspective, the core problem is not one isolated bug. The real risk comes from the combination of three conditions: high local privileges, exposure to external input, and automatic tool execution. OpenClaw’s own security guidance explicitly frames it as a personal assistant operating within a single trusted-operator boundary, not as a hardened hostile multi-tenant platform for mutually untrusted users. CNCERT has also issued a dedicated risk warning about OpenClaw deployments and usage.
As of March 23, 2026, the official OpenClaw threat model draft lists 37 total threats, including 6 rated Critical. Those threats span the agent runtime, gateway, skills ecosystem, extensions, and client surfaces. That alone suggests an important conclusion: OpenClaw should be understood as a system with a broad and evolving attack surface, not as a product where fixing a single CVE makes the deployment “safe.”
The first major category of risk is authentication and permission-boundary failure. Several public advisories show how easily identity, pairing, or control-plane trust can become the weakest link. CVE-2026-28472 describes a flaw in the gateway WebSocket handshake that allowed device identity checks to be skipped when a token was merely present rather than properly validated. CVE-2026-32057 covers an authentication bypass in the trusted-proxy Control UI pairing mechanism, where a client could claim the control-ui identity without correct device verification. The common root cause in these cases is straightforward: the system treated “appears internal” or “has some auth material” as equivalent to “has completed trustworthy identity binding.”
The second category is prompt injection and trust-boundary confusion. One of the clearest examples is CVE-2026-24764, in which Slack channel metadata such as topics or descriptions could be incorporated into the model’s system prompt. That widened the injection surface by allowing untrusted channel metadata to be interpreted as higher-trust control input. In practical terms, once multiple partially trusted or untrusted users, channels, or group chats are allowed to steer a tool-enabled agent, ordinary messages can stop being “just content” and start becoming effective control instructions. That is especially dangerous in an agent that can invoke tools, read secrets, or act on the host system.
The third category is command execution and sandbox failure, which is arguably the most dangerous layer because it moves the impact from “the model was manipulated” to “the host system can be compromised.” CVE-2026-24763 describes command injection in OpenClaw’s Docker sandbox execution mechanism due to unsafe handling of the PATH environment variable. CVE-2026-25157 describes remote code execution through SSH command injection. Beyond those CVEs, OpenClaw’s own security materials also warn that safeBins is not a generic allowlist and that interpreters or runtime binaries should not be trusted casually, because that can undermine approval and execution controls. In other words, once shell execution or remote command paths are exposed, weak validation can turn agent mistakes into system-level compromise.
The fourth category is file disclosure, path handling, and data exfiltration. Public advisories have shown that MEDIA: directives could cause OpenClaw to stage and send arbitrary local files that were readable by the OpenClaw process. Another advisory explains that a malicious or compromised MCP tool server could exfiltrate arbitrary local files by injecting MEDIA: directives into tool result text. Additional file-handling advisories have described sensitive-file disclosure through attachment-path metadata and similar staging paths. These cases matter because they show that file access is not a secondary feature in an AI agent; it is a high-impact privilege boundary. Once that boundary is crossed, the likely outcome is not merely inconvenience, but leakage of secrets, chat history, documents, credentials, or other sensitive local data.
The fifth category involves webhooks, remote fetching, and plugin or skill supply-chain risk. Public advisories show that Telegram webhook configurations could accept forged updates when secrets were not correctly validated, while the optional BlueBubbles plugin had webhook authentication weaknesses, including a passwordless fallback path or trust assumptions based on loopback/proxy conditions. OpenClaw advisories have also documented SSRF-style issues in image or attachment fetching, media URL hydration, citation redirect resolution, and redirect-chain validation for allowlisted media targets. On top of that, CNCERT specifically warned that multiple OpenClaw-compatible skills had already been identified as malicious or potentially dangerous, with the ability to steal keys or install backdoors. This is a reminder that external integration points do not merely extend functionality; they also import risk directly into the agent’s core trust boundary.
Taken together, these disclosures support a clear risk conclusion. The five most dangerous deployment mistakes are: running OpenClaw as a shared system for users who do not fully trust one another, exposing the management or control interface to the public internet, installing untrusted skills, granting the agent excessive host privileges, and storing API keys or secrets in plaintext. This conclusion aligns closely with OpenClaw’s own security guidance and with CNCERT’s public warning.
From a practical defense standpoint, the mitigation priorities are also clear. First, upgrade to the latest patched release and keep monitoring the OpenClaw security advisory feed. Second, do not expose the web interface or management ports directly to the internet; OpenClaw’s official guidance states that the web interface is intended for local use only. Third, enforce least privilege and isolate the runtime in a container or virtual machine instead of running it broadly on a privileged host account. Fourth, do not allow mutually untrusted users to share a single gateway; separate trust boundaries should mean separate gateways, and ideally separate OS users or hosts. Fifth, tightly control skill sources, prefer only trusted and auditable plugins, and disable or limit risky update paths where appropriate. Finally, use the built-in openclaw security audit tooling, which is specifically designed to detect dangerous configuration flags, insecure trust-proxy setups, safeBins mistakes, and other common security foot-guns.
OpenClaw – A Complete Clean Reinstall of OpenClaw and Telegram Bot Reset Guide
A Complete Clean Reinstall of OpenClaw and Telegram Bot Reset Guide
First, remove OpenClaw completely together with its service, state directory, and workspace, then delete the old Telegram bot, and finally reinstall everything and create a brand-new bot.
OpenClaw already provides a built-in uninstall flow. The openclaw uninstall command removes the gateway service and local data. If you want the removal to be as thorough as possible, the official documentation also recommends deleting the state directory, the workspace, and removing the CLI itself according to the way you originally installed it.
1. Completely Remove “OpenClaw”
The most recommended way to do a clean reinstall
Start with:
openclaw uninstall --all --yes --non-interactive
This is the official non-interactive full uninstall command. It removes the service, state, workspace, and related local content. However, whether the CLI executable itself is still present depends on how you originally installed it.
Then remove the CLI as well:
npm rm -g openclaw
If you installed it with pnpm or bun instead of npm, use one of these instead:
pnpm remove -g openclaw
# or
bun remove -g openclaw
The OpenClaw documentation is very clear on this point: the standard installation from install.sh or install.ps1 uses a global npm installation by default, so the corresponding uninstall command is npm rm -g openclaw.
If you want to manually verify that everything is gone
You can also check and remove these paths manually:
echo "$HOME"echo "$OPENCLAW_STATE_DIR"Common result:HOME prints something like /Users/yourname or /home/yournameOPENCLAW_STATE_DIR is blankThat is normal. In that case, the command will delete:~/.openclawSo you can also run this directly:rm -rf ~/.openclaw
rm -rf "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}" rm -rf ~/.openclaw/workspace
According to the OpenClaw documentation, the default state directory is ~/.openclaw, and the default workspace is ~/.openclaw/workspace. Sessions, configuration, credentials, logs, and other data are also stored under this state directory.
If you previously used profiles, remove those profile directories too:
rm -rf ~/.openclaw-*
The official documentation states that profiles are stored by default under paths like ~/.openclaw-<profile>.
If you are on macOS, make sure no background service is left behind
If the openclaw command is already gone but the background service is still running, the official manual cleanup commands for launchd are:
UIDmeans your user ID on macOS or Linux.echo $UID
launchctl bootout gui/$UID/ai.openclaw.gateway
rm -f ~/Library/LaunchAgents/ai.openclaw.gateway.plist
These are the default macOS service label and plist location.
If you installed the Mac app, you can also remove it with:
rm -rf /Applications/OpenClaw.app
This is also listed separately in the official uninstall steps.
If you originally ran it from a git clone
In that case, first uninstall the service, then delete the repository directory directly. The official guidance for a source checkout is: uninstall the service first, then remove the repo, and then remove the state directory and workspace.
2. Delete the Old Telegram Bot and Create a New One
If you suspect the old bot is problematic, that is a reasonable approach. Telegram’s official BotFather supports the following commands:
/newbot: create a new bot- name -> username
- /token -> username
/token: generate a new token for an existing bot/deletebot: permanently delete the old bot; the username will be released, and the action is irreversible- username -> Yes, I am totally sure.
Steps to create a new bot
Go to @BotFather in Telegram and run:
/newbot
BotFather will ask for two things:
- Bot name: the display name, which can be anything
- Bot username: must be 5–32 characters, can only contain Latin letters, numbers, and underscores, and must end in
bot, for examplemy_openclaw_bot
The username cannot be changed later. Once creation succeeds, BotFather will give you a token.
If you want to completely retire the old bot, run this in BotFather:
/deletebot
If you only suspect the token was leaked but want to keep the same bot, run:
/token
This will generate a new token.
3. Reinstall a Fresh Copy of OpenClaw
The officially recommended installation command is:
curl -fsSL https://openclaw.ai/install.sh | bash
This installer automatically checks your system, installs the required Node version, and installs OpenClaw. Node 24 is the recommended version, while Node 22.16+ is also supported.
After installation, the onboarding flow recommended in the official FAQ is:
openclaw onboard --install-daemon
This installs the daemon or service as part of the setup.
4. Connect the New Bot Back to OpenClaw
The official OpenClaw configuration method for Telegram is to put the token into the configuration or environment variables, then start the gateway. Telegram does not use openclaw channels login telegram.
The simplest base configuration looks like this:
{
"channels": {
"telegram": {
"enabled": true,
"botToken": "123456:ABC...",
"dmPolicy": "pairing",
"groups": {
"*": { "requireMention": true }
}
}
}
}
This is the minimal working example from the official documentation.
You can also do it through the CLI:
openclaw channels add --channel telegram --account default --name "My Telegram Bot" --token 'your-new-token'
The OpenClaw CLI reference includes an example using channels add --channel telegram ... --token ....
Then start the gateway and pair the bot:
bot -> /start -> pairing code
openclaw gateway
openclaw pairing list telegram
openclaw pairing approve telegram <pairing-code>
The default Telegram DM policy is pairing. After the first private chat, you need to approve the pairing code, and the code expires after 1 hour.
5. If You Want the Bot to Work in Groups, Do These Too
If you want the new bot to work properly in group chats, both Telegram’s official guidance and the OpenClaw documentation highlight two important things:
Allow the bot to be added to groups
In BotFather, enable:
/setjoingroupschoose a bot -> enable
Make sure the bot can see group messages
Bots have Privacy Mode enabled by default. If you want the bot to see ordinary group messages, you have two options:
-
turn off privacy mode with
/setprivacy -> Disable,or make the bot a group administrator directly (*)
After changing privacy mode, remove the bot from the group and add it back again. Telegram only applies the new setting after the bot is re-added.
If you only want the bot to respond when someone mentions @bot, you can keep Privacy Mode enabled and set requireMention: true in the configuration. That is also the default example shown in the OpenClaw documentation.
vi ~/.openclaw/openclaw.json
@userinfobot -> /start
ID: 12345
{
"commands": {
"allowFrom": {
"telegram": ["user id", "user id 2"]
}
},
"channels": {
"telegram": {
"name": "My Telegram Bot",
"enabled": true,
"dmPolicy": "allowlist",
"allowFrom": ["user id", "user id 2"],
"botToken": "BotFather token",
"groupPolicy": "open",
"groupAllowFrom": ["user id", "user id 2"],
"groups": {
"*": {
"requireMention": false
}
},
"streaming": "partial"
}
}
}
Subscribe to:
Posts (Atom)