Prompt Injection in AI Issue Triage Bot Led to Cline CLI Supply Chain Attack, Affecting Thousands of Developers

Overview

A supply chain attack targeting Cline CLI, a widely-used AI coding assistant with roughly 418,000 monthly npm downloads, installed unauthorized software on developer machines for approximately eight hours on February 17, 2026. The incident traced directly to a prompt injection vulnerability in the project’s AI-powered GitHub issue triage bot — a flaw publicly disclosed just eight days earlier.

The attack, which security researchers have dubbed “Clinejection,” offers a stark case study in how AI automation applied to software maintenance workflows can introduce novel supply chain risk vectors that bypass conventional code review controls.

The Clinejection Vulnerability

Security researcher Adnan Khan submitted a GitHub Security Advisory (GHSA) on January 1, 2026, detailing a multi-stage attack chain he had discovered in Cline’s GitHub Actions infrastructure. Cline’s repository had implemented an AI-powered issue triage bot — built on Claude — that automatically processed incoming GitHub issues to label and route them.

The critical flaw, as Khan detailed in his disclosure, was that the bot interpolated user-submitted issue titles directly into Claude’s prompt without sanitization. An attacker could craft a malicious issue title containing natural-language instructions, tricking the model into executing arbitrary npm commands through a preinstall hook in an attacker-controlled package.

From that foothold, Khan demonstrated a second stage: GitHub Actions’ shared cache, accessible to both the limited-permission triage workflow and the high-privilege nightly release pipeline. By flooding the cache with more than 10GB of data, the attacker could force eviction of legitimate cached dependencies. The vacated cache slots could then be filled with poisoned entries that the nightly release workflow would consume — exposing long-lived publishing credentials including the NPM_RELEASE_TOKEN, VSCE_PAT, and OVSX_PAT needed to push packages to npm, the Visual Studio Code Marketplace, and the Open VSX Registry.

Cline fixed the triage workflow within one hour of Khan’s public disclosure on February 9, 2026. However, the team did not immediately rotate the publishing credentials that the vulnerability had exposed.

The Attack: February 17, 2026

Eight days after public disclosure, an unidentified actor exploited the same attack chain against Cline’s publishing infrastructure. At 3:26 AM Pacific Time on February 17, 2026, a malicious package — cline@2.3.0 — was published to the npm registry using the compromised publishing token.

According to The Hacker News, the package differed from legitimate Cline releases in a single critical way: a postinstall script that executed npm install -g openclaw@latest, silently installing the OpenClaw autonomous AI agent framework on every developer machine that updated during the window.

The compromised version remained live on npm for approximately eight hours before Cline maintainers detected and deprecated it, releasing version 2.4.0 as the clean replacement. During that window, the package was downloaded roughly 4,000 times, according to The Register.

Endor Labs, a software supply chain security firm, noted in its analysis that version 2.3.0 also lacked the provenance attestations present in prior legitimate releases — a signal that the package had not passed through Cline’s normal publication pipeline.

What OpenClaw Is — and Isn’t

OpenClaw is a legitimate, open-source autonomous AI agent framework that has accumulated significant traction in developer communities. Cline maintainers were careful to clarify that OpenClaw itself was not malicious software; rather, its installation was unauthorized and undisclosed to users.

Microsoft Threat Intelligence observed “a small but noticeable uptick” in OpenClaw installations attributable to the Cline incident, per The Register. The attack did not activate OpenClaw’s “Gateway” daemon or establish persistent connections, limiting the direct harm — though any unauthorized software installation on developer workstations constitutes a meaningful breach of trust and a potential pivot point for future exploitation.

Endor Labs characterized the incident as resembling “a prank” in terms of immediate damage, while stressing that the same technique could have been used to deploy genuinely destructive payloads.

Remediation and Systemic Lessons

Cline’s response included deprecating version 2.3.0, revoking the compromised token, and migrating to OpenID Connect (OIDC) publishing via GitHub Actions — a mechanism that eliminates long-lived static tokens in favor of short-lived, workflow-scoped credentials. Developers who installed Cline during the affected window were advised to run cline --version, update to 2.4.0, and manually uninstall OpenClaw if present.

Snyk’s post-incident analysis identified three systemic failures that compounded into the attack:

1. Prompt injection in AI automation: Issue triage bots that process external user input without sanitization are susceptible to instruction injection — a risk that grows as AI automation is applied to more privileged operational contexts.
2. Shared cache across permission boundaries: GitHub Actions’ cache does not distinguish between workflows with different permission levels, allowing low-privilege workflows to influence the execution of high-privilege ones.
3. Long-lived publishing tokens: Static, long-lived credentials that were not rotated after the February 9 disclosure remained valid and exploitable.

Dark Reading noted that the gap between Khan’s disclosure and the attack underscored a recurring pattern: public vulnerability disclosures in open-source projects are regularly weaponized in the days before credential rotation or patching is complete.

What We Don’t Know

The identity of the attacker has not been publicly confirmed. It remains unclear whether the actor who exploited the Clinejection chain in production is the same as, or connected to, Khan’s original research. Cline has not published a full post-mortem indicating exactly when the publishing token was first compromised — whether during the January-through-February exposure window or immediately before the February 17 incident.

The full population of affected developer machines also remains uncertain. While the npm download count provides a floor, the package may have propagated through CI/CD pipelines and developer workstation image caches that are not captured in standard registry metrics.