The check software supply chain: the Cline attack you installed OpenClaw without permission

This week another worrying episode was confirmed in the security of the software supply chain: the Cline CLI programmer help tool, an open source project that integrates artificial intelligence capabilities, was published on the npm network in a compromised version that included an instruction to quietly install the OpenLaw autonomous agent. The package concerned was cline @ 2.3.0, and the unauthorized publication was produced on 17 February 2026 using a publication token that, according to the maintainers, had been compromised. The official communiqué is available in the security notice of the project in GitHub: GHSA-9ppg-jx86-fqw7.

The published package included a modification in package.json that added a post-installation script whose effect was to run npm install -g openclaw @ latest. This led, for a period of approximately eight hours between 3: 26 and 11: 30 PT on February 17, any developer who installed that version received the automatic OpenLaw installation in its surroundings. Cline officials claim that no other malicious code was detected within the package, and that the OpenClaw installation was not designed or authorized; yet, the fact that an autonomous agent could be distributed thus gives rise to concern.

The maintainers responded by withdrawing the affected version and publishing quickly cline @ 2.4.0, in addition to disable the committed token and marking the 2.3.0 as deprecada. They also announced changes to their publishing mechanism that incorporate OpenID Connect (OIDC) from GitHub Actions to reduce the dependence on static tokens and minimize this type of risk. The technical news flow has been documenting the reaction and the scope: for example, Microsoft Threat Intelligence noted in its X account an increase in OpenClaw facilities matching the incident ( see publication), and security signatures have estimated that the compromised version was downloaded thousands of times during the exposure window, according to data shared by StepSecurity.

Although OpenClaw itself is not considered malware and, according to the analysis of the firm Endor Labs, the publication did not contain components that would immediately start dangerous services, this event is a reminder that the unwanted installation of privileged software can become a gateway for more serious attacks. As the researcher Henrik Plate of Endor Labs explained, the immediate technical impact may be limited, but the operational lesson is clear: the maintainers must force reliable publishing mechanisms and users must monitor the atstations and signatures associated with the releases. The complete analysis of Endor Labs is available here: Endor Labs - incident analysis.

Research on how the ability to publish the malicious version was obtained points to a more complex chain of exploitation involving IA agents used in triage workflows of issues. Researcher Adnan Khan detected that the Cline repository had a workflow that, when an incidence opened, raised a Claude agent with access to the code base and additional tools to generate automatic responses. This automation, designed to lighten the burden of the maintainers, granted excessive permissions to the agent, and a carefully built issue title could induce the IA to execute arbitrary commands: a technique that Khan baptized as "Clinediction." His technical explanation and evidence are published on his blog: Clinediction - analysis by Adnan Khan. The commission that introduced the potentially operating change can also be found in the repository: December 2025 commitment.

The attack sequence described by Khan combines prompt injection against IA agents with a cache poisoning technique in GitHub Actions to achieve execution in a publication workflow with high permissions. The attacker first causes the triage system to execute malicious code, then fill the cache with data that cause the expulsion of legitimate entries and place "poisoned" entries that match the keys used by the publication night jobs. When the night publication routine runs and finds those manipulated inputs, it recovers artifacts and credentials that allow those who control the flow to publish artifacts in npm with production tokens. Khan had already written about this type of risk in previous analysis of GitHub Actions cache poisoning: The monsters in your build cache.

External researchers have confirmed that the operating chain described was, in essence, the one that resulted in the publication of cline @ 2.3.0 with the post-installation script. A technical report summarizing findings and correlations is available on the MBG Security blog, which details how an active npm publication token was used to sign and upload the committed package: MBG Security - commitment investigation. In addition, case analysis and coverage by specialized security means help to understand the picture: socket.dev - attack analysis and a more general note with industry reactions in The Hacker News.

Beyond the immediate technical details, the security community notes a practical conclusion: the IA agents incorporated in pipelines and automations are not neutral actors; when they receive extensive permits, they act as privileged components of the system. Chris Hughes, responsible for security strategy in Zenity, synthesized this idea by stressing that what was previously discussed in abstract about the safety of self-employed agents now has a tangible operational cost and requires specific governance and access controls. The note with his statement is collected in the coverage of the incident by The Hacker News.

If you use Cline or manage repositories using similar automations, the immediate measures recommended by response teams and researchers are clear: update to the corrected version, review the environment by unexpected OpenClaw facilities and remove any unrequired component, rotate tokens and credentials that may have been exposed, and tighten workflows so that IA agents do not receive permission to run code with publication privileges. It is also appropriate to adopt OIDC for publication from GitHub Actions and to disable publication by traditional tokens where possible, as well as to add attestation and signature checks on delivery pipelines.

This incident highlights that the adoption of IA in development and operations brings benefits, but also introduces new attack vectors. The security of the supply chain is no longer just the responsibility of package holders: it involves teams from below, developers and the platforms themselves that orchestrate automations. Maintaining confidence in the packages we install requires, now more than ever, fine controls over who or what you can publish, traceability of publications and regular audits of automated flows.