Cline CLI npm Breach: What Happened and What to Do

Cline CLI npm token was compromised and used to publish v2.3.0 with an unauthorized postinstall script. The payload was benign, but the incident exposes a critical CI/CD vulnerability involving AI agents with shell access.

Cline CLI npm Breach: What Happened and What to Do

TL;DR

  • Cline CLI npm package v2.3.0 was published with an unauthorized postinstall script on Feb 17
  • The payload was benign (installed openclaw, a legitimate open source tool), but credentials were compromised
  • If you're on v2.3.0, update to 2.4.0+ and uninstall openclaw. VS Code and JetBrains extensions were not affected.

What Dropped

On February 17 at 3:26 AM PT, an attacker used a compromised npm publish token to release cline@2.3.0 with a single unauthorized change: a postinstall script that globally installs openclaw. The CLI binary itself was untouched—byte-identical to the previous release. By 11:23 AM, Cline published v2.4.0, deprecated 2.3.0, and revoked the token. Exposure window: roughly 8 hours.

The Dev Angle

The root cause is a textbook CI/CD failure. In December, Cline added a GitHub Actions workflow to auto-triage issues using claude-code-action with shell access and no restrictions on who could trigger it. An attacker crafted a malicious issue title that injected commands into Claude's prompt, gaining code execution on the runner. From there, they exploited GitHub Actions cache poisoning—a lesser-known attack where an attacker floods the cache to evict legitimate entries, then plants poisoned ones. When Cline's nightly release workflow ran, it restored the poisoned cache and exposed the npm token.

Security researcher Adnan Khan reported the vulnerability on January 1. Cline didn't act until Khan publicly disclosed it on February 9. Within 30 minutes, they rotated VS Code and JetBrains credentials—but fumbled the npm token rotation. The wrong token was deleted; the exposed one stayed active. They verified rotation through npm's dashboard, which showed zero tokens, but the exposed token wasn't surfaced in that view. Six days later, someone used it.

The payload itself was harmless: openclaw is a real, non-malicious open source project. No CLI binary was modified, no user data was accessed. But the fact that publication credentials were compromised at all is the real story here.

Should You Care?

If you use the Cline VS Code extension or JetBrains plugin: No action needed. Those distribution channels were never compromised.

If you use the Cline CLI via npm: Check your version with cline --version. If you're on 2.3.0, run:

npm install -g cline@latest
npm uninstall -g openclaw

Versions 2.4.0 and above now use OIDC provenance attestations, meaning every published version is cryptographically linked to a specific GitHub Actions workflow run and source commit. Long-lived npm tokens are gone.

Cline audited all releases across all four distribution channels (VS Code Marketplace, OpenVSX, npm, JetBrains) during the full exposure window (December 21 through February 17). Every authorized version traces back to a verified workflow run or git commit. No other unauthorized releases were found.

What's Changing

Cline has already removed the AI-powered triage workflows entirely—any future automation will be read-only with no shell access. They've eliminated GitHub Actions cache usage from credential-handling workflows and rotated all publication credentials. They're also establishing a formal vulnerability disclosure process with defined SLAs and working with third-party security firms to audit their CI/CD infrastructure.

The broader lesson here: AI agents with broad tool access create new attack surfaces. Giving an LLM shell access in a CI context where it processes untrusted input is functionally equivalent to giving every GitHub user shell access. The individual techniques (prompt injection, cache poisoning, credential theft) aren't new, but the combination is, and the industry is still learning to defend against it.

Source: Cline