Cline CLI 2.3.0 compromised — OpenClaw dropped via npm

We spotted this in our dev environment this morning. The scary part isn't just the malware; it's that OpenClaw is designed to operate autonomously. If it has access to git credentials, it could theoretically commit code or exfiltrate repos without human interaction.

We've temporarily blocked npmjs.com for non-prod environments until we scrub our dependencies. Strongly recommend checking your SBOMs if you use Cline.

From a SOC perspective, detecting this is tricky because the traffic looks like normal AI API calls at first glance. We're looking for large outbound data transfers to non-standard ports associated with OpenClaw's default configuration.

Also, run npm audit immediately, but remember that won't catch it if you already installed the malicious version and haven't updated yet.

This is exactly why we pin versions strictly and use --ignore-scripts when installing dev tools in CI/CD. While inconvenient, it stops scripts from running during npm install.

Anyone know if the attacker stole just the publish token or if they have broader access to the maintainer's account?

On the remediation side, we're advising teams to scrub the .npmrc for any lingering tokens, as these agents often target auth files. If you can't upgrade immediately, verify integrity by comparing the registry shasum:

npm view cline@2.3.0 dist.shasum

Compare that against your local file hash. Has anyone identified if the malware attempts to establish persistence beyond the node_modules directory?

Don't forget to rotate all exposed credentials, not just npm tokens. If OpenClaw operated with user permissions, it may have accessed cloud keys, API tokens, or SSH keys.

From an IAM perspective, implement just-in-time (JIT) access principles for dev tools. Using runtime behavioral monitoring tools like Falco or Sysdig can help detect when "benign" AI agents attempt unusual file operations or make unexpected network connections to non-whitelisted endpoints.

For those who installed the compromised version, assume lateral movement and rotate credentials across your development infrastructure, not just local machines.

Great insights on containment and rotation. Since OpenClaw operates autonomously, lateral movement is a real risk if not isolated. If you're still investigating potentially affected machines, I strongly suggest running dev tools inside a sandboxed environment like Firejail or a dedicated VM with strict egress rules.

This limits the blast radius if the agent activates before you fully patch. You can verify the package checksum quickly with:

npm view cline@2.3.0 dist.integrity

Compare that against your local lock file to ensure you haven't pulled the malicious version.

To strictly limit the blast radius, consider running untrusted CLIs in ephemeral containers with dropped capabilities. Even if OpenClaw executes, it can't access host credentials or socket files.

For example:

docker run --rm -it --network=none -v ${PWD}:/app node:18 sh -c "npm install && ..."

This network isolation stops exfiltration, while volume binding prevents host filesystem access. It's a bit more overhead, but it's safer than trusting a compromised package on a dev laptop with root access.

From a DLP standpoint, the immediate worry isn't just credential theft, but data exfiltration via the agent's context window. I strongly suggest auditing network logs for large JSON payloads to unknown IPs. If you run an enterprise DLP solution, temporarily tighten your data-in-motion policies to block any codebase content leaving the environment to non-whitelisted AI endpoints. It’s safer to over-block AI traffic temporarily than risk proprietary code leaking.