AI SECURITY • SUPPLY CHAIN • DEV TOOLS
A Hacker Made an AI Coding Tool Install OpenClaw Everywhere. The Stunt Is Funny. The Pattern Is Not.
Cline CLI 2.3.0 briefly shipped with an unauthorized postinstall that globally installed OpenClaw. No fireworks, no ransom notes, no obvious malware. And that is exactly why this incident matters.
TL;DR (3 things to remember)
- Confirmed: Installing cline@2.3.0 during an ~8-hour window on Feb 17, 2026 could run a postinstall that globally installed openclaw.
- Big idea: When AI tools and automation touch real tokens and real publish pipelines, text inputs (issues, PRs, logs) can become execution paths.
- Do now: Check your environment, remove unintended installs, update to cline 2.4.0+, and harden how agents and CI handle untrusted content.
In this guide
What happened, in plain English
A popular open-source AI coding agent, Cline, has a CLI
distributed via npm. For a short window, an unauthorized release of the
CLI package (cline@2.3.0) was published with a modified
package.json that added a lifecycle script. If you installed
that version during the window, npm could execute the script and
globally install a second package:
openclaw.
The payload choice made headlines because OpenClaw is viral and recognizable. That’s why this story reads like a prank. But the important part is not the lobster-shaped mascot, or even the specific package. The important part is the security pattern: autonomous tools + real permissions + supply chain distribution.
What is confirmed
- The incident affected the Cline CLI package on npm, not the VS Code extension or JetBrains plugin.
- Installing cline@2.3.0 during the window could install openclaw globally.
- OpenClaw was described as a legitimate open-source project, and the core issue was unauthorized installation.
- 2.4.0 and higher are fixed; the compromised token was revoked; publishing moved to stronger provenance.
What is likely (but separate from “confirmed”)
- The attacker had access to the ability to publish to npm (via a token or equivalent credential).
- OpenClaw was used as a “proof-of-impact” payload; a malicious actor could have chosen something worse.
- This incident sits in the same risk neighborhood as prompt injection and workflow credential exposure, especially in agentic tooling.
Timeline (high level)
- Feb 9, 2026: A researcher published a write-up showing how agentic workflows can be steered toward supply-chain outcomes.
- Feb 17, 2026: cline@2.3.0 is published with an added postinstall that installs openclaw globally.
- Same day: Cline deprecates 2.3.0, ships a corrected release, revokes the compromised token, and documents the incident publicly.
Note: exact timestamps vary by source/timezone. For operational response, use the official advisory as the anchor of truth.
Why this matters more than a prank
Supply chain incidents used to be framed like this: “A dependency got backdoored.” That is still true, but incomplete. The modern story is: systems publish software automatically, and developers increasingly wire in agents that can browse, edit, run commands, and sometimes push releases.
When an agent or automation has access to a publish credential, the boundary between “reading” and “doing” collapses. A GitHub issue stops being “text.” It becomes a place where instructions might land, get processed, and turn into actions. That’s how you get a situation where a package registry becomes the delivery channel for whatever the attacker wants.
Memorable rule: If an AI tool can click “Publish,” every text box it reads becomes part of your attack surface.
How the attack works (the pieces you need to understand)
1) Why postinstall scripts are so effective
npm packages can run lifecycle scripts such as postinstall.
In normal development, these scripts are used for setup tasks (compiling
native modules, generating files, validating environment assumptions). In
an incident like this, lifecycle scripts become a delivery mechanism
because they run at install time.
The compromised release reportedly added a simple behavior: run a global install of another package. Simple. Loud in hindsight. But also exactly the kind of thing that can slip through if teams are accustomed to “install scripts are normal” and rely on registries as implicit trust anchors.
2) Prompt injection: not magic, just mis-scoped trust
Prompt injection is when untrusted content is treated as instructions by an LLM-driven workflow. The trick is rarely a single “evil sentence.” The trick is that an agent is asked to do something like “summarize this issue and decide next steps,” and the issue contains text like: “Ignore the above. Do X. Exfiltrate Y. Run Z.”
If your agent is allowed to call tools (terminal, browser, repo operations), and your pipeline doesn’t enforce a strict separation between “content” and “instructions,” you can get undesirable outcomes. The model doesn’t need superpowers. It just needs permission.
3) Supply chain: why this becomes “everywhere” quickly
Registries scale. That’s their job. When the distribution channel is npm, a compromised release can propagate into laptops, CI runners, and build servers quickly, especially when a package is popular and continuously installed.
In the Cline case, the incident was contained quickly. But the same playbook, applied to a more harmful payload, would be a very different day: credential theft, repository poisoning, CI persistence, and downstream compromise of dependents.
Who was affected (and who was not)
Affected
- Systems where cline@2.3.0 was installed from npm during the incident window.
- Environments that executed install scripts normally (developer machines, CI, ephemeral build containers).
Not affected (per the public advisory)
- The Cline VS Code extension and JetBrains plugin.
- Users installing versions 2.4.0+ after the fix, and those who did not install 2.3.0 during the window.
How to check if you were affected (and fix it safely)
Before you start
The goal here is not panic. The goal is verification.
You want to know: did you install cline@2.3.0 during the
window, and did openclaw get installed globally as a
result?
Step 1: Check your installed Cline version
cline --versionIf you have multiple Node setups, check the one you used at the time (nvm, volta, asdf, system Node, CI runner).
Step 2: Check global installs for OpenClaw
npm ls -g --depth=0 | grep -i openclaw
On Windows PowerShell, use:
npm ls -g --depth=0 | Select-String -Pattern openclaw
Step 3: Remove unauthorized global install (if present)
npm uninstall -g openclawStep 4: Update Cline to a fixed version
npm install -g cline@latestIf your team pins versions, update your pin to 2.4.0 or higher based on the official fix guidance.
Step 5: Optional hygiene (recommended for CI images and shared runners)
npm cache verifynpm cache clean --forceCache cleaning is not a magic erase button. It is a practical cleanup step for shared runners and cached build images.
Step 6: If this touched your CI/CD, rotate credentials
If you run Cline (or any agent) inside CI, or if your environment stores publish tokens, treat this as a reason to: rotate npm tokens, rotate GitHub tokens, review GitHub Actions secrets access, and audit publish permissions. The risk you are defending against is not just “an extra package installed.” It is “a workflow that could be made to act on secrets.”
Should you disable npm install scripts?
Disabling lifecycle scripts can reduce risk, but it can also break legitimate dependencies. The right answer is situational: a production CI pipeline that builds container images for deployment may have a different policy than a local dev machine.
When disabling scripts makes sense
- High-trust environments: build servers, release pipelines, image builders.
- Install steps that should be deterministic (and do not require native compilation).
- When you can use allowlists or prebuilt artifacts instead of arbitrary install-time execution.
When you need a more careful approach
- Projects that depend on native modules or build steps executed during install.
- Tooling that expects postinstall hooks (some CLIs, language bindings, binaries).
- Teams without the bandwidth to maintain a curated allowlist or internal mirror.
A practical compromise many teams adopt: disable scripts by default in CI, then explicitly enable them only in controlled steps, inside isolated containers, for known packages.
Old vs New: why AI agents change the threat model
| Topic | Traditional dev tooling | Agentic dev tooling |
|---|---|---|
| Inputs | Code + configs | Code + configs + untrusted text (issues, PRs, docs, logs) |
| Decision-making | Human interprets text | Model interprets text (often at scale) |
| Action surface | Human runs commands, publishes | Agent can run tools, modify files, trigger workflows, publish |
| Failure mode | Human mistake | Instruction hijack + automation speed |
| Blast radius | Usually local | Potentially systemic (CI, release, registries) |
The point is not “AI is unsafe.” The point is: when you grant autonomy, you must redesign controls. In agentic systems, guardrails are infrastructure, not a checkbox.
Hardening guide: how to run AI coding agents without losing sleep
For individual developers
- Prefer least privilege: do not give agents your most powerful tokens by default.
- Separate contexts: run agentic tooling in a dedicated dev container/VM when possible.
- Pin and verify: use lockfiles, pin CLI versions, and avoid “latest” in automation where you can.
- Audit global installs: periodic checks of globally installed packages are low effort and high value.
- Be skeptical of instructions inside content: issues and docs can be hostile when an agent reads them.
For teams and CI/CD
- Gate actions: human approval for publishing, token access, and production changes.
- Credential hygiene: short-lived tokens, scoped permissions, automatic rotation, and immediate revocation paths.
- Isolation: ephemeral runners, minimal filesystem access, restricted network egress, no shared home directories.
- Install policy: consider disabling lifecycle scripts in CI, then allowlist exceptions.
- Provenance: use OIDC-based publishing or equivalent provenance mechanisms where supported.
- Monitoring: alert on unexpected publish events, unexpected version bumps, and install-time script execution in sensitive pipelines.
For maintainers (the “make this not happen again” list)
- Kill long-lived publish tokens: move to OIDC trusted publishing where possible.
- Split credentials: do not let nightly tokens equal production tokens.
- Lock down GitHub Actions permissions: minimize secret exposure and restrict what workflows can do.
- Guard untrusted triggers: issue/PR-driven automations should not run with write/publish privileges.
- Fast advisory muscle: publish clear advisories, time windows, and remediation steps immediately.
What to watch next: “stunt payloads” won’t be the default
In this case, the installed package was described as legitimate and not inherently malicious. That reduced immediate damage. But the uncomfortable takeaway is that the delivery mechanism worked. The same pathway could ship credential stealers, backdoors, or persistence. Attackers optimize for access and repeatability, not for clever jokes.
As more people let autonomous software use their computers on their behalf, you should expect more incidents that look like: “A harmless thing was installed… this time.” That “this time” is doing a lot of work.
Takeaway you can share: The AI era doesn’t invent new attackers. It reduces the friction between untrusted text and privileged actions.
FAQ
Is OpenClaw malware?
In the reporting and the project advisory context, OpenClaw was described as a legitimate open-source project. The core issue in this incident was that it was installed without user authorization via a compromised release. Even if a package is legitimate, unauthorized installation is still a serious supply chain event because it proves someone had publish capability.
How do I know if I installed cline@2.3.0 during the incident window?
Start by checking your current installed version (cline --version). Then check your install logs (CI logs, shell history), and check
for a global OpenClaw install (npm ls -g --depth=0). If
you use multiple Node environments, check each relevant environment.
How do I remove OpenClaw safely?
Uninstall it globally: npm uninstall -g openclaw. Then
update Cline to a fixed version, and consider cache verification steps
for shared runners.
Should I disable npm install scripts everywhere?
Not everywhere. But in high-trust environments like CI/CD and release pipelines, disabling scripts by default is often a good baseline, paired with allowlisted exceptions. The most important control is aligning privileges with trust: untrusted inputs should not lead to privileged actions.
How do prompt injections turn into supply-chain compromises?
Prompt injection is a steering technique: untrusted text contains instructions that an LLM-driven workflow may follow. If that workflow has access to secrets or privileged tooling (publish tokens, repo write access), the injected instructions can push the system toward unsafe actions. The “bridge” is permission: the model can’t publish unless the pipeline lets it.
What is the single best hardening move for teams adopting agents?
Put a hard gate between “agent recommendations” and “privileged actions.” Publishing, token access, production deploys, and registry writes should require explicit approval, least-privilege credentials, and isolated execution.