Skip to content
HACKTECH
AI securityReported Published 4 sources

Unauthorised Cline CLI release followed a prompt-injection flaw in its AI triage bot

On 17 February 2026 an unauthorised party used a compromised npm publish token to release Cline CLI 2.3.0 with a postinstall script that globally installed OpenClaw; the version was available for about eight hours and was downloaded roughly 4,000 times, according to StepSecurity. Eight days earlier a security researcher had publicly disclosed "Clinejection", in which a GitHub issue title could prompt-inject Cline's Claude-based issue-triage workflow and, through GitHub Actions cache poisoning, expose nightly publishing tokens. Cline said that when it rotated credentials on 9 February the wrong token was deleted and the exposed npm token stayed active; it then published 2.4.0, deprecated 2.3.0 and moved npm publishing to OIDC via GitHub Actions.

  • prompt injection
  • GitHub Actions
  • npm
  • CI/CD
  • Cline
  • cache poisoning

What the sources report

  • The triage workflow, added on 21 December 2025, ran claude-code-action on the issues event in a configuration any GitHub account could trigger by opening an issue; its allowed tools included Bash, Write and Edit, and the issue title was interpolated directly into the prompt.
  • In the disclosed chain, the agent would run npm install against an attacker-controlled commit, flood the GitHub Actions cache past 10 GB to evict entries and plant poisoned node_modules caches that nightly publish workflows restore, which could expose VSCE_PAT, OVSX_PAT and NPM_RELEASE_TOKEN.
  • According to the researcher's timeline, the issue was reported privately on 1 January 2026 and followed up several times before public disclosure on 9 February, after which Cline removed the bot workflows and rotated credentials.
  • StepSecurity's monitoring flagged 2.3.0 at 11:40 UTC, 14 minutes after it was published, because it was published manually from a user account without npm provenance attestations, unlike earlier releases made through GitHub Actions OIDC trusted publishing.
  • Cline's advisory GHSA-9ppg-jx86-fqw7 rates the issue Low, says no other files were modified and the CLI binary was identical to 2.2.3, and states that the VS Code extension and JetBrains plugin were not affected.
  • The Hacker News reported that Microsoft Threat Intelligence observed a small but noticeable uptick in OpenClaw installations on 17 February 2026.

What it means for your organisation

An AI agent that reads untrusted text such as issue titles and holds shell tools inside CI/CD is a privileged automation account that anyone on the internet can address. In this case it sat alongside a build cache shared with publish workflows and nightly credentials that could publish production releases, and Cline later said the exposed npm token had survived its rotation. Rotation after a disclosure needs to be verified at each registry, not assumed from a checklist.

What we check

  • Inventory CI workflows that pass issue, pull request or comment text to an LLM agent, and check which tools, tokens and permissions that agent can reach, mapped to OWASP LLM01:2026 (prompt injection) and LLM03:2026 (excessive agency).
  • Confirm that workflows triggered by untrusted users cannot write caches that release or publish workflows restore, and that publish jobs do not consume shared caches.
  • Check that packages are published through OIDC trusted publishing with provenance, and that any release published outside the pipeline raises an alert.
  • After a credential exposure, verify revocation directly at each registry, such as npm, the VS Code Marketplace and Open VSX, rather than relying on rotation records.
  • Check developer and CI hosts for unexpected global packages installed by dependency postinstall scripts.

Sources

Services that cover these checks

  • AI & LLM application testing

    Adversarial testing of features built on large language models: chat assistants, retrieval-augmented search, agents with tool access, and generated output that reaches users or other systems. We test whether the model can be steered into leaking data, taking actions it should not, or passing untrusted output into the rest of your stack.

    Duration: 4 to 10 working days

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works