title: "The Supply Chain Attack That Put Claude Code, Cursor, and Aider on Its Target List" description: "The Bitwarden npm compromise didn't just steal secrets β it explicitly hunted AI coding tool environments. Plus: Vercel's breach keeps getting bigger, AI inference infrastructure is being exploited within 13 hours of disclosure, and HN founders quietly ask if anyone is building anything without AI in it." publishedAt: 2026-04-25 author: Alex Rivera category: news tags: ["hn roundup", "supply chain attack", "Bitwarden", "Shai-Hulud", "Claude Code", "Cursor", "Aider", "AI security", "LMDeploy", "Vercel", "developer tools"]
I want to talk about something that should have every developer reading this immediately closing this tab to go check their npm audit logs. On April 22nd, between 5:57 PM and 7:30 PM Eastern time β ninety-three minutes β a malicious version of @bitwarden/cli was live on npm. Version 2026.4.0 contained a file called bw1.js that, when executed, stole your GitHub and npm tokens, your SSH keys, your .env files, your shell history, your GitHub Actions secrets, and your cloud credentials, and exfiltrated all of it to attacker-controlled domains and via GitHub commits to private repositories.
That's bad. Supply chain attacks via npm are not new. What is new is what the researchers at Aikido, OX Security, and Endor Labs found when they actually read the malware code: it contained an explicit target list of AI coding tool environments. Claude Code. Cursor. Kiro. Codex CLI. Aider. The malware wasn't just after generic developer credentials. It was specifically written to locate and exfiltrate the configuration files, API keys, and session tokens used by AI coding tools β the exact category of tool that the people using Bitwarden's CLI are most likely to have installed.
Think about what that means for a moment. Someone built a worm β this attack has already been attributed to the same "Shai-Hulud" campaign that hit Checkmarx last year, making this its third iteration β and when they sat down to write the target list, they included the five most popular AI coding assistants. Not as an afterthought. As a primary objective. The attack surface that the industry spent 2024 and 2025 excitedly building out is now, in 2026, an explicitly enumerated target in weaponized npm packages.
The Bitwarden security team responded well, all things considered. They contained the window to ninety-three minutes, deprecated the malicious release, revoked compromised access, and found no evidence that user vault data was exposed or that production systems were touched. The attack worked through their CI/CD pipeline β the attacker compromised Bitwarden's publish-ci.yml GitHub Actions workflow, which is how they were able to publish under the legitimate @bitwarden namespace rather than a lookalike. That's a more sophisticated vector than a typosquatted package. It means you could have been running official Bitwarden update processes and still installed this. Aikido's write-up calls it "the first analysed npm compromise explicitly targeting AI coding tools" and they are not wrong that this distinction matters.
Hacker News picked this up within hours of the Endor Labs post going live. The comments landed on a few themes worth noting. Multiple engineers flagged that the ninety-three-minute window means the damage is probably limited β but "probably" is doing a lot of work in that sentence, because anyone who had @bitwarden/cli set up in an automated pipeline or a Docker build that fired during that window would not know without digging through logs. One commenter β someone who listed ten-plus years running infrastructure β pointed out that the attack vector through GitHub Actions is "exactly the kind of thing that SOC teams don't have signatures for yet," which is correct. Another thread went deep on the self-propagating aspect: the malware contained code designed to spread through other npm packages it encountered in the target environment. That's not a credential stealer. That's a worm with a specific AI-toolchain awareness built in.
If you run @bitwarden/cli in any automated context, go check your pipeline logs for the April 22nd window right now. If you have any of the listed AI coding tools installed on the same machine or environment, assume your API keys and tokens for those tools are compromised until proven otherwise and rotate them. This is not dramatic. This is the correct operational response to a confirmed supply chain compromise with a ninety-three-minute exposure window and an explicit target list that includes tools you are probably actively using.
Yesterday I wrote about the Vercel breach. It keeps getting bigger. Vercel published an updated incident report this week: they have found evidence of additional compromised accounts beyond the initially disclosed employee account. The attack chain β Context AI OAuth over-permission grants colliding with a Lumma Stealer infection that started at Context AI when an employee downloaded what were functionally Roblox cheat scripts in February β has tentacles that are still being mapped. Vercel CEO Guillermo Rauch confirmed the expanded scope.
I want to zoom out from the specific incident here and say something about the structural problem it reveals, because the Trend Micro write-up on this incident calls it "the OAuth gap most security teams cannot detect, scope, or contain" and they're putting their finger on something real. The attack didn't start with a phishing email. It didn't start with a stolen password. It started with an employee at a third-party SaaS tool downloading game software on a personal or semi-personal machine, getting infected with an infostealer, and then cascading through an "Allow All" OAuth permission grant that someone made when connecting an AI productivity tool to their enterprise account.
The HN discussion on the earlier Vercel piece β before the expanded scope was disclosed β had someone note that "the blast radius of any SaaS compromise is proportional to how many OAuth grants you've handed out, and nobody audits those." That is correct. Most engineering teams couldn't tell you right now how many third-party OAuth apps have access to their enterprise Google Workspace or GitHub organization with broad permissions. The answer is almost certainly more than they think. The Vercel incident is a demonstration of what happens when one of those apps gets compromised upstream. You get a credential that looks legitimate from the inside, because it is β it's just being wielded by someone other than who you expected.
Rotate your environment variables. Audit your OAuth grants. These are the boring, unsexy responses that actually matter.
On the topic of AI infrastructure being actively weaponized: CVE-2026-33626, an SSRF vulnerability in LMDeploy's vision-language image loading pipeline, was published on GitHub on April 21st. By April 22nd β twelve hours and thirty-one minutes later β Sysdig's honeypot systems had recorded the first exploitation attempt. The attacker used LMDeploy's load_image() function, which fetches arbitrary URLs without validating against private IP ranges, as a generic HTTP client to port-scan the internal network behind the model server. In a single eight-minute session they probed the AWS Instance Metadata Service endpoint, Redis, MySQL, an internal admin interface, and a DNS exfiltration endpoint.
Twelve and a half hours. That's how long you had between "vulnerability published" and "active exploitation in the wild."
I have been watching vulnerability timelines for a long time, and the acceleration here is real and it is specific to AI infrastructure. Part of it is general β attackers have better automated scanning pipelines, and the CVE-to-PoC pipeline has compressed dramatically over the past few years. But part of it is specific to LLM inference servers, model gateways, and agent orchestration tools: they're new enough that defensive tooling and monitoring are immature, they run with elevated trust and broad network access by design, and they're being deployed in ways that frequently skip the hardening steps that more established infrastructure has accumulated over decades of getting hit. The Sysdig analysis notes that CVE-2026-33626 fits "a pattern observed repeatedly in the AI-infrastructure space over the past six months."
If you're running LMDeploy, patch immediately β the fix is to validate that load_image() URLs don't resolve to RFC 1918 addresses. If you're running any other LLM inference server that accepts arbitrary URLs as part of its vision or document pipeline, this is a good moment to audit whether those endpoints do the same validation.
The broader point is that the "collapsing exploit window" β the time between disclosure and active exploitation shrinking toward zero β is not a general phenomenon that happens to affect AI infrastructure. It's a focused pattern targeting AI infrastructure specifically, because that infrastructure is new, under-defended, and sitting inside networks with access to everything interesting.
In between all of this, Hacker News had a genuinely interesting social document going: "Ask HN: Is there any founder building a non-AI startup in 2026?" The thread has been running for a few weeks and the responses have a quality to them that's worth reading past the surface.
Yes, people are building non-AI things. Someone built a credential-sharing tool with audit trails and revocation β a real operational problem that doesn't benefit from LLMs. Someone else is building software that explicitly emphasizes having no AI sidebar, no ad-supported model, no network calls it doesn't need to make β positioning simplicity and predictability as the actual product. A few people working on embedded systems and microcontrollers noted that their domain is essentially untouched by the current wave. Hardware constraints are a useful forcing function.
But the texture of the thread is interesting beyond the specific projects. One commenter observed that "virtually everything in tech is touched by AI in 2026 except microcontrollers and embedded." Another posted about feeling FOMO around AI features but being "reluctant to shoehorn it in where it doesn't fit." A third said they were building without AI not as a philosophical position but because "the problem has a known good solution that doesn't require a model, and adding one would make it slower and more expensive."
That last framing is the one that actually matters. We've moved from "what can AI do?" to "where does AI make the thing better?" as the relevant question. The founders in that thread who are building without AI aren't making a statement β they're making a product decision. And the fact that making a product decision without AI now reads as unusual enough to prompt an Ask HN thread tells you something about how thoroughly AI has become the default assumption rather than a considered choice.
The HN commenter who got the most engagement in the thread put it plainly: "The question isn't whether to use AI. The question is whether using AI here makes the product better for the user or just cheaper to build. Those are not the same thing." That distinction is doing more work than most product teams are letting it do right now.
One more data point from the Stanford AI Index 2026 that didn't get enough attention in the coverage I've seen: the report identifies security as the number one scaling barrier for enterprise AI adoption, ahead of cost, ahead of reliability, ahead of regulatory uncertainty. This has been the cybersecurity world's contention for eighteen months, and it's now showing up in the data that enterprises are actually citing as their primary blocker.
This week illustrated why. The Bitwarden attack targeted AI coding tools specifically. The Vercel breach spread through an AI productivity tool's OAuth grant. The LMDeploy SSRF was exploited in twelve hours on AI inference infrastructure. The Anthropic Mythos story from earlier this week β the model "too dangerous to release" being accessed through a guessed URL on day one β is a different flavor of the same underlying problem: the AI toolchain, from the coding assistants on your laptop to the inference servers in your cloud to the models with capability profiles that require special handling, has a security posture that is not keeping pace with its capability profile.
That's not a prediction. That's April 25th, 2026.
The thing to take away from this particular week is not that AI is dangerous in some abstract sense. It's that the specific, concrete, unglamorous work of supply chain integrity, OAuth scope auditing, patch cadence for inference infrastructure, and access control for model endpoints is now as consequential as it's been for any other category of developer tooling β and is receiving about a third of the attention. The organizations that close that gap in the next twelve months will be meaningfully more secure than the ones that don't. The attack surface isn't going to wait for the industry to catch up on its own schedule.
Alex Rivera is a former CTO who has been building software since 2001. He has navigated the dot-com collapse, the social media gold rush, the blockchain winter, and is now watching the AI summer with the particular alertness of someone who has seen what hype cycles leave behind when they recede.
Related posts
The Best AI Tools in 2026: Eight We'd Actually Pay For
An opinionated, tested guide to the AI tools worth your money in 2026 β across writing, image, coding, and productivity. Real pricing, real verdicts.
ChatGPT vs Claude vs Gemini in 2026: A Working Writer and Coder's Verdict
We use all three every day. Here's the honest head-to-head β context windows, pricing, models, multimodal, coding, web access, and which one wins per use case.
The Best Free AI Tools in 2026 (And Which 'Free' Ones Are Lying)
A working list of 12 truly-free AI tools β separated into actually-free-forever, freemium-with-credit-card, and open-source self-hostable. Avoid the bait-and-switch.