Somewhere in the sprawling registry of open-source JavaScript packages, a piece of code sat waiting. It looked like a useful library. It had a plausible name, a reasonable description, and version numbers that suggested active maintenance. But buried inside was something else entirely — a wiper designed to destroy data on machines geolocated to Iran, and a self-propagating mechanism that let it spread from one software project to the next like a digital contagion.
The discovery, first reported in detail by Ars Technica, has rattled the software supply chain security community. Not because supply chain attacks are new — they aren’t — but because this one combined geopolitical targeting with worm-like propagation in a way that security researchers say they haven’t seen before in the npm registry. The attack didn’t just compromise a single package. It was engineered to infect other packages on the same developer’s machine, turning each victim into an unwitting distributor.
The malicious packages were identified by researchers at Reversing Labs and Socket, two firms that specialize in software supply chain security. According to their analysis, the packages masqueraded as legitimate tools — one posed as a helper for working with arrays, another as a configuration utility. Innocuous names. Standard-looking code. The kind of thing a developer might install without a second thought during a late-night coding session.
But the payload was anything but innocuous.
Once installed, the code first checked the machine’s IP address against geolocation databases. If the IP resolved to Iran, the malware activated its destructive payload: it began overwriting files with random data, effectively wiping the machine. Files critical to the operating system, user documents, project directories — all targeted. The destruction was thorough and, in most cases, irreversible without backups.
For machines outside Iran, the behavior was different but no less insidious. The malware scanned the local file system for other npm projects — specifically, it looked for node_modules directories and package.json files. When it found them, it injected itself into those projects’ dependency lists and modified the code to include its own malicious payload. If the developer then published any of those projects to the npm registry, the malware would ride along, reaching new machines, new developers, new organizations. Self-propagation through the trust developers place in each other’s code.
This is the part that has security professionals most concerned. Supply chain attacks typically follow a linear path: compromise a package, wait for people to install it, execute the payload. This attack added a recursive element. Every infected machine became a launchpad. Every compromised project became a new vector. The potential for exponential spread was real, even if the actual reach appears to have been limited — the packages were caught relatively quickly, accumulating a few hundred downloads before removal.
A few hundred downloads. That sounds small. It isn’t necessarily. A single download by a developer working on a widely used framework could cascade into thousands of downstream installations. And because npm’s dependency resolution is automatic and deeply nested, a poisoned package three or four layers deep in a dependency tree can be nearly invisible to the end user.
The geopolitical dimension adds another layer of complexity. Targeting Iran specifically suggests this wasn’t a financially motivated attack. There was no ransomware component, no cryptocurrency miner, no data exfiltration for sale on dark web markets. The wiper’s sole purpose was destruction. That pattern — destructive malware aimed at a specific nation-state — echoes the tactics seen in cyber operations attributed to state actors or politically motivated hacktivists. Researchers have not attributed the attack to any specific group or government, and doing so based on targeting alone would be speculative. But the intent is unmistakable.
Iran has been on both sides of destructive cyber operations for years. Stuxnet, the U.S.-Israeli operation that sabotaged Iranian nuclear centrifuges, remains the most famous example of a wiper deployed against Iranian infrastructure. More recently, Iranian-linked groups have been accused of deploying wipers against targets in the Middle East and beyond. The npm attack fits into this broader pattern of digital hostility, though its origins remain unclear.
What is clear is that the npm registry — and open-source package registries in general — remain stubbornly difficult to secure. npm hosts over two million packages. Developers download billions of packages per week. The registry operates on a model of implicit trust: anyone can publish a package, and the barrier to entry is essentially an email address. There are some safeguards. npm has implemented two-factor authentication for maintainers of popular packages, and automated scanning catches some malicious uploads. But the sheer volume makes comprehensive vetting impossible.
Socket, one of the firms that identified the malicious packages, has built its business around this exact problem. The company’s tools analyze packages for suspicious behaviors — things like network calls to unknown servers, file system access patterns inconsistent with a package’s stated purpose, or obfuscated code. In this case, Socket’s analysis flagged the geolocation check and the file-overwriting behavior as anomalous. But the self-propagation mechanism was sophisticated enough to evade some initial automated checks, according to researchers familiar with the investigation.
Reversing Labs provided additional technical analysis, breaking down the malware’s infection chain in granular detail. The propagation code specifically targeted the structure of npm projects, suggesting the author had intimate knowledge of how JavaScript developers organize their work. This wasn’t a crude script. It was carefully engineered.
And that’s what makes it so troubling.
The open-source software supply chain has been under increasing scrutiny since the SolarWinds attack in 2020, the Log4Shell vulnerability in 2021, and the XZ Utils backdoor discovered in 2024. Each incident revealed a different failure mode. SolarWinds showed that even proprietary build systems could be compromised. Log4Shell demonstrated that a single vulnerability in a ubiquitous library could threaten the entire internet. XZ Utils proved that a patient, years-long social engineering campaign could insert a backdoor into critical infrastructure software maintained by a single exhausted volunteer.
The npm wiper attack is different from all of these, yet it shares a common thread: the exploitation of trust. Developers trust that packages in the registry are what they claim to be. They trust that dependencies of dependencies have been vetted by someone. They trust that the open-source model’s transparency — anyone can read the code — provides a natural defense. But transparency only works if someone is actually reading the code. And with millions of packages and billions of downloads, no one is reading all of it. Not even close.
Industry responses have been incremental. GitHub, which owns npm, has invested in security features like package provenance attestations, which cryptographically link a published package to its source code and build process. The OpenSSF (Open Source Security Foundation), backed by major tech companies, has funded initiatives to improve the security of critical open-source projects. Google’s SLSA framework provides a maturity model for supply chain security. These are meaningful steps.
They’re also insufficient for the scale of the problem.
The fundamental tension is economic. Open-source software generates enormous value — estimates range into the trillions of dollars annually — but the maintainers who build and maintain it are often unpaid volunteers. Asking them to also serve as security gatekeepers is unrealistic. And the companies that profit most from open source have been slow to fund the infrastructure needed to secure it, though that’s gradually changing under regulatory and market pressure.
The European Union’s Cyber Resilience Act, which is being phased in, will impose new security requirements on software products sold in the EU, including those that incorporate open-source components. In the United States, executive orders on cybersecurity have pushed federal agencies toward software bills of materials (SBOMs) — detailed inventories of every component in a piece of software. The idea is that if you know what’s in your software, you can respond faster when something goes wrong.
But an SBOM wouldn’t have prevented this attack. Knowing that your project depends on a malicious package is useful only if you also know the package is malicious. And the whole point of these attacks is that the malicious packages look legitimate until someone — a researcher, an automated tool, a very attentive developer — spots the anomaly.
So where does that leave the industry? In a difficult position. The npm wiper attack was caught before it could spread widely, which is a success story of sorts. The security firms that identified it did their jobs. The packages were removed. Warnings were issued. But the attack demonstrated a capability — self-propagating malware in a package registry, with geopolitically targeted destruction — that is now a proven concept. Others will study it. Some will replicate it. The next version might be stealthier, more patient, harder to detect.
For developers, the immediate takeaways are familiar but worth repeating. Pin your dependencies to specific versions. Use lockfiles. Audit new dependencies before installing them. Be skeptical of packages with few downloads, recent creation dates, or names suspiciously similar to popular libraries — a technique known as typosquatting. Use tools like Socket or Snyk that perform behavioral analysis on packages. And if you maintain packages that others depend on, enable two-factor authentication and monitor for unauthorized changes.
For organizations, the calculus is broader. Supply chain security can’t be an afterthought. It requires investment in tooling, in processes, and in the people who understand how modern software is actually built — which is to say, assembled from thousands of components written by strangers on the internet. That reality isn’t going to change. The question is whether the defenses can evolve fast enough to keep up with the attacks.
The wiper in the npm registry was a warning shot. It was targeted, it was destructive, and it was clever. It exploited the same trust and openness that make open-source software so powerful. And it won’t be the last.
WebProNews is an iEntry Publication