Cline GitHub Actions Compromise and Unauthorized npm Release - [email protected]
On February 17, 2026 an attacker stole the npm publish token used to release the Cline CLI package through its GitHub Actions workflow and pushed an unauthorized [email protected] release to the npm registry. No CVE was assigned; defenders track this as a supply-chain incident, not a product flaw. This advisory covers what happened and how to inventory and govern the agents that touch publishing credentials.
What happened
Cline is an open-source AI coding agent. While it is best known as a VS Code extension, the compromise affected only its command-line tool published to the npm registry (the VS Code extension and JetBrains plugin were not affected). On February 17, 2026, an attacker reached the GitHub Actions workflow that builds and releases the Cline CLI and obtained the npm publish token it uses to push releases. With that token, the attacker published an unauthorized [email protected] version - code the Cline maintainers did not author, shipped under the project's real package name.
Because the token carried publish rights, the unauthorized release was positioned to reach every developer who installed or updated the package. The root cause was not a code-execution bug in Cline itself; it was a single over-permissioned workflow token reachable through the project's CI integration, turned into a supply-chain foothold. It mirrors the broader wave of agentic CI/CD abuse - the bot-actor and prompt-injection bypasses in the Claude Code GitHub Action and the Amazon Q extension compromise - where an attacker influences an automated workflow, captures a publishing credential, and ships malicious code through a trusted channel.
Remediation centered on operational cleanup: revoking the stolen npm token, removing the unauthorized [email protected] release from the registry, and tightening the scope of the workflow token. Because no CVE was assigned, there is no patched version to chase - the durable response is to know which endpoints run the affected agent and to record what those agents do with secrets.
Why this is an agentic-endpoint risk
The asset the attacker monetized was a publishing credential, and the path to it ran through an AI agent's CI integration. A coding agent like Cline does the ordinary work of building and releasing through automated workflows; the moment one holds a broadly scoped publish token, any influence over the workflow - a malicious pull request, a prompt injection, a bot actor - becomes a path to the registry. AI agents and CLIs are part of the eight AI artifact types Anomity tracks per endpoint, adopted bottom-up the same way AI agents became the new shadow IT.
This exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The publish step looks like a legitimate CI job to network tooling, the Cline process looks legitimate to EDR, and DLP sees nothing at rest because the token moves through a live workflow, not a file. The question is not whether one workflow is patched - there is nothing to patch - it is which endpoints and pipelines run the Cline surfaces, and what secret access those agents perform. It is the same root cause as the sibling Claude Code project-file RCE and token exfiltration advisory: a credential exposed to an agent acting on untrusted input.
How Anomity surfaces and governs it
With no version to roll forward, the durable control is to inventory the agents that can reach publishing credentials and govern what they do with them. Anomity does that in three steps.
First, inventory. Anomity inventories AI agents and CLIs on every managed endpoint as part of the eight AI artifact types it tracks, then classifies them. It captures which Cline surfaces are present across developer machines and CI-adjacent endpoints, so you can find every place that can build and publish a package. Anomity collects metadata only, and secrets such as an npm publish token are redacted on the endpoint before anything leaves it.
Second, decide at the hook. On agents that expose a hook - for example, the Claude Code PreToolUse event - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. An agent reaching for a publish token, or invoking a release command that would push to a registry, can be denied at the boundary - which is exactly what runtime governance provides when there is no patch to wait for.
Third, keep the record. Anomity logs the tool calls and secret access an agent performs, so an agent reaching a publish token in CI is recorded against a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When an incident like the Cline npm token theft lands, you can answer which endpoints ran the affected agent and what they were allowed to do - from a record, not a guess. Anomity is SOC 2 Type II and complements your Network, EDR, DLP, and GRC tooling; it covers the artifact layer those were never built to inventory.
You can't govern what you can't see.The Anomity principle
What to check across your fleet
- Inventory every endpoint and pipeline that runs Cline - the VS Code extension and any CLI surface - confirm none installed the unauthorized [email protected] release, and pin to a known-good version.
- Audit which GitHub Actions workflows hold npm publish tokens, scope each to the narrowest permission and shortest lifetime, and prefer trusted-publisher flows over long-lived tokens.
- Treat any token reachable through an AI agent's CI integration as exposed to untrusted input - a malicious pull request, prompt injection, or bot actor.
- Confirm release and publish commands triggered by an agent are evaluated at a hook with allow/deny/log, so an unauthorized push to a registry is stopped before it runs.
- Verify npm tokens and other agent credentials are redacted on the endpoint and never centralized in plaintext, so a workflow-time read has nothing to capture.
- Verify every tool call and secret access is written to a 90-day audit trail and routed to your SIEM, so you can answer scope when the next CI supply-chain incident lands.
- Cross-reference this inventory against the sibling Claude Code project-file RCE and token exfiltration advisory to find endpoints exposed to more than one credential-theft path.
The Cline compromise is a reminder that an AI agent's everyday work - building and publishing through automated workflows - is a credential and supply-chain path the moment a publish token is over-scoped. Revoke and re-scope the affected tokens, confirm no endpoint carries the unauthorized [email protected] release, then inventory the agents and CLIs your endpoints run and govern the tool calls those agents make at the hook. For the full coding-agent attack surface, see the pillar guide on securing AI coding agents and CLIs. To see Anomity govern the agent layer across your fleet, request early access.
Frequently asked questions
What happened in the Cline GitHub Actions compromise?
In February 2026 an attacker abused Cline's GitHub Actions workflow to obtain the npm publish token used to release the Cline package, then used that token to push an unauthorized [email protected] release to the npm registry. Because the token had publish rights, the unauthorized version could reach every developer who installed or updated the package through the trusted distribution channel. There was no product code-execution flaw at the core of the incident; the root cause was an over-permissioned workflow token reachable through the project's CI integration. No CVE was assigned, so defenders track it as a supply-chain incident rather than a software vulnerability.
Was a CVE assigned to the Cline npm token theft?
No CVE was assigned. The Cline compromise is a supply-chain incident, not a product vulnerability with a fixed code path, so it is tracked as an incident rather than under a CVE identifier. Remediation centered on operational steps: revoking the stolen npm publish token, removing the unauthorized [email protected] release from the registry, and tightening the scope of the workflow token so a single credential reachable through CI can no longer publish. The durable control beyond cleanup is to know which endpoints run the Cline extension and CLI surfaces, and to record what tool calls and secret access those agents perform.
How does this relate to the Claude Code GitHub Action and Amazon Q incidents?
All three sit in the same wave of agentic CI/CD abuse. The Claude Code GitHub Action saw bot-actor and prompt-injection bypasses, and the Amazon Q extension was compromised through an automated workflow that shipped malicious code. The Cline incident follows the same pattern: an attacker influences an automated workflow, captures a publishing credential, and ships code through a trusted channel. The common thread is an AI agent's CI integration exposing an over-permissioned token. Treating that token as untrusted, scoping it tightly, and recording every agent secret access on the endpoint is the consistent control across the cluster.
How does Anomity reduce exposure to this class of incident?
Anomity inventories AI agents and CLIs on every managed endpoint as part of the eight AI artifact types it tracks, so you can find Cline across the fleet and see which surfaces are present. On agents that expose a hook, it returns allow, deny, or log on each tool call before it runs, so an agent reaching a publish token or invoking a release command can be denied at the boundary. Every tool call and secret access is recorded against a queryable 90-day audit trail, with metadata-only collection and on-endpoint secret redaction, and decisions route to your SIEM, Slack, email, or Jira.