Back to Blog
SecurityFeb 17, 2026· 12 min read

We Love OpenClaw — Let's Make It Even More Secure Together

OpenClaw, Clawdbot, and Moltbot have seen tremendous success — and for good reason. Here's how Keychains.dev can help the community tackle credential security so everyone can keep building amazing things with confidence.

If you're using OpenClaw (formerly Clawdbot, briefly Moltbot), you're part of one of the most vibrant AI communities in the world. With over 200,000 GitHub stars and a rapidly growing ecosystem, OpenClaw has seen tremendous success — and we couldn't be happier about it. We love how it enables developers to unleash the real power of AI agents.

We have been wowed by how powerful Claude can be when run in such an environment, and so have hundreds of thousands of users worldwide. That said, as the ecosystem grows, so does the importance of keeping credentials safe. Recent security research has surfaced some credential security challenges — from plaintext key storage to browser-based credential exposure to supply-chain risks through malicious skills. These are real concerns that affect many default configurations, and we want to help the community address them.

What the community should be aware of (February 2026)

CVE-2026-25253 — WebSocket hijacking allows full gateway takeover and token theft via malicious websites

CVE-2026-24763, CVE-2026-25157 — Command injection through unsanitized inputs enables arbitrary code execution

135,000+ exposed OpenClaw instances found in internet-wide scans, 15,000+ vulnerable to RCE (SecurityScorecard)

341 malicious skills discovered in ClawHub, most bundling AMOS infostealer malware (Bitdefender, Koi Security)

22% of enterprise OpenClaw deployments are unauthorized shadow IT (Bitsight)

Five areas where credentials can be at risk

To understand the challenges, let's look at the specific areas where credentials can be exposed in OpenClaw deployments. These have been documented by independent security researchers and, in several cases, assigned CVE identifiers. Understanding them helps the whole community build more securely.

1

Plaintext credential storage

OpenClaw stores API keys, OAuth tokens, and other secrets in plaintext files at ~/.clawdbot. This includes active credentials and historical credentials in .bak files. The "SOUL.md" persistent memory file can also contain credentials injected through conversation history.

Impact: Any process with filesystem access — including malicious skills, compromised tools, or lateral movement from other exploits — can read all stored credentials. There is no encryption at rest, no access control, and no separation between credential storage and general configuration.

2

Browser-based credential theft (CVE-2026-25253)

Discovered by DepthFirst and detailed by ZeroPath, this vulnerability allows any website to connect to OpenClaw's gateway WebSocket on localhost and steal the authentication token. Once obtained, an attacker has full control of the agent — including the ability to execute commands, access files, and exfiltrate any credentials the agent can reach.

Impact: Visiting a single malicious webpage is enough to compromise all credentials accessible to your OpenClaw agent. The attack can hijack active sessions from services like Gmail and Microsoft 365, bypassing even two-factor authentication.

3

Malicious skills and supply-chain attacks

ClawHub, OpenClaw's skill marketplace, has been infiltrated by malicious actors. Bitdefender and Koi Security found 341 malicious skills, with 335 using fake prerequisites to install the Atomic Stealer (AMOS) malware. The "ClawHavoc" campaign delivered crypto-stealers to thousands of agents through seemingly legitimate, highly-rated skills.

Impact: Installing a popular-looking skill can compromise your entire system — credentials, crypto wallets, browser sessions, and more. Skills execute with the same privileges as the agent, with no sandboxing.

4

Prompt injection and memory poisoning

OpenClaw's SOUL.md persistent memory has no trust tiers, no expiration, and no integrity verification. Malicious instructions hidden in web pages, skill outputs, or conversation history persist indefinitely and can trigger time-delayed attacks — executing dangerous actions like exfiltrating files or installing backdoors during future interactions.

Impact: Even after patching other vulnerabilities, poisoned memory can reintroduce compromises. Detection is extremely difficult because the malicious behavior appears normal until triggered.

5

Exposed instances and authentication bypass

SecurityScorecard's STRIKE Team found 135,000+ exposed OpenClaw instances across 82 countries, with over 15,000 vulnerable to remote code execution. Many are deployed behind reverse proxies that inadvertently make all traffic appear as localhost — bypassing authentication entirely. Bitsight found that 22% of enterprise deployments are unauthorized shadow IT.

Impact: Anyone who finds your exposed instance has immediate, unauthenticated access to execute commands, read files, and steal every credential your agent has access to.

The common thread: credentials living in the agent

All of these challenges share a common thread: credentials exist in the agent's environment. They're stored in plaintext files the agent can read. They're present in the context window where prompt injection can reach them. They're accessible to skills that execute with the agent's privileges.

Patching individual CVEs is great, and the OpenClaw team has been responsive. But there's also an opportunity to address this at the architectural level. As long as credentials live alongside the agent, they remain at risk. This is why security researchers from Tenable, Palo Alto Networks, Kaspersky, and others are recommending architectural changes alongside patches — and we'd love to help make that easy.

A simple fix: keep credentials out of the agent

This is exactly what Keychains.dev does — and it's designed to complement OpenClaw, not replace it. Instead of storing credentials in the agent's environment, Keychains acts as a credential proxy. Your agent authenticates itself to Keychains using an SSH keypair (no credentials needed), and when it needs to call an API, the proxy injects the right credentials server-side.

The agent never sees, handles, or stores the actual secrets. They don't exist in its filesystem, its context window, its memory, or its environment variables. You keep everything you love about OpenClaw — the orchestration, the skills, the community — and just add a layer of credential safety on top.

Before (OpenClaw) → After (with Keychains)
# Before: credentials in the agent
GITHUB_TOKEN=ghp_R3aLs3cR3t... ← stored in ~/.clawdbot
# After: credentials never touch the agent
$ keychains curl https://api.github.com/user/repos \
-H "Authorization: Bearer {{GITHUB_TOKEN}}"
credentials injected server-side, never in agent memory

How Keychains addresses each challenge

How Keychains addresses each challenge
  • Plaintext storage: Eliminated. No credentials exist on the agent's filesystem. They're stored encrypted (AES-256-GCM) on the Keychains server and decrypted only in memory during the proxy request.
  • Browser-based theft: Eliminated. Even if the agent's gateway is compromised, there are no credentials to steal. The SSH keypair used for authentication is protected by stateful fingerprinting that detects stolen keys on first use.
  • Malicious skills: Mitigated. Skills cannot harvest credentials because no credentials are present in the agent's environment. The proxy enforces strict destination binding — an API key for GitHub can only be sent to GitHub's API, never to an attacker-controlled server.
  • Prompt injection: Eliminated for credential theft. Credentials never enter the agent's context window, so there is nothing for prompt injection to exfiltrate. The agent can still be manipulated to make API calls within approved scopes, but this is bounded and audited.
  • Exposed instances: Contained. Even if the agent is fully exposed, no API credentials are accessible. The agent authenticates to the Keychains proxy via SSH challenge-response, and the proxy requires user-approved permissions for each API scope.

For OpenClaw users: getting started is simple

The setup is designed to be as simple as possible — just two steps and you're up and running. You keep using OpenClaw for everything it's great at, and Keychains handles the credentials.

1

Ask your Clawbot to use Keychains for all API requests

Tell your Clawbot to use npx -y keychains curl as a drop-in replacement for curl every time curl is needed, and to replace all credentials with template placeholders such as XXX and YYY. For scripts that make requests to third-party API providers, ask it to use the keychains.dev SDK for Node.js, Python, Go, or Rust.

$ npx -y keychains curl https://api.github.com/user/repos \
-H "Authorization: Bearer XXX"
How it works: Your bot will receive a 403 response on the first request, along with a URL to forward to you for authorization. Once you've approved access, replaying the request will work seamlessly — no credentials ever touch the agent.
2

Install the Keychains skill from ClawHub

We've published a Keychains skill on ClawHub that teaches your Clawbot to automatically use Keychains whenever credentials are needed. Ask your Clawbot to download and install it, use it every time credentials are encountered, and please give it a star!

# Coming soon — ClawHub skill URL will be available here

What you get beyond security

Full audit trail

Every API call made through Keychains is logged — which agent, which API, which scope, when. A great complement to OpenClaw's built-in capabilities.

Instant revocation

Revoke any agent's access with one click from the dashboard. No need to rotate API keys across all your services.

User consent flow

Users approve each permission explicitly. They see what the agent wants to access and can approve or deny with one click. Full transparency.

What security researchers recommend

The security community has weighed in with helpful guidance. The Centre for Cybersecurity Belgium issued an advisory. The University of Toronto published a vulnerability notification. Kaspersky, Palo Alto Networks, Tenable, Bitsight, and Adversa AI all published detailed hardening guides. This kind of attention is actually a sign of how important OpenClaw has become — the community cares because the project matters.

The consistent recommendation across all of these: keep credentials out of the agent. Use proxy architectures. Enforce least privilege. Add audit trails. These are precisely the primitives Keychains was built to provide — as a complement to OpenClaw, not a replacement.

Building the future together

OpenClaw is a genuinely incredible agent framework. Its skill ecosystem, orchestration capabilities, and rapid development velocity are what make it the go-to choice for hundreds of thousands of developers worldwide. We're fans, and we want to see the community continue to thrive.

The architectural approach matters. Patches fix individual vulnerabilities — and the OpenClaw team has been doing great work there. Removing credentials from the agent eliminates the entire class of credential theft attacks — regardless of what future challenges emerge. It's a win-win.

If you're running OpenClaw and working with API credentials, we'd love to help you keep them safe. The two-step setup above takes just minutes, and you keep everything you love about OpenClaw exactly as it is.

Keep building amazing things with OpenClaw — securely

Get started in under 5 minutes. Keep using OpenClaw for everything it's great at, and let Keychains handle the credentials.