Clinejection: What an OS-Layer Firewall Actually Sees
The attack chain that compromised 4,000 developer machines, analyzed at the process and syscall level. What Rampart blocks, what it logs, and what it misses.
On February 17, 2026, an unauthorized party used a stolen npm publish token to push cline@2.3.0. The postinstall script was a single line: npm install -g openclaw@latest. It was live for eight hours and downloaded roughly 4,000 times before Socket’s automated monitoring flagged it.
The full attack chain has been well-documented — Adnan Khan’s original disclosure, the Snyk breakdown, the Socket writeup. I’m not retelling it. What I want to do is be honest about what each defense layer would and wouldn’t have caught, because the narrative around this attack has gotten a bit muddled.
What actually happened
Five steps composed into a single exploit. Someone opened a GitHub issue against the Cline repo with a title crafted to look like a tool error but containing an embedded instruction. Cline’s AI-powered issue triage bot, running with allowed_non_write_users: "*", processed the title without sanitization and executed the injected command. That gave the attacker code execution on a CI runner.
From there: Cacheract flooded GitHub’s Actions cache past the 10GB LRU limit, poisoning it with a crafted payload that matched Cline’s nightly release workflow cache keys. When the release workflow ran, it restored the poisoned node_modules. The release workflow held the NPM_RELEASE_TOKEN. The attacker exfiltrated it and published the compromised package.
The 4,000 developers who got hit weren’t doing anything unusual. They ran npm install or npm update during an eight-hour window. The compromise arrived through normal package management, not through any action on their part.
What stopped it (and what didn’t)
StepSecurity’s Artifact Monitor caught the malicious version approximately 14 minutes after publication. That’s what actually limited the damage. Socket marked it as malware the following day after Cline published a GHSA advisory. Not a firewall, not an agent policy, not a sandbox. A service that watches the npm registry for anomalous package changes.
StepSecurity’s Harden-Runner, which monitors network egress from Actions runners, is the right tool for the CI/CD phase. That class of attack — pivoting through GitHub’s cache service to steal a publish token — happens entirely within CI infrastructure. An OS-layer tool running on a developer’s laptop has no visibility into it.
The prompt injection on the CI runner is interesting. Rampart’s watch-prompt-injection policy uses regex matching on tool responses for phrases like “ignore all instructions.” The Clinejection payload looked like a plausible tool error message. It bypassed string matching because it was socially engineered rather than blunt. Semantic understanding of whether Claude should install a dependency versus whether an attacker is tricking Claude into installing one isn’t something pattern matching solves.
The phase where OS-layer enforcement is actually relevant
The postinstall hook. When a developer ran npm install on the compromised version, npm’s lifecycle runner spawned npm install -g openclaw@latest as a child process. That’s the moment an OS-layer interceptor running on the developer’s machine would have seen something.
With rampart preload — which uses LD_PRELOAD to intercept exec-family syscalls from any child process — the ExecInterceptor evaluates that command before execution. The standard policy’s default_action: deny means unmatched commands require an explicit allow rule. A global npm install spawned by a postinstall hook wouldn’t match any allow rule in a typical development session. It would have been blocked.
That’s a real catch. It’s also a narrow one. The developer had to have Rampart installed and running with preload mode. Most didn’t.
Without preload, coverage depends on whether npm’s postinstall runner goes through $SHELL. Sometimes it does, sometimes it doesn’t. Shell-level interception is leaky for exactly this kind of lifecycle script attack.
What the payload actually installed
This is the part that’s relevant to the longer tail of this incident. The postinstall script installed OpenClaw — a separate AI agent framework — globally on developer machines. OpenClaw runs with full system access by default. The 4,000 affected developers now had a second AI agent on their machine that they hadn’t asked for and didn’t know about.
That’s the scenario Snare is built for. Not the supply chain attack itself, but what happens after: an unexpected agent running on your machine, touching your credentials.
Snare canary credentials planted in ~/.aws/credentials, ~/.ssh/config, ~/.npmrc, and the other standard locations would fire alerts when OpenClaw touched them. The alert includes the exact user agent, process metadata, timestamp, and IP. An unexpected process reading your AWS credentials at 3am is a signal that something is wrong, even if you can’t immediately identify it as a supply chain compromise.
The Snare connection here isn’t “Snare stops the attack.” It’s “Snare tells you when the thing the attack installed starts behaving like an agent that’s looking for credentials.” That’s a different problem with a different solution, and in the Clinejection case it’s actually the more relevant one for most affected developers.
What neither tool catches
The underlying vulnerability was a GitHub Actions CI bot with too much trust and no input sanitization. That’s an architectural problem in how Cline deployed their triage workflow. No local tool catches it because it never touches a local machine until the postinstall hook.
The disclosure-to-exploit gap is the other one. Khan reported the vulnerability privately on January 1 and received no response for five weeks. He published publicly on February 9. The exploit came eight days later, on February 17. Forty-seven days of unremediated vulnerability, with the last eight publicly known. The best runtime defense in the world doesn’t help when the upstream package is compromised before you install it.
Clinejection wasn’t a sophisticated attack. It composed five unremarkable techniques — prompt injection, cache poisoning, credential theft, postinstall hooks, social engineering — into a chain that no single layer was designed to catch end-to-end. That’s the actual lesson. Defense in depth doesn’t mean having one good tool. It means having the right tool at each layer, and knowing honestly where the gaps are.