Responding to a Supply Chain Attack: The ClawHavoc Campaign

A real-world walkthrough of auditing my AI agent infrastructure against the ClawHavoc supply chain attack — and the unrelated kernel vulnerability I found and patched while I had the hood open.

Share

In February 2026, security researchers disclosed a coordinated supply chain attack against ClawHub, the skill marketplace for OpenClaw — the AI agent framework I use to run my homelab's automation. The campaign, dubbed ClawHavoc, planted somewhere between 341 and 900+ malicious skills designed to steal SSH credentials, crypto wallet keys, and browser passwords. On macOS, the payload was Atomic Stealer (AMOS). On Windows, a credential harvester. Both phoned home to the same command-and-control infrastructure.

I run four AI agents through OpenClaw on my homelab — Nyx, Prometheus, Ares, and Aegis — so this wasn't a theoretical risk. It was time for a full audit.

## Starting With the Attacker's Question

The first thing I needed to know: had I ever installed anything from the ClawHub marketplace itself? That's where the malicious skills lived.

I checked the actual install directory — `~/.openclaw/skills/` — where ClawHub registry installs land. It was empty. I'd never pulled a single skill from the marketplace. Every skill running on Nyx had been custom-built by hand or sourced directly from a verified upstream CLI tool, installed via Homebrew from known publishers.

I went through all seventeen active skills one at a time, tracing each one back to its source. Custom scripts I'd written myself. Verified package managers. Nothing from the compromised marketplace. Zero exposure.

There was a second vulnerability tied to the same disclosure — CVE-2026-25253, a one-click remote code execution flaw via WebSocket hijacking that could be exploited even against localhost connections, with a CVSS score of 8.8. The fix was simpler than the audit: update OpenClaw to the patched version and move on.

## The Real Problem Was Somewhere Else Entirely

While I was in the middle of that audit, I discovered Atlas — my actual homelab server — was completely unreachable. Not slow, not degraded. Zero response on any network path. A full power cycle was the only way back in.

Once it came back up, three containers had failed to restart cleanly: Grafana, qBittorrent, and one of my security monitoring tools. Grafana had hit a Go runtime panic from a boot-order race condition. qBittorrent's VPN container, Gluetun, had hit a similar timing issue. The third had a stale PID file left behind from the crash, buried inside Docker's overlay2 filesystem layer. I had to trace it down using `docker inspect` to find the exact upper directory, then manually delete the stale file before the container would start again.

All three came back clean after that.

## A Second, Unrelated Vulnerability Surfaces

While I had the hood open, I found something else worth fixing immediately: CVE-2026-31431, nicknamed "Copy Fail," a local privilege escalation vulnerability affecting every Linux kernel since 2017, actively being exploited in the wild at the time. It worked through the `algif_aead` kernel module.

The module wasn't loaded on Atlas, which meant I wasn't immediately vulnerable, but I wasn't taking chances. I wrote a modprobe block to disable it outright, then ran a full kernel upgrade — from 6.17.13-6-pve to 7.0.2-2-pve, the patched build. Proxmox itself got bumped to 9.1.9 in the same pass, which also happened to resolve a separate CERT-Bund XSS advisory I'd been tracking.

## What This Incident Reinforced

None of this happened because of a single mistake. It happened because I treat infrastructure security as an ongoing practice, not a one-time setup. The ClawHavoc audit took time precisely because I went skill-by-skill instead of assuming I was fine. The kernel patch happened because I was already in the system fixing something else and didn't want to leave a known exploit on the table, even an inactive one.

If you're running any kind of AI agent framework with a plugin or skill marketplace, the lesson is straightforward: know exactly where every piece of code in that ecosystem actually came from. "I don't remember installing that" is not an acceptable answer when credential theft is on the line.