- The Mess: OpenClaw versions before 2026.3.13 automatically loaded extensions from
.OpenClaw/extensions/without requiring explicit trust. A malicious extension could therefore execute code as soon as OpenClaw loaded it. - The Damage: An attacker who can place a crafted extension in the user’s OpenClaw directory can turn the agent into a local code-execution mechanism, potentially gaining the same privileges as the OpenClaw process.
- The Fix: Upgrade to 2026.3.13 or later and audit
.OpenClaw/extensions/for extensions you did not intentionally install.
AI agents are supposed to follow instructions.
Apparently, OpenClaw was also willing to follow code it never explicitly trusted.
That’s the problem behind CVE-2026-32920.
The vulnerability is brutally simple:
put a malicious extension in the right directory → OpenClaw loads it → code runs.
No confirmation dialog.
No trust decision.
No explicit installation step.
The Directory Was Enough
OpenClaw supports extensions that expand what the agent can do.
The problem was how those extensions were discovered.
Before version 2026.3.13, OpenClaw automatically loaded extensions placed in the .OpenClaw/extensions/ directory.
The application didn’t require an explicit trust decision for each extension.
That turns a local filesystem location into an execution boundary.
And execution boundaries are exactly where security teams don’t want implicit trust.
The Attacker Doesn’t Need to Modify OpenClaw
This isn’t an attack against the OpenClaw binary itself.
The attacker needs to get a malicious extension onto the victim’s machine.
That could potentially happen through another compromised application, a malicious repository, a supply-chain attack or another local file-write primitive.
Once the extension lands in the expected directory, OpenClaw can load it automatically.
The extension becomes code executed by the agent.
This Is a Supply-Chain Problem
The dangerous pattern looks familiar:
untrusted content → extension directory → automatic loading → code execution
It’s the same class of problem that keeps appearing in developer tooling.
Editors.
IDE plugins.
Browser extensions.
AI agents.
Package managers.
The software itself may be legitimate.
The malicious component arrives through the ecosystem around it.
AI Agents Make Plugins More Interesting
OpenClaw isn’t just a conventional desktop application.
It’s an agent with access to tools and integrations.
That means an extension can potentially expand what the agent is capable of doing.
The attacker isn’t necessarily interested in OpenClaw itself.
They’re interested in the permissions OpenClaw already has.
If the agent can access files, execute commands, interact with messaging services or use credentials, malicious extension code inherits a valuable position.
The Trust Model Was Backwards
A secure extension model should generally look like:
unknown extension → blocked
Then:
user explicitly approves → loaded
OpenClaw’s vulnerable behavior effectively looked like:
extension appears in the directory → loaded
That’s convenient.
It’s also dangerous.
Automatic discovery is great for usability.
Automatic execution is another story.
Why This Matters on Developer Machines
OpenClaw is likely to be used in environments where sensitive information already exists.
Developer systems can contain:
- SSH keys
- API tokens
- cloud credentials
- GitHub credentials
- source code
.envfiles- browser sessions
If malicious code executes with the same privileges as the agent, the extension doesn’t need to exploit another vulnerability.
It can simply use what the process can already access.
That’s the ugly advantage of local code execution.
The Fix Changes the Trust Boundary
The issue was fixed in OpenClaw 2026.3.13.
The patched behavior requires explicit trust for extensions instead of silently loading them from the discovery directory.
That is a much better model.
The application now asks a basic security question:
“Did you actually intend to run this?”
That question should have existed from the beginning.
Check Your Extensions
If you’re running OpenClaw, don’t stop at upgrading.
Look inside:
.OpenClaw/extensions/
Remove anything you don’t recognize.
Review recently added files.
Check where extensions came from.
And don’t blindly copy extension directories between machines.
A convenient AI extension can have considerably more power than a normal browser plugin.
The Bigger AI Problem
AI agents are becoming modular.
They can load:
- plugins
- skills
- tools
- MCP servers
- integrations
- extensions
That’s useful.
It also creates an enormous supply-chain attack surface.
An attacker doesn’t always need to compromise the model.
They can compromise something the model trusts.
Then the agent does the rest.
Bugstoday Opinion
This is the AI version of the oldest software-security mistake:
“If it’s in the right directory, it must be safe.”
No.
A filename isn’t a trust decision.
A directory isn’t a security boundary.
And an extension certainly isn’t trustworthy just because the application found it.
OpenClaw fixed the problem, but the lesson applies far beyond OpenClaw.
Every AI agent that automatically discovers and executes third-party components is building a miniature software supply chain inside the user’s machine.
Bugstoday verdict: AI agents don’t need to be jailbroken if attackers can simply become one of their extensions.
Today’s Bugs. Tomorrow’s Breaches.
