Clinejection: When an AI Agent Becomes the Attack Surface

On February 17, 2026, someone published cline@2.3.0 to npm. The package contained a postinstall script that installed OpenClaw globally on every machine that downloaded it. The attack window lasted about eight hours. Roughly 4,000 developers were affected. The CLI binary itself was never modified.

The immediate damage was small. The attacker chose a benign payload. But the infrastructure that allowed the compromise would have permitted anything. A cryptominer. A credential harvester. A persistent backdoor in every development environment that ran npm install.

The incident earned a name: Clinejection. Security researcher Adnan Khan coined it. The name is apt, because what makes this attack significant is not the payload. It is the injection point.

The Entry Point Was an Issue Title

Cline uses an AI-powered issue triage bot. Claude reads incoming GitHub issues and categorizes them. Standard practice for open-source projects with high issue volume. One detail made this installation different from most: the workflow configuration gave the bot full Bash access and accepted input from any GitHub user.

Read that again. An AI agent with shell access, processing unsanitized input from the public internet. The allowedNonWriteUsers field was set to '*'. Every GitHub account holder on the planet had the ability to feed text to an agent that could execute arbitrary commands.

Cline’s own post-mortem states it plainly: “LLM shell access in CI contexts processing untrusted input is functionally equivalent to giving every GitHub user shell access.”

The attack required no exploit kit, no zero-day, no social engineering. It required a GitHub account and a carefully worded issue title. Khan’s disclosure confirmed this: the entire attack needed “no more than a GitHub account and knowledge of publicly documented techniques.”

Three Weaknesses, Composed

A single vulnerability is a bug. Three vulnerabilities that chain together are an architecture problem. Clinejection was three composed weaknesses, each one individually concerning, collectively devastating.

The first weakness was prompt injection. The issue triage bot accepted unsanitized GitHub issue titles as input. An attacker could craft a title that caused Claude to execute arbitrary npm commands. The bot would read the malicious title, interpret it as an instruction, and run whatever command the attacker embedded. No code review. No approval. The agent acted on untrusted input as though it were a trusted directive.

The second weakness was cache poisoning. GitHub Actions caches dependencies to speed up builds. The cache has a 10GB limit with least-recently-used eviction. The attacker flooded the cache past capacity, forcing eviction of legitimate entries, then planted poisoned node_modules entries using Cacheract, an open-source tool built for exactly this purpose. When Cline’s nightly release workflow restored cached dependencies, it pulled the attacker’s code.

This is not a novel technique. Cache poisoning in CI/CD is a known vector with published tooling. It was preventable with cache integrity verification. That verification did not exist.

The third weakness was credential scope. Cline’s nightly build pipeline and production publishing pipeline shared the same npm token. The token was bound to the package, not to the pipeline. Compromising the nightly workflow gave the attacker the ability to publish to production. There was no separation between “test” and “release.” One key opened both doors.

Each weakness in isolation would have been insufficient. Prompt injection without cache access leads nowhere productive. Cache poisoning without publishing credentials poisons only internal builds. Credentials without an entry point sit unused. The three composed into a complete attack chain: inject a command via an issue title, poison the dependency cache, then use the shared credentials to publish a compromised package to the world.

The Disclosure Failure

The technical failure was bad. The organizational response was worse.

Khan submitted a GitHub Security Advisory (GHSA) on January 1, 2026. On January 8, he sent a follow-up email. No response. On January 18, he sent a direct message to Cline’s CEO on X. Ignored.

Thirty-nine days of silence. Khan went public on February 9. Cline patched the vulnerability within 30 minutes of public disclosure. The fix that took 30 minutes had been waiting for 39 days behind an inbox nobody was reading.

Then it got worse. Cline announced credential rotation on February 10-11. The “rotated” npm token was not actually revoked. On February 17, eight days after Cline declared the issue resolved, someone used the un-revoked token to publish the compromised package.

Credential rotation without verification is theater. You announce the rotation. You check the box. You move on. The old credential remains active, waiting for someone to notice. Someone did.

The OpenClaw Irony

The payload the attacker installed was OpenClaw. If that name sounds familiar, it should.

We wrote about OpenClaw in February when a CloudBees VP confused it with Claude Code in a governance article. OpenClaw is an open-source personal AI assistant, originally named “Clawd,” renamed multiple times after Anthropic trademark pressure. In that article, we argued that the confusion between OpenClaw and Claude Code revealed how far the market was from understanding what it was trying to govern.

Now OpenClaw reappears, this time as the payload in a supply chain attack against an AI coding tool. An AI agent was exploited to compromise the build pipeline of another AI coding tool, which then distributed a third AI project to thousands of developers without their consent.

The governance deficit we identified in February is no longer theoretical. It has a CVE number and a body count of 4,000 compromised installations.

The “Low Impact” Framing Is Wrong

Cline’s post-mortem describes the impact as limited. The CLI binary was unmodified. The payload was benign. Only 4,000 downloads were affected during an eight-hour window.

This framing confuses outcome with exposure. The attacker chose a benign payload. Nothing in the infrastructure prevented a destructive one. The same attack chain, with the same entry points and the same credentials, could have delivered anything.

Evaluating a security incident by what the attacker chose to do, rather than what the attacker could have done, is like evaluating a bank vault by noting that the last person who walked through the open door only took a photograph. The door was open. That is the finding.

Chris Hughes of Zenity put it clearly: “When a single issue title can influence an automated build pipeline…the risk is no longer theoretical.”

What GitHub Got Right by Contrast

Compare this architecture to what GitHub shipped with Agentic Workflows. As we covered in Continuous AI, GitHub’s security model for AI agents in CI/CD follows a five-stage defense-in-depth pipeline. Pre-activation permission checks. Input sanitization. Read-only agent access (all writes buffered as artifacts). AI-powered threat detection on agent output. Permission-scoped write jobs that execute only after threat detection passes.

The core principle: the agent never gets write access.

Cline gave its issue triage bot full Bash access to a pipeline with production publishing credentials. GitHub’s architecture ensures the agent cannot write to anything, ever, under any circumstances. The difference is not sophistication. It is discipline. One team treated the AI agent as a trusted actor inside the security perimeter. The other treated it as untrusted input that must be contained.

The Cline incident validates GitHub’s architectural choices through failure. Every control GitHub implemented, Cline lacked.

The Compound Vulnerability Pattern

Clinejection reveals a threat model that security teams need to internalize. The threat is not a single vulnerability. It is the composition of mundane weaknesses into a complete attack chain.

Prompt injection is well documented. Cache poisoning has published tooling. Credential over-scoping is a known anti-pattern. None of these individually would merit a blog post. All three exist in thousands of CI/CD pipelines today, sitting quietly, waiting for someone to compose them.

This is the new attack surface that AI agents create in CI/CD. Every AI agent processing untrusted input is a potential injection point. Every shared credential is a lateral movement opportunity. Every unverified cache is a persistence mechanism. The question is not whether any single weakness exists. The question is whether the weaknesses compose.

Organizations running AI agents in their build pipelines should audit for composition, not individual vulnerabilities. Check the agent’s input sources. Check what the agent can access. Check whether the credentials available to the agent extend beyond what the agent needs. Then check whether those three answers, taken together, form a viable attack chain.

Principle of least privilege is not new advice. But AI agents make it urgent in a way that script-based automation did not. A bash script does what it is written to do. An AI agent does what it is told to do, and “told” now includes every piece of text the agent processes. An issue title is an instruction. A PR description is an instruction. A comment is an instruction. Any surface where untrusted text meets an AI agent with execution capability is a security boundary that most teams have not drawn.

What This Requires

The prescription is architectural, not procedural.

Isolate agent credentials. No agent should have access to production publishing tokens. Build pipelines and release pipelines should use separate credentials with separate scopes. If compromising one pipeline gives access to another, you have a credential architecture problem.

Treat agent input as untrusted. Every text field an AI agent reads is an attack vector. Issue titles, PR descriptions, comments, commit messages. Sanitize inputs before they reach the agent. Restrict the agent’s execution capabilities to the minimum required for its task. An issue triage bot needs to read issues and apply labels. It does not need Bash.

Verify cache integrity. Pin dependency hashes. Verify checksums on cache restoration. Do not trust that what you cached is what you get back. The tooling to poison CI caches is open source. Act accordingly.

Respond to security disclosures. Thirty-nine days of silence is not a communication failure. It is an organizational failure. If your project accepts external security reports, someone must read them. If nobody reads them, stop accepting them and let researchers publish immediately. Silence is the worst option.

Verify credential rotation. “Rotated” means nothing if the old credential still works. Test it. Confirm revocation. Then test it again. The eight-day window between Cline’s announced rotation and the actual exploitation is the cost of checking a box without checking the result.

The AI agent is the new perimeter. Secure it like one.

This analysis synthesizes Cline’s post-mortem on the unauthorized CLI npm publication (February 2026), Adnan Khan’s Clinejection disclosure (February 2026), GHSA-9ppg-jx86-fqw7 (February 2026), Snyk’s supply chain attack analysis (February 2026), and The Hacker News coverage (February 2026).

Victorino Group helps engineering organizations audit their CI/CD pipelines for the compound vulnerability patterns that AI agents introduce. Let’s talk.