An open-source maintainer was phished, enabling an attacker to push malware into 18 npm packages that are collectively downloaded 3 million times a week and used to create software in a million projects. Security firms monitoring the incident say the packages collectively receive more than 2 billion weekly downloads, highlighting how one compromised account can reverberate across the software supply chain.
The maintainers, identified as Josh Junon, said the attacker got in using an “incredibly convincing” 2FA phishing campaign that included faux branding and domain information. The bad releases were quickly flagged and pulled, but it’s a good reminder for all of us that the margin of error on a dependency-laden era of development is slim to none.
The Opening the Phishing Campaign Provided
Aikido Security writes that the attacker sent emails containing titles replicating registry notices and diverting the recipient to a corresponding lookalike domain established to capture credentials and one-time codes. From that toehold, the adversary unleashed tainted versions of popular modules used for tasks including styling text and handling fonts.
GitHub, which runs the npm registry, has tightened the requirements around when to apply multifactor authentication in recent years, yet well-executed phishing can elude defenses if users are pushed into real-time approvals. The lure was particularly convincing because it employed a deceptive domain, complete with official logos.
Scope and Real-World Impact
Aikido Security called the attack one of the biggest npm supply-chain compromises by package count, as well as by how fast it was downloaded once created in the target ecosystem, but early telemetry indicates a fairly small blast radius. Semgrep noted that the malicious versions were live for a short period of time and had no or minimal installs, according to npm telemetry, prior to the time of removal.
Projects would have had to have met a variety criteria to be impacted, in an effort to reduce further exposure, BleepingComputer said. The operation was characterized by security researcher Florian Roth as one with broad access but a payload that was relatively unsophisticated; it’s a reminder that even a low-skill intrusion can be high-impact when it infects a critical dependency.
What the Malware Attempted to Do
Analysis by Socket found the implants targeted the theft of cryptocurrencies from victim’s by hijacking browser-based transactions. The code in question would try to intercept and rewrite crypto addresses on the fly, routing payment to an attacker-controlled wallet — a low-level address-swapping scam that improbably spares the user from the more sophisticated exploit chains.
Compromised packages are commonly embedded deep in dependency trees, so the attacker probably went for scale over precision: seed a widely used utility, wait for automated builds to pull it in, and opportunistically skim value. The universal resentment and quick takedowns defanged that tactic.
Why This Is Relevant to Software Supply Chains
Open-source ecosystems centralize risk in a handful of maintainers with their modules rooted in giant dependency trees. Incidents such as the 2018 compromise of event-stream, the 2022 disruptions to colors/faker, the supply‐chain breach of 3CX, or the attempted backdoor of XZ Utils do show how trust can be quickly turned into a weapon.
It’s a lesson that is not dependent on any individual module, but rather on the fragile nature of transitive trust. A phished maintainer, a poisoned update, and a CI pipeline on autopilot can become how attackers get deliveries done—especially when teams pin in the loose, or don verify what they release.
What Teams Should Do Now
It Recommended developers using the libraries audit their dependency trees, lock files and build artifacts and, if affected packages are among those used — re-install from known-good sources. Rotate your tokens and credentials, clean up any CIs caches, and check your logs for anything suspect such as potentially rogue postinstall scripts or network calls in your build process.
For prevention, use hardware security keys for 2FA, use publisher provenance or signing where available, and use allowlisting for install scripts. Embrace multiple sources of intelligence – package registries, behavior-based scanners, runtime monitoring – and don’t singlehandedly count on one or an advisory feed.
Organizations like the Open Source Security Foundation continue to promote principles of SLSA-style build integrity, least privilege permissions for publishing tokens, and regular validation of dependency integrity. Community response time in this case was fast enough to contain damage; the next compromise may not be so lenient.
The takeaway is grim but actionable: attackers will continue to go after human maintainers because it works. The most solid approaches to prevent a standard upgrade from becoming an incident response is to reduce trust sprawl, harden publisher accounts and treat dependency updates as if they were code changes that need analysis.
