Clinejection: How One GitHub Issue Title Turned into a Supply Chain Incident

What Actually Happened

On February 17, 2026, cline@2.3.0 was published to npm with a modified postinstall lifecycle script:

"postinstall": "npm install -g openclaw@latest"

Cline’s GitHub advisory states:

  • affected version: 2.3.0
  • fixed versions: >=2.4.0
  • exposure window: about 8 hours (from 3:26 AM PT to 11:30 AM PT on February 17, 2026)

During that window, installations of cline@2.3.0 also installed openclaw globally without user intent. Public reporting and vendor telemetry estimated about 4,000 downloads before deprecation.

The crucial detail: Cline reported that package contents were otherwise effectively unchanged from the prior good release, with the main malicious difference living in packaging script behavior rather than core CLI logic.

The Attack Chain, Step by Step

The incident called “Clinejection” is best understood as a composed exploit chain. Each step is known in isolation, but chaining them through AI-enabled CI created the impact.

Step 1: Prompt Injection Through Issue Metadata

A GitHub issue title carried hidden instruction payload text.
An AI triage workflow consumed issue text and treated that payload as executable intent.

In other words, issue content crossed directly into a high-trust execution context.

Step 2: Workflow-Level Code Execution

The AI automation executed attacker-directed install behavior.
That allowed retrieval and execution of attacker-controlled dependency and shell logic.

This is the transition point from “prompt manipulation” to “actual runtime compromise.”

Step 3: GitHub Actions Cache Poisoning

The exploit chain reportedly used CI cache behavior and eviction pressure to displace legitimate cache entries and plant crafted cache material aligned to release workflow expectations.

Cache layers are frequently treated as performance plumbing. In this chain, cache became a control plane attack surface.

Step 4: Release Credential Exfiltration

When a credential-bearing publish workflow consumed compromised material, release secrets were exposed.
That enabled unauthorized publish rights on npm.

At this stage the attacker no longer needed prompt injection. They owned a signing/publish path.

Step 5: Unauthorized Publish with Install-Time Side Effects

Using stolen publish capability, cline@2.3.0 was released with the postinstall hook that globally installed another tool.

This was a supply chain trust break:

  • users requested package A
  • install process silently introduced package B
  • behavior ran with user-level machine permissions during routine install flows

Why This Incident Was Different

Supply chain incidents are common. What made this one unusually important is the recursive agent behavior:

  • an AI-assisted developer tool was compromised,
  • to automatically install another AI-capable tool,
  • through normal dependency lifecycle mechanics,
  • without interactive user consent prompts.

Even if the secondary payload is framed as non-malicious, the mechanism demonstrates a transferable pattern for future attacks with less benign payloads.

Public Timeline (Condensed)

Based on Cline’s post-mortem and related disclosures:

  • January 1, 2026: vulnerability reported through security advisory channels.
  • January 28, 2026: malicious issue-content execution path leveraged in practice.
  • February 9, 2026: public disclosure increased urgency and patching actions accelerated.
  • February 17, 2026: unauthorized npm publish (cline@2.3.0) occurred.
  • same day: corrected versions and remediation actions followed; compromised version deprecated.

The timeline shows two truths that both matter:

  1. the attacker chain was technically clever,
  2. process latency around vulnerability handling and credential assurance widened risk.

Why Existing Defenses Missed It

Several “normal” controls do not cover this chain well.

1. Binary or App-Diff Focus

If integrity checks emphasize app binaries but underweight packaging metadata, a one-line lifecycle script change can evade priority review.

2. Trust in CI Internal Boundaries

Teams often assume workflow boundaries and caches are naturally safe once inside a repo perimeter.
But any workflow that processes attacker-controlled text should be threat-modeled as internet-facing.

3. Long-Lived Publish Credentials

Static tokens keep value over time and are reusable once stolen.
By contrast, provenance-backed OIDC publish paths significantly narrow replay opportunities.

4. Input-to-Execution Coupling in Agent Workflows

If AI outputs are allowed to execute shell commands directly, untrusted prompt content can transitively become operation requests unless explicit policy gates exist.

What Cline Changed Afterward

Public post-incident statements and advisories indicate multiple corrective measures, including:

  • removing vulnerable AI triage execution patterns,
  • removing cache usage from credential-sensitive publish paths,
  • revoking/rotating publication credentials,
  • shifting npm publishing toward OIDC provenance-backed workflows,
  • tightening credential rotation validation procedures.

These are meaningful improvements, especially moving away from long-lived publish tokens for release operations.

What Engineering Teams Should Change Now

This incident is a practical design review template for any organization building AI-enabled CI.

1. Treat All Repo Text Inputs as Untrusted

Issue titles, issue bodies, PR titles, PR comments, and commit messages are attacker-controlled by default.
Never inject them into autonomous command-capable prompts without strict sanitization and policy mediation.

2. Separate “Read/Analyze” from “Execute/Mutate”

Agent workflows for triage should be read-only.
If execution is needed, require separate, constrained jobs with explicit human approval or narrowly scoped allowlists.

3. Eliminate Long-Lived Release Tokens

Use OIDC trusted publishing for registries that support it.
Bind publish rights to auditable workflow identity, commit provenance, and branch policy instead of static secrets.

4. Harden CI Cache Strategy

For security-critical release jobs:

  • disable cache restore where possible,
  • namespace cache keys with immutable context,
  • isolate credential-bearing pipelines from shared cache channels.

5. Enforce Install-Time Policy Controls

Detect and block suspicious lifecycle script behavior in dependency updates, especially:

  • new postinstall/preinstall hooks,
  • global install commands,
  • network egress during install phases.

6. Build Fast Security-Response SLAs

A technically strong team can still lose control through process delay.
Disclosure triage, remediation ownership, and credential validation need clear deadlines and rehearsed playbooks.

The Larger Pattern: Agent Security Is Now Supply Chain Security

Historically, “prompt injection” and “package compromise” were discussed in separate buckets.
Clinejection shows they can be one pipeline:

  • language injection opens execution,
  • execution compromises CI internals,
  • CI compromise breaks release trust,
  • release trust break lands on end-user machines.

That is why this incident matters beyond one package or one team.
Any org deploying AI operators in CI/CD now runs a blended threat model that combines LLM safety, workflow security, and dependency-chain controls.

Closing

The Hacker News discussion focused on the headline number: thousands of affected installs.
The more durable lesson is architectural:

if an agent can execute, and untrusted text can influence that agent, then your CI pipeline is an active attack surface.

Teams that separate interpretation from execution, remove static release credentials, and enforce operation-level controls will absorb this class of failure far better than teams relying on “trusted automation” assumptions.

Resources