Cline CLI 2.3.0 supply chain attack silently installed OpenClaw on developer systems

Cline CLI 2.3.0 supply chain attack silently installed OpenClaw on developer systems

Executive summary

The Cline CLI supply chain incident is a practical reminder that unauthorized changes in developer tooling do not need to be overtly malicious to become a serious incident response problem. According to The Hacker News and Cline's own advisory, [email protected] was published to npm using a compromised publish token and included an added postinstall script that ran npm install -g openclaw@latest.

That meant any user or CI runner that installed Cline CLI 2.3.0 during the affected window could end up with OpenClaw globally installed without authorization. The package itself was described as legitimate and non-malicious, but the delivery path was not. From a defender's perspective, that still qualifies as a software supply chain failure because trusted package installation behavior was altered downstream.

What happened?

Cline maintainers said an unauthorized party used a compromised npm publish token on February 17, 2026 at 3:26 AM PT to publish [email protected]. The release modified package.json to add a postinstall hook that installed OpenClaw globally.

The affected exposure window lasted roughly eight hours, ending when maintainers published version 2.4.0 and deprecated 2.3.0 later that morning. Public reporting says the impact was limited to the CLI package on npm. The VS Code extension and JetBrains plugin were not affected.

StepSecurity estimated the compromised version was downloaded about 4,000 times during that period. Microsoft Threat Intelligence also reported a noticeable uptick in OpenClaw installations that aligned with the compromise window.

Why defenders should care

1. Unauthorized install events matter even without overt malware

This case is unusual because the secondary payload was not described as malware. Even so, an unexpected global package install on developer systems is still a security event. It changes endpoint state, expands attack surface, and forces teams to verify what landed where.

2. Developer tooling is now part of the production attack surface

The impacted package sits close to engineering workflows, local shells, and CI runners. That makes compromise of package publication or update paths operationally important even when the visible code delta is small.

3. The upstream lesson is bigger than the payload

The reporting connects this incident to Clinejection, a previously disclosed chain involving prompt injection risk in an AI-assisted GitHub issue triage workflow, abuse of GitHub Actions cache behavior, and potential theft of publication secrets. Whether defenders own AI-enabled workflows or not, the broader lesson is the same: automation that handles untrusted input must not sit too close to release credentials.

Technical details in plain English

The unauthorized npm release changed the package lifecycle behavior by adding this logic to package.json:

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

So the attack did not need to replace the primary CLI binary to create downstream impact. It only needed to alter installation behavior at publish time.

The reported upstream path is also important. Research cited by The Hacker News describes a chain where an attacker could influence an AI issue-triage workflow through crafted GitHub issue content, gain command execution in CI, poison GitHub Actions caches, pivot into nightly release workflows, and ultimately access publication credentials. That is a strong example of how CI/CD misconfiguration, cache trust, and AI workflow design can converge into a supply chain vulnerability.

Affected versions and scope

Public disclosures indicate that:

• Affected product: Cline CLI on npm
• Affected version: 2.3.0
• Exposure window: approximately 3:26 AM PT to 11:30 AM PT on February 17, 2026
• Fixed version: 2.4.0 and later
• Not affected: Cline VS Code extension and JetBrains plugin

If your teams installed cline during that period, you should assume review is required.

Immediate actions to take

🔴 Identify affected systems

Search developer endpoints, ephemeral build runners, and long-lived CI agents for installs of [email protected] during the affected window.

🔴 Check for unexpected OpenClaw installation

Review global npm packages and package manager logs to confirm whether OpenClaw was installed as a result of the compromised release.

🔴 Update and clean up

Upgrade Cline CLI to 2.4.0 or later and remove OpenClaw from any system where it was not intentionally deployed.

🟠 Review CI/CD exposure

If a build pipeline installed the affected version, review runner telemetry, job logs, environment variables, and credential scope. Even when observed impact looks low, you should verify what secrets and permissions were present in those environments.

🟠 Tighten publish controls

For maintainers and internal package owners, this is a good time to disable legacy token-based publishing, require OIDC trusted publishing, and alert on missing provenance or unexpected changes in publisher identity.

🟠 Harden automation paths

Any AI-assisted or automation-heavy workflow that accepts untrusted external input should be isolated from release credentials, high-trust caches, and privileged workflows.

Detection ideas

Security teams should review:

• npm logs for installation of [email protected]
• global package inventories for openclaw
• endpoint telemetry showing unexpected npm install -g activity
• CI runner logs tied to developer tooling installs on February 17
• GitHub Actions anomalies such as unusual cache churn, provenance gaps, or suspicious post-checkout behavior

Strategic takeaway

This incident matters less because of what OpenClaw is and more because of how it arrived. When trusted package distribution can be altered through compromised publish credentials or weak automation boundaries, the security model around developer tooling starts to look a lot like production software supply chain risk.

For defenders, the right response is straightforward: validate exposure, clean up unauthorized installs, and use the event to harden package publishing, provenance checks, and AI-connected CI/CD workflows.

Was OpenClaw malware in this case?

Public reporting and the vendor advisory said OpenClaw itself was a legitimate open-source package and not malicious. The security issue was that it was installed without authorization through a compromised package release.

Which Cline products were affected?

Only the Cline CLI package on npm, specifically version 2.3.0. The VS Code extension and JetBrains plugin were not affected.

What should defenders do first?

Identify systems that installed [email protected], verify whether OpenClaw was installed, update to a fixed Cline version, and review CI and developer endpoints for unauthorized package changes.

References

1. The Hacker News coverage.
2. Cline GitHub security advisory.
3. StepSecurity incident analysis.
4. Adnan Khan's Clinejection research.