OpenClaw Slack Security After ClawHavoc: What Your Team Needs to Know

What Happened

On February 14, 2026, security researcher Marta Kessler published a disclosure that shook the OpenClaw community. She'd identified 1,184 skills in the public OpenClaw Skills Registry that contained obfuscated code designed to exfiltrate data from connected workspaces. The vulnerability was assigned CVE-2026-25253, and the internet quickly named the incident "ClawHavoc."

Let's be blunt about what this means. If your team was running OpenClaw in Slack and had installed any of the affected skills, your bot may have been sending workspace data (messages, files, user information) to external servers. The exfiltration was subtle; it piggy-backed on legitimate API calls and used steganographic techniques to hide data in outbound image uploads.

That's bad. Really bad.

Which Skills Were Affected

The full list is in the ClawHavoc disclosure repository, but the high-level breakdown: 847 of the 1,184 skills were variations of popular legitimate skills with malicious payloads injected. The remaining 337 were entirely new skills designed to look useful (things like "slack-channel-summarizer" and "meeting-notes-pro") that were actually just data harvesting tools from the start.

Skills that were specifically targeting Slack deployments made up about 40% of the total, roughly 470 skills. This makes sense. Slack workspaces contain messages, files, credentials, API keys dropped in channels, customer data in support threads. For an attacker, a compromised Slack bot is a goldmine.

How It Worked

The attack exploited two things. First, OpenClaw's skills system trusts code that's installed locally. Once a skill is downloaded and placed in the skills directory, OpenClaw executes it with the same permissions as the core agent. There's no sandbox, no permission model, no capability restrictions. The skill can do anything OpenClaw can do.

Second, the Skills Registry had minimal vetting. Anyone could publish a skill by submitting a pull request, and the review process was overwhelmed. With over 6,000 skills in the registry by January 2026, the maintainers were approving hundreds per month with cursory reviews at best.

The malicious skills used several techniques to avoid detection:

• Base64-encoded payloads that decoded at runtime
• Time-delayed activation (the skill would behave normally for 72 hours before starting exfiltration)
• Conditional execution (only activated when the workspace had more than 50 users, avoiding small test environments)
• Data hidden in seemingly innocent outbound requests

What OpenClaw Did About It

To their credit, the OpenClaw team moved fast. Within 48 hours of Kessler's disclosure, they'd purged all flagged skills from the registry, published a scanner tool (openclaw audit --skills) that checks installed skills against the known-malicious list, and released OpenClaw 0.49.1 with a new skill verification system.

The verification system uses cryptographic signing. Skills published to the registry after February 16 are signed by their authors, and OpenClaw verifies signatures before execution. Skills without valid signatures generate a warning. In version 0.50 (expected April 2026), unsigned skills will be blocked by default.

But here's the thing. None of that helps retroactively. If data was exfiltrated before the disclosure, it's already gone. And the new signing system only protects against future registry-based attacks. It doesn't protect against other supply chain vectors.

What You Need to Do Right Now

1. Run the Audit

If you have OpenClaw connected to Slack, run the scanner immediately:

openclaw audit --skills --verbose

This checks every installed skill against the ClawHavoc database. It takes about 30 seconds. If it flags anything, remove the skill immediately and check your logs for signs of exfiltration (look for unexpected outbound HTTP requests to unfamiliar domains).

2. Update to 0.49.1 or Later

Versions before 0.49.1 don't have the signature verification system. Update. There's no good reason to run an older version at this point.

openclaw update
# or, if you installed via Docker:
docker pull openclaw/openclaw:latest

3. Rotate Your Slack Tokens

If the audit found any compromised skills, treat your Slack bot token and app token as compromised. Go to api.slack.com/apps, revoke the existing tokens, generate new ones, and update your OpenClaw configuration. This is annoying but necessary. A compromised token means someone could impersonate your bot.

4. Review Connected Integrations

OpenClaw connects to other services via OAuth. If your bot had connections to GitHub, Jira, Gmail, or other tools, review the OAuth grants. Revoke any you're not sure about and re-authorize. A malicious skill with access to your Gmail OAuth connection could have read your email. Think about that.

5. Audit Your Skills Going Forward

Don't install skills from the registry without reading the source code first. I know this is tedious. I know most people won't do it. But after ClawHavoc, you can't treat the registry as a trusted source. Read the code, understand what it does, or don't install it.

Better yet: write your own skills, or use only skills from authors you trust. For guidance on writing custom skills, check out our custom skills guide.

Why SlackClaw Wasn't Affected

SlackClaw users were completely unaffected by ClawHavoc. Zero exposure. Here's why.

SlackClaw doesn't use the public Skills Registry. Every skill available through SlackClaw has been reviewed, tested, and is maintained by the SlackClaw team. There's no mechanism for third-party skills to be installed without going through our review process. We run about 120 skills in total; compare that to the 6,000+ in the public registry.

Beyond that, each SlackClaw team runs on a dedicated, isolated server. Even if one customer's environment were somehow compromised, there's no lateral movement to other customers. That's not true for multi-tenant SaaS platforms where a vulnerability in one tenant can cascade.

We also run outbound traffic monitoring on every server. Any skill attempting to send data to an unauthorized external endpoint would be flagged and blocked before it left the network. The kind of steganographic exfiltration that ClawHavoc used wouldn't survive our egress filtering. Read more about our approach on the security page.

The Bigger Problem

ClawHavoc isn't just a bug. It's a structural problem with how AI agent frameworks handle extensibility. OpenClaw's skill system is powerful precisely because it's unrestricted; skills can call any API, read any file, execute any code. That power is exactly what makes it dangerous when trust is misplaced.

Other agent frameworks have similar issues. The pattern of "download code from the internet and run it with full permissions" is disturbingly common in the AI tooling space. ClawHavoc was the first major incident, but it won't be the last.

For Slack deployments specifically, the stakes are high. Your Slack workspace is probably the most information-dense system in your organization. Every conversation, every file share, every decision lives there. Connecting an AI agent to it means that agent has access to all of it. Choose carefully what code you let that agent run.

For a deeper look at best practices, see our article on OpenClaw security best practices for Slack admins. And if you want to remove the supply chain risk entirely, that's what SlackClaw is for.