OpenClaw has grown fast. Faster, arguably, than the security thinking around it.

The platform now has over 228,000 GitHub stars and a community producing daily guides, tutorials, and hardening advice. Some of that advice is excellent. Some of it is dangerously incomplete. The gap between the two is hard to see unless you're watching closely.

That is what this series is for. Each month, we synthesize what the OpenClaw community is actually learning about security and configuration: the incidents, the debates, the tools people are building, and the questions nobody has answered yet. We run Cora on OpenClaw ourselves. We have skin in this.

This first issue covers a dense February: a major supply chain attack, a critical vulnerability that was public before most users patched, over 42,000 exposed instances on insecure default settings, and a community actively working out what responsible operation looks like. We cover what happened, what people are converging on, what remains genuinely unsettled, and how to think about keeping a running instance secure over time.

You do not need to be a security expert to read this. Where we use technical terms, we explain them.

What Happened in February

February was an active month for OpenClaw security, and not in a reassuring way.

The month opened with researchers publishing data on over 42,000 publicly exposed OpenClaw instances running their default, out-of-the-box settings. The root cause, in almost every case, was the same: the gateway was configured to accept connections from any device on the internet, rather than only from the machine it was running on. Combined with no password protection, this meant anyone who found these instances could connect to them, issue commands, and access whatever data the agent had permission to touch. Most of the affected users did not know their instance was exposed. The defaults that make first-time setup easy are not the defaults that make ongoing operation safe.

On February 13, a coordinated supply chain attack compromised 341 skills on ClawHub, the community marketplace for OpenClaw add-ons. Adversa AI documented the attack in detail. The skills were silently modified after publication to steal credentials and leave a backdoor in any installation. This was not a theoretical risk. It happened, at scale, and the marketplace had no automated system to detect it. We cover the mechanics in the next section.

The other major event was a formally disclosed vulnerability tracked as CVE-2026-25253, rated near-maximum severity on the industry scale used to score these issues. The vulnerability allowed an attacker to send a victim a specially crafted link. When the victim clicked it while their OpenClaw instance was running, the attacker gained full remote access to that instance, with all the permissions the agent held. The OpenClaw team patched it quickly, but the vulnerability was publicly documented before most users had applied the fix.

Six formally recorded vulnerabilities have been disclosed against OpenClaw in 2026 alone. The project is young. The attack surface is actively being discovered.

Deep Dive: The ClawHub Supply Chain Attack

The February 13 supply chain attack is worth examining closely, because it reveals something important about how OpenClaw security actually works.

When you install a skill from ClawHub, you are not installing a limited plugin or a restricted app. You are adding code that runs with the same permissions as the agent itself. A skill can browse the web, execute commands, read and write files, call any API your agent is connected to, and change the agent's own settings. There is no sandbox. A skill is not a helper with limited access. It is code operating with the same authority as the agent.

The modified skills in the February attack exploited this directly. The injected code, hidden inside otherwise functional skills, ran automatically when the agent started. It scanned the agent's configuration folder for saved credentials and API keys, quietly sent copies of those to attacker-controlled servers, and added a new backdoor access token to the agent's settings. Skills that had been trusted for months became credential theft vectors on the next restart.

If you installed any ClawHub skills between early January and February 13 and have not reviewed them, that review is overdue. Signs that something may have happened: unexplained changes to your agent's settings, unfamiliar entries in its access logs, or credentials appearing to be used somewhere you did not authorize.

The harder lesson is structural. The marketplace has no automated scanning, no formal review process, and no trust signal that tells you whether a skill is safe. Until that changes, the only real defense is reading the code before you install anything, and treating an update to an existing skill the same way you'd treat installing it fresh. That is not practical for most people to do well, which is why this problem remains unsolved.

What the Community Is Converging On

Despite the difficult month, the community response has been serious. A clearer set of baseline practices has started to crystallize, drawn from the accumulated experience of people running OpenClaw in production and documenting what went wrong.

Use a dedicated machine, not your main computer. This is the recommendation that shows up in almost every serious guide. If your agent is compromised, you want the damage contained to hardware that only holds what that agent needs, not to the machine you use for everything else. Cloud servers from providers like DigitalOcean or Hetzner are common. A spare Mac Mini or Raspberry Pi 4 works well. Your primary laptop does not.

Lock the gateway to local-only access. The single highest-leverage configuration change you can make is ensuring the gateway only accepts connections from the machine it runs on, not from the broader internet. This one setting, if it had been the default, would have protected most of the 42,000 exposed instances. It is not the default. It has to be set explicitly.

Use Tailscale for remote access. If you need to reach your OpenClaw instance from other devices or locations, Tailscale is what the community has most broadly settled on. It creates a private, encrypted network between your devices, so your instance stays invisible to the public internet even while you can reach it remotely. No open ports, no public exposure. Some users hit DNS issues this month with certain configurations, but the approach remains the community standard for remote access.

Use a strong, unique password. The authentication token that protects your OpenClaw instance should be long, random, and stored somewhere safe, not in a file that also gets backed up to version control. Short or default tokens have appeared as contributing factors in multiple disclosed vulnerabilities.

Run it in a container if you're doing anything serious. Docker is a tool that isolates your OpenClaw instance inside its own controlled environment, limiting what it can access on the underlying machine even if it is compromised. Running without this isolation is fine for testing. For anything handling real business data or live credentials, the community has moved to treating containerization as standard, not optional. The specifics of how the container is configured matter significantly: a poorly configured container provides much weaker protection than it might appear.

Audit your configuration with SecureClaw. Adversa AI released SecureClaw as a free, open-source tool that checks your setup against 56 security criteria across five categories. Think of it as a health check that tells you what you have missed. Running it after initial setup, after any configuration change, and after installing any new skill has become the baseline expectation in serious community guides.

Prompt Injection: What We Know and Don't

Prompt injection is the security problem the OpenClaw community is most actively debating and has not solved. It deserves its own section because the threat is real, the current mitigations are partial, and a lot of the advice circulating overstates how much protection any single approach actually provides.

Here is the basic idea: an OpenClaw agent can read web pages, emails, documents, and messages as part of doing its job. Prompt injection is when an attacker hides instructions inside that content, designed to be read by the agent as commands rather than data. A web page that looks normal to a human might contain hidden text instructing the agent to forward credentials to an external server. A document being processed might contain text telling the agent to perform an action the user never intended. The agent, following instructions as it is designed to do, may comply.

This is hard to defend against because the same capability that makes an agent useful - reading content and acting on what it finds - is exactly what the attack exploits. You cannot simply tell the agent "ignore any instructions hidden in web content," because that is itself just text, and a sufficiently crafted attack can work around it.

What partial mitigations actually help: give the agent access only to the tools it genuinely needs for a given task. An agent that does not have the ability to run system commands cannot be tricked into running them through a malicious web page. Restricting tool access does not eliminate the problem but meaningfully reduces the surface area.

Requiring human approval before the agent takes any consequential action is the other mitigation with real traction. If the agent must ask before sending an email, making an API call, or writing to a file, a successful injection attack triggers a review before damage occurs. This only helps if the approval request is legible, which is not always the case, but it raises the bar significantly.

What the community is experimenting with but has not settled: using two separate agents in sequence, where one reads external content and can only summarize it, and a separate agent with elevated permissions receives only that summary and never directly touches external content. This reduces injection risk at the cost of complexity. No one is claiming it is fully production-ready yet.

The honest current state: scope your agent's tools tightly, require approval for consequential actions, and be skeptical of any guide that suggests a single setting solves this.

Overhead flat lay of a printed checklist on a warm desk, an orange pen making a checkmark, and a coffee mug in the corner

Keeping It Secure After Setup

The most common gap in OpenClaw security advice is treating security as a setup task. You harden the configuration, run a scan, and consider it done. That is not how secure operation actually works.

Stay current on patches. Six disclosed vulnerabilities in two months means the attack surface is actively being found. The OpenClaw project does not yet have a formal security mailing list, but the project's GitHub releases page, its official Discord, and a search alert for "OpenClaw" in the National Vulnerability Database together give you reasonable coverage. For high-severity issues, the community expectation has moved toward patching within 48 hours of a disclosure. Being more than one minor version behind on a project with this pace of security fixes is increasingly risky.

Review your logs periodically. OpenClaw keeps records of what your agent has done: what websites it visited, what commands it ran, what files it accessed. Reviewing those logs is how you catch anomalies that automated tools miss. An agent that suddenly started making network requests to an unfamiliar domain, or ran a command that was not part of any workflow you configured, is a signal worth investigating. Weekly review is the baseline most serious operators are settling on.

Keep your skill list current. Skills accumulate. An agent that has had a dozen skills installed over several months probably has several that are no longer actively used. Each installed skill is code running with agent-level permissions. Remove skills you are not using. When you update a skill, treat it as a new installation and review what changed.

Run your security audit on a schedule. SecureClaw is most useful as a regular check, not a one-time scan. Running it after every skill install or configuration change tells you if that change introduced a gap. Running it weekly as a baseline tells you if anything has drifted from the state you last verified.

Rotate your authentication credentials periodically. Access tokens should be changed on a regular schedule, and immediately after any personnel change that had access to them or any suspected compromise. This is easy to defer. Put it on a calendar.

What Is Still Contested

Two areas remain genuinely unsettled, where the community has real debate and no clear answer yet.

Running OpenClaw for a team. Almost all the hardening guidance in circulation is written for a single person running their own instance. The questions that come up when multiple people share the same agent, with different roles and different levels of trust, remain significantly less developed. How do you manage access? How do you audit who instructed the agent to do what? The community is producing more writing here, but it has not reached the quality and consensus of the single-operator playbook. If you are deploying OpenClaw for a team rather than an individual, you are in earlier territory and should expect to make more judgment calls.

Cloud versus self-hosted. The right answer here genuinely depends on your organization, and the conversation has not gotten simpler. Running your own instance gives you control over your data and eliminates provider trust dependencies. It also requires sustained operational attention. Cloud deployments handle that burden for you but introduce questions about what the provider can see and under what circumstances. Neither approach is categorically safer. The right choice depends on what your agents are doing, what data they touch, and whether your team has the capacity to maintain a self-hosted deployment responsibly over time. Anyone claiming one is categorically better is probably selling something.

The Baseline, As Best We Understand It

Based on what the community has worked out this month, here is where the bar sits for a defensible setup. This is a synthesis of what serious operators are actually doing, not a definitive list.

  • Gateway bound to loopback, not 0.0.0.0
  • Strong auth token, generated randomly, not left at default
  • DM and group policies set to allowlist or pairing
  • Running as a non-root user
  • Docker with hardened compose config (read-only fs, no-new-privileges, capabilities dropped)
  • No sensitive directories mounted into the container
  • Credential files at chmod 600, config directory at chmod 700
  • Secrets in .env, not in openclaw.json
  • Tool sandboxing enabled (sandbox.mode: all) where the workflow allows
  • Tailscale or authenticated reverse proxy for remote access
  • External-facing tools scoped to minimum necessary
  • Human approval required for irreversible external actions
  • SecureClaw audit run at setup, after every skill install, and weekly
  • Version v2026.1.29 or later (patches CVE-2026-25253)
  • Skills vetted before installation; updates treated as new installs
  • Unused skills removed
  • Logs reviewed weekly
  • Auth token rotated on schedule

This is the floor the community has converged on. The ceiling is still being built.

Where Cora Sits in This

We built Cora on OpenClaw, which means we think about this every day. We also run AI agents across our own organization, so we are not advising from theory.

Our security model reflects the lessons above, applied consistently. Every Cora deployment uses isolated identities with least-privilege access, starts with human approval required for all external-facing actions, and maintains a complete audit trail of everything the agent does. We track OpenClaw vulnerabilities and patch proactively. We vet every skill before it enters a customer environment. We run continuous automated audits. The full picture is on our security page.

What we have learned is that the security work is ongoing, not a setup task. It is the main reason most businesses should not try to self-host an agent for serious operations. Not because it is impossible, but because it demands sustained attention that tends to erode as other priorities compete for it. The incidents above happened to people who had gone through setup correctly.

If you are weighing your options, reach out at hello@cora.st. We will be honest about what makes sense for your situation.