Malicious OpenClaw Skills: The Supply Chain Attack Targeting Mac Users

If you've spent any time in the JavaScript or Python ecosystem, you know about supply chain attacks. A malicious package gets uploaded to npm or PyPI with a name that looks legitimate, someone installs it, and suddenly their CI/CD pipeline is exfiltrating secrets to an attacker-controlled server. In September 2025, the npm ecosystem suffered a massive supply chain attack that compromised 18 widely used packages — including chalk and debug — with a combined 2.6 billion weekly downloads. CISA issued a formal advisory.

Now the same attack pattern has arrived in AI agent ecosystems. And this time, it's worse. Because unlike a bad npm package that typically runs in a build pipeline with limited scope, a malicious AI agent skill runs on your personal Mac, with access to your personal files, your browser history, your SSH keys, and your saved passwords.

I've been following this closely because I build Mac security software. What's happened with OpenClaw's ClawHub marketplace is a case study in what happens when a fast-growing ecosystem prioritizes openness over security — and why Mac users specifically need to pay attention.

What are OpenClaw skills?

OpenClaw (formerly known as Clawdbot and Moltbot) is an open-source AI assistant with over 180,000 GitHub stars. It runs locally on your Mac and can automate tasks, manage files, browse the web, and interact with dozens of services. I covered the broader security implications in my companion post on OpenClaw security.

Skills are what make OpenClaw extensible. They're plugins — community-contributed modules that give the agent new capabilities. Think of them like VS Code extensions or browser add-ons. A skill might let the agent interact with a specific API, parse a certain file format, or automate a workflow.

ClawHub is the public marketplace where these skills are published and distributed. Anyone can upload a skill. The only requirement to publish is a GitHub account that's at least one week old. There is no code signing, no mandatory security review, and no sandbox by default. The barrier to entry is a SKILL.md Markdown file.

If that sounds familiar, it should. It's the same openness model that has led to years of supply chain attacks on npm, PyPI, and the Chrome Web Store. The difference is that AI agent skills don't just run code — they run code through a trusted intermediary (the AI agent) that has broad system access and that users implicitly trust to act on their behalf.

The ClawHavoc campaign: what happened

In late January 2026, security researchers at Snyk audited 2,857 skills on ClawHub. What they found was alarming: 341 malicious skills, roughly 12% of the entire registry, were actively stealing user data.

The campaign, codenamed ClawHavoc by Koi Security, worked like this:

1. Attackers created skills with names that mimicked popular, legitimate skills
2. The skills contained a SKILL.md file with hidden instructions that exploited the AI agent as a trusted intermediary
3. When installed, 335 of these skills used fake "prerequisite" prompts to trick users into installing Atomic Stealer (AMOS), a well-known macOS infostealer
4. The remaining 6 skills used direct data harvesting techniques

The campaign window was tight — January 27-29, 2026 — but effective. All 335 AMOS-delivering skills shared a single command-and-control IP, and targeted data included exchange API keys, wallet private keys, SSH credentials, browser passwords, saved credit cards, and bot configuration files. The stealer variant could exfiltrate Apple Keychains, KeePass databases, and stored data from 19 different browsers.

By mid-February 2026, the problem had grown far beyond the initial audit. The number of confirmed malicious skills climbed to over 824 across an expanded registry of 10,700+ skills. Cyberpress reported the count reaching 1,184 malicious packages across 12 publisher accounts.

Snyk published a follow-up study called ToxicSkills, finding prompt injection in 36% of sampled skills and identifying 1,467 malicious payloads across the ClawHub ecosystem. They also published a detailed threat model showing how three lines of Markdown in a SKILL.md file could escalate to full shell access on a user's machine.

This is not a theoretical risk. This is a documented, active campaign targeting Mac users right now.

The supply chain problem in detail

The ClawHavoc campaign didn't succeed because of some sophisticated zero-day exploit. It succeeded because the supply chain model is fundamentally broken for AI agent skills. Here's why:

No mandatory security review

When you submit a skill to ClawHub, there is no automated security scan, no code review, and no sandboxed test environment. The skill goes live almost immediately. OpenClaw has since started integrating VirusTotal scanning, but this is reactive — it catches known malware signatures, not novel techniques or prompt injection payloads.

Compare this to npm, which processes over 4.4 million packages and has dealt with supply chain attacks for over a decade. npm at least has automated malware detection, package provenance attestation, and a security reporting pipeline. ClawHub launched without any of these foundational safeguards.

Name-squatting and typosquatting

Attackers register skill names that are slight misspellings or variations of popular, trusted skills. A user searching for "google-calendar" might install "gogle-calendar" or "google-calender" without noticing. This is the same technique that has plagued npm and PyPI for years — and it works reliably because people trust the search results of a marketplace they consider legitimate.

Post-install updates

Skills can be updated after installation. A skill that was clean when you installed it can receive an update with malicious code. The agent pulls updates without requiring you to re-review the skill. This is the most insidious vector because it defeats even careful manual review — the skill you vetted is not the skill you're running two weeks later.

Implicit trust model

Here's what makes AI agent supply chain attacks categorically different from npm or PyPI attacks. When you install an npm package, it runs in a Node.js process with limited scope. Your CI/CD pipeline might catch weird behavior. Your test suite might fail. There are layers of detection between installation and real damage.

When you install an AI agent skill, the agent trusts it immediately and completely. The skill runs with the full permissions of the agent — which, as I detailed in my OpenClaw security post, includes access to your Terminal, your files, your network, your messaging apps, and your email. There is no permission scoping. There is no sandbox. The agent treats every installed skill as fully trusted code.

Memory poisoning

Snyk's research revealed an attack vector that has no parallel in traditional package ecosystems: memory poisoning. OpenClaw uses memory files (SOUL.md and MEMORY.md) to persist context between sessions. Malicious skills can modify these files, permanently altering the AI's behavior. A poisoned memory file can instruct the agent to ignore security warnings, trust specific domains, or exfiltrate data on a schedule — even after the malicious skill itself has been removed. You've effectively backdoored your own AI assistant.

Real attack vectors targeting Mac users

Based on published research and the ClawHavoc post-mortems, here are the primary attack vectors being used against Mac users through malicious skills:

Data harvesting

The skill's stated purpose might be legitimate — formatting text, integrating with an API, managing files. But in the background, it silently reads sensitive data and exfiltrates it. Targets include ~/.ssh/ (SSH keys), ~/.cursor/mcp.json and similar config files that store API credentials, browser cookie databases, .env files, and Keychain data. The data gets sent to an external server during what looks like normal agent network traffic. Without outbound network monitoring, you'd never see it.

Persistence installation

A skill claims it needs a "setup step" and creates a LaunchAgent plist file during installation. This plist runs a background process on every boot — long after you've stopped using the skill. The process phones home, downloads additional payloads, or continuously exfiltrates data.

If you're not monitoring ~/Library/LaunchAgents/ and /Library/LaunchAgents/, you won't notice. macOS doesn't alert you when new LaunchAgents are created. I wrote a detailed breakdown of how LaunchAgent persistence works in hidden processes running on your Mac.

Credential theft through fake configuration

A skill requests API keys or credentials during a "configuration" step. The user (or the agent itself) provides them, believing it's required for the skill to function. The skill stores the credentials locally but also sends them to the attacker. Straiker's audit found 71 Claude Skills that were overtly malicious and 73 exhibiting high-risk behaviors, including an active agent-to-agent attack chain that instructed agents to store wallet private keys in plaintext.

Cross-server data exfiltration

When multiple MCP (Model Context Protocol) servers are connected to the same client — which is common in advanced OpenClaw setups — a malicious server can poison tool descriptions to access and exfiltrate data from other trusted servers. Your legitimate GitHub MCP integration might be leaking your private repos through a malicious skill you installed for something completely unrelated.

Why macOS doesn't catch this

I've written about macOS security extensively on this blog, including why Macs still need additional security in 2026. The core issue is that macOS security is perimeter-focused: Gatekeeper checks apps when they're first launched, XProtect scans for known malware signatures, TCC gates access to sensitive resources like camera, microphone, and contacts.

But skills don't trigger any of these defenses:

• No Gatekeeper check. Skills run within the agent's process. They aren't standalone executables, so Gatekeeper never inspects them.
• No TCC prompt. Skills inherit the agent's existing permissions. If you gave Terminal full disk access for the agent, every skill has full disk access too.
• Network traffic blends in. Outbound connections from a skill look identical to normal agent API calls. The system firewall only blocks incoming connections, not outgoing ones.
• File modifications are authorized. Skills write files using your user account's permissions. As far as macOS is concerned, you made those changes.

The result is that a malicious skill operates in a blind spot. It's not a separate app, it's not a recognized malware signature, and it's using permissions you already granted. macOS has no mechanism to distinguish a skill that's formatting your calendar from one that's sending your data to a server in another country.

How to protect yourself

There's no silver bullet here, but there are practical steps that significantly reduce your risk.

1. Audit every skill before installation

Read the source code. Skills are typically open source — the SKILL.md file and any associated scripts are visible on GitHub. Look for curl or wget commands that phone home, encoded strings (Base64 is a red flag), LaunchAgent plist creation, and any file reads targeting ~/.ssh/, Keychain, or browser data directories.

2. Check publisher history

A GitHub account created last week publishing a skill with a generic name is a red flag. Look at the publisher's commit history, other repositories, and overall profile age. The ClawHavoc campaign used accounts with minimal history.

3. Monitor network connections after installing new skills

After installing and running a new skill, check what connections are active:

lsof -i -P | grep ESTABLISHED

Connections to IPs you don't recognize — especially on non-standard ports — warrant investigation.

4. Check for new LaunchAgents

Before and after installing skills, diff your LaunchAgents directories:

ls -la ~/Library/LaunchAgents/
ls -la /Library/LaunchAgents/

Any new plist files that appeared during a skill installation are suspicious and should be inspected.

5. Audit file system changes

Use macOS's built-in fs_usage or third-party tools to monitor file system activity during skill execution. Pay attention to reads from sensitive directories and writes to system startup locations.

6. Use runtime monitoring

Manual checks only get you so far. This is what I built CoreLock for — continuous monitoring of processes, network connections, and system changes. When a skill spawns an unexpected child process, makes a connection to an unknown server, or creates a new LaunchAgent, CoreLock flags it in your scan results. The free tier gives you 3 scans per day, which is enough for before-and-after comparisons when you install new skills. If you're actively developing with AI agents, Pro gives you unlimited scans and real-time behavioral analysis.

The goal isn't to stop you from using skills. It's to make sure you know what they're doing.

What the industry needs to fix

The ClawHavoc campaign exposed systemic problems that no individual user can solve. The industry needs to address these at the platform level:

Mandatory skill signing and verification. Every skill should be cryptographically signed by its publisher, with verification on install. npm learned this lesson years ago with package provenance. AI agent marketplaces need to catch up.

Permission scoping. Skills should declare the permissions they need upfront — network access, file system paths, system modifications — and the agent should enforce those boundaries at runtime. A calendar skill has no business reading ~/.ssh/.

Sandboxed execution. Skills should run in isolated environments by default, with explicit permission escalation for system-level operations. Docker has proven that containerized execution doesn't have to be impractical.

Runtime behavioral monitoring. Marketplaces should monitor what skills actually do, not just what their SKILL.md claims they do. This is what CoreLock does at the OS level for individual Macs — the same principle needs to be applied at the ecosystem level.

Transparent disclosure. AI companies need to be upfront about the security model of their skill ecosystems. Users deserve to know that installing a skill means granting it unrestricted access to their system.

OpenClaw has started integrating VirusTotal scanning, which is a step in the right direction. But signature-based scanning catches yesterday's malware, not tomorrow's. The fundamental architecture — open registry, no sandboxing, implicit trust — needs to change.

The bottom line

Supply chain attacks are not new. What's new is the attack surface. AI agent skills combine the openness of npm with the system access of a root-level backdoor. The ClawHavoc campaign proved this isn't theoretical — over 800 malicious skills, active credential theft, macOS infostealers delivered through Markdown files.

If you're using OpenClaw or any AI agent with third-party skills, treat every new skill like you'd treat running a shell script from an untrusted source. Read the code. Check the publisher. Monitor what happens after installation. And make sure you have visibility into what's running on your Mac.

I wrote a broader guide to running OpenClaw safely on macOS that covers prompt injection, process monitoring, and permission management. If this post was the "what's happening," that post is the "what to do about it."

Your Mac is powerful. AI agents make it more powerful. But power without visibility is just risk. Know what's running on your machine.