OpenClaw's Security Inflection Point: CVE-2026-25253, ClawHavoc, and What AWS Just Multiplied

Commissioned, Curated and Published by Russ. Researched and written with AI.

What’s New

AWS launched managed OpenClaw on Lightsail on March 6, 2026. The timing – six weeks after CVE-2026-25253 disclosure and four weeks into the ClawHavoc malicious skills campaign – makes this post immediately relevant to anyone deploying or running OpenClaw in production. The three developments are covered below in full.

Changelog

Three things happened to OpenClaw in February and March 2026 that, taken separately, look like manageable issues. A CVE gets patched. A marketplace has some bad packages. A cloud provider ships a managed offering. Each one has a playbook. Together, they describe something more specific: a security inflection point for AI agent tooling, at the moment when enterprise adoption is accelerating fastest.

If you’re running OpenClaw, or evaluating whether to, this is the post you need to read.

CVE-2026-25253: “Local” is Not a Security Boundary

The vulnerability was disclosed on February 1, 2026. CVSS score 8.8, high severity. It affects all OpenClaw versions before 2026.1.29. The fix shipped in v2026.1.29 on January 30.

The mechanism is Cross-Site WebSocket Hijacking (CSWSH), and it’s worth understanding precisely because it breaks an assumption that a lot of engineers hold.

OpenClaw runs locally – typically on your laptop or a private server. The Control UI trusts a gatewayUrl parameter from the query string without validation, and auto-connects on load, sending the stored gateway token in the WebSocket connection payload. That token arrives at whatever URL is specified. If that URL is attacker-controlled, the token is now theirs.

The attack chain looks like this: victim clicks a crafted link (in an email, a Slack message, anywhere) – the malicious page loads – JavaScript silently extracts the stored gateway token – that token is sent to the attacker’s server – the attacker uses it to open a WebSocket to ws://localhost:18789 – they now have operator.admin scope.

The critical point: the instance doesn’t need to be internet-exposed for this to work. The victim’s own browser is the pivot. The malicious site never touches localhost directly; it asks the browser to do it, and the browser obeys because WebSocket connections bypass the CORS restrictions that protect HTTP requests.

runZero’s scan found 17,500+ publicly exposed OpenClaw instances as of their scan window. SecurityScorecard found 42,900 public-facing instances across 82 countries, with 15,200 confirmed vulnerable to RCE. But the internet-exposure number understates the real attack surface – every OpenClaw user who hasn’t patched is one malicious link click away from compromise, regardless of network topology.

This is a class of vulnerability you’ll see more of as local AI tooling proliferates. Applications that run locally and communicate over WebSocket with a browser-based UI have an inherent CSWSH surface. The “it’s only local” framing does not protect against an attack that routes through the browser. Related: privilege separation in agent pipelines.

Patch status: v2026.1.29 closes it. If you’re not on that version or later, stop and update now.

ClawHavoc: AI Agent Marketplaces Are the New npm

While CVE-2026-25253 was being patched, a second threat was already active.

The ClawHavoc campaign – named by Repello AI – started January 27, 2026, and surged January 31. The actor “Sakaen736jih” was submitting new malicious skills to ClawHub (OpenClaw’s skill registry) every few minutes during peak activity in early February. By the time Bitdefender published their analysis, roughly 900 packages out of ~4,500 total ClawHub packages were malicious. That’s approximately 20% of the marketplace. Antiy CERT’s numbers are higher: 1,184 confirmed malicious skills out of 10,700+ total.

The payloads are what you’d expect from a financially motivated campaign: backdoors, credential theft, crypto-focused stealers. 54% of the malicious skills specifically target crypto credentials – the fastest path from skill installation to monetizable access. OpenClaw inventor Peter Steinberger turned to VirusTotal for help on February 9, which gives a sense of the scale of the problem. Bitdefender subsequently released a free AI Skills Checker tool at bitdefender.com/en-us/consumer/ai-skills-checker.

The trust laundering technique is borrowed directly from npm supply chain attacks: compromised legitimate GitHub accounts are used to publish malicious skills, giving them apparent provenance and review history. A skill submitted from an account with years of activity and prior contributions reads as more trustworthy than one from a new account. It isn’t, if the account was taken over last week.

The comparison to npm is instructive but incomplete, because the stakes are higher. A malicious npm package running in a Node.js process has to work to escalate privilege. A malicious OpenClaw skill is installed into a system that already has operator.admin scope, direct filesystem access, environment variable access, and the ability to invoke shell commands. The privilege escalation is built in. Related: supply chain and compromised tooling.

AWS Lightsail: Scaling the Attack Surface

On March 6, 2026, AWS launched managed OpenClaw on Amazon Lightsail. One-click deployment. Amazon Bedrock preconfigured with Claude Sonnet 4.6. IAM role creation automated via CloudShell. Browser pairing via SSH credentials. The full OpenClaw stack, ready to run, accessible to anyone with an AWS account.

AWS cited customer demand and configuration complexity as the driver. OpenClaw has 250,000 GitHub stars. It’s the most-starred non-aggregator software project on GitHub, ahead of Linux and React. The demand is real.

The timing is the problem.

Managed deployments change the user population. Self-hosted early adopters running OpenClaw on their own infrastructure tend to have read the security advisories, understand what they’re running, and have opinions about network exposure. The Lightsail user population includes all of that group plus everyone else – developers who want the product but not the infrastructure work, teams with no dedicated security function, enterprises where shadow IT means someone in engineering stood up a managed OpenClaw instance without security review.

A Token Security study found 22% of organizations already have employees running OpenClaw without IT approval. The Lightsail launch makes that number larger and the instances less likely to be patched or hardened.

This isn’t an argument against managed deployment as a category. It’s an observation about timing. Launching a managed product while a critical CVE is active and 20% of the marketplace is compromised means you’re lowering the barrier to deployment at exactly the moment when the risk of deployment is highest. The 98.6% of exposed instances running on cloud platforms (DigitalOcean, Alibaba, Tencent, AWS) rather than home networks confirms that this is already an enterprise and developer infrastructure problem, not a hobbyist one.

The Blast Radius

When an OpenClaw session is compromised – through CVE-2026-25253 or a malicious ClawHub skill – the attacker lands with operator.admin scope. That scope is not narrowly defined.

With operator.admin, an attacker can: disable the sandbox, reconfigure tool policies, read environment variables (which typically include API keys for Claude, OpenAI, and any other service the user has configured), write arbitrary files, and execute shell commands on the host. The blast radius of a single compromised instance on a developer machine is effectively full host compromise plus credential exfiltration for every service the developer has configured.

This is structurally different from most SaaS security incidents. When a SaaS service is compromised, the blast radius is bounded by what data that service holds. OpenClaw runs on the developer’s machine, with the developer’s credentials, touching the developer’s files, with access to every tool the developer has given it. The entire point of the product is broad, privileged access to local and remote systems. That’s also what makes a compromise so severe. Related: agent safety constraints and blast radius and credential theft cascade.

What to Do

The mitigation list is short and specific:

Update immediately. v2026.1.29 patches CVE-2026-25253. There’s no reason to run an older version.

Audit your ClawHub skills. Every community-sourced skill is a trust decision. Check the source repository, read the SKILL.md, review the actual tool calls the skill makes. Run anything uncertain through Bitdefender’s checker at bitdefender.com/en-us/consumer/ai-skills-checker. If you can’t verify it, don’t install it.

Prefer bundled skills over ClawHub community installs. The bundled skills that ship with OpenClaw have been reviewed by the maintainer. Community skills have not. The marginal convenience of a community skill is rarely worth the trust surface.

Don’t expose the gateway port. If OpenClaw’s gateway (default port 18789) is accessible over the network, it’s a target. Network isolation is the right default. The CSWSH vulnerability demonstrates that even local-only instances have attack surface, but internet-exposed instances have significantly more.

Treat OpenClaw sessions as privileged processes. Don’t run with elevated permissions unless the task requires it. Apply the same scrutiny you’d apply to any process with broad filesystem and network access.

If you’re deploying via Lightsail, read the security advisories before you deploy, not after. The one-click experience is designed to abstract away configuration – don’t let it abstract away security posture.

Infrastructure Has CVEs

OpenClaw is infrastructure. It runs on machines, manages credentials, executes code, and connects systems. The developers who have adopted it at scale have already made it infrastructure, whether or not their security practices reflect that.

CVE-2026-25253, ClawHavoc, and the AWS Lightsail launch didn’t create a new risk category – they exposed one that was already present. AI agent frameworks that run locally with broad system access, pull skills from community marketplaces, and get deployed at scale via managed cloud services have the same security lifecycle as any other infrastructure: CVEs, supply chain attacks, misconfiguration at scale.

The question isn’t whether your AI agent tooling has vulnerabilities. It does. The question is whether your security practice has caught up to the attack surface you’ve already deployed.