A meticulously crafted two-factor authentication phishing campaign has compromised a prominent npm maintainer’s account, pushing malicious updates to widely used packages and briefly putting massive portions of the JavaScript ecosystem at risk. The incident highlights how even 2FA can be sidestepped by attackers who understand developer workflows and deploy real-time social engineering.
How the 2FA phish worked
The maintainer, known as Josh Junon (qix), reported receiving a convincing “security notice” that spoofed an official npm support message. The email used a lookalike domain resembling npm’s real address and urged a 2FA “update,” steering the victim to a cloned login page. From there, attackers captured the username and password, requested a time-based one-time passcode (TOTP), and even attempted to enroll a fresh TOTP secret to maintain access.
Security researchers describe this as an adversary-in-the-middle technique: the attacker relays credentials and temporary codes to the real service in real time, defeating conventional 2FA that relies on TOTPs. It’s an increasingly common tactic seen across developer platforms and enterprise SSO portals because it yields persistent session cookies and immediate access to publishing capabilities.
What changed in the packages
According to Aikido Security, malicious versions were published to 18 npm packages associated with the compromised maintainer. Popular libraries reportedly included chalk, debug, ansi-styles, color-string, and simple-swizzle — projects that are deeply embedded in build pipelines, CLIs, and front-end tooling. Aikido’s analysis found that index.js files were altered to include obfuscated code designed to run in the browser.
The injected payload quietly intercepted crypto and web3 interactions, manipulated wallet prompts, and rewrote payment destinations to attacker-controlled addresses — all without obvious warnings to end users. In aggregate, those affected packages saw roughly 1.1 billion downloads in the prior week alone, underscoring the blast radius when a maintainer account is hijacked.
Scale and immediate impact
The npm ecosystem processes billions of weekly downloads, and foundational utilities like the ones targeted ripple through countless transitive dependencies. The malicious updates were quickly detected and yanked, and the maintainer’s account access has since been restored. npm stated that impacted versions were revoked to prevent further propagation.
Early signals suggest the campaign may not have been limited to a single maintainer. Junon warned that “other maintainers have been affected,” while Aikido Security indicated at least one additional target. That possibility raises the stakes: a coordinated wave of account takeovers could seed malicious code across multiple high-traffic libraries before detection.
Why 2FA wasn’t enough
TOTPs dramatically improve security over passwords, but they are phishable. If a user enters a code on a cloned site and the attacker relays it immediately, the barrier collapses. Phishing-resistant factors — such as hardware security keys or passkeys using WebAuthn — bind logins to the legitimate domain, making adversary-in-the-middle attacks far harder to pull off.
Session hardening also matters. Once an attacker obtains a valid session token, they can publish new releases without repeatedly re-authenticating. This is why the community has been pushing for additional layers like package signing, build provenance, and automated verification that code came from a trusted CI system rather than a local machine.
Steps maintainers should take now
– Rotate passwords and revoke all npm access tokens; treat every token used near the time of compromise as exposed.
– Switch from TOTP to phishing-resistant authentication where available, such as security keys or passkeys.
– Enable granular, least-privilege npm tokens and restrict publish rights to CI. Favor OIDC-based publishing and enable package provenance features that attest builds originated from your repository and workflow.
– Review recent releases for unexpected changes, especially obfuscated code, altered index.js entry points, and new postinstall scripts. Require independent review for any release that modifies install-time behavior.
– Communicate clearly with downstream users about affected versions and safe upgrade paths. Encourage pinning, lockfiles, and integrity checks to limit exposure.
A widening supply chain threat
The incident echoes prior supply chain compromises that leveraged maintainer accounts or build pipelines to distribute malicious code. From event-stream to ua-parser-js to destructive protestware episodes, the lesson is consistent: trust in open-source packages is foundational, but fragile.
Industry groups such as the Open Source Security Foundation have urged broader adoption of practices like SLSA build levels, code signing, and automated dependency risk scoring. GitHub and the npm team have introduced mandatory 2FA for high-impact maintainers and added provenance features to help consumers verify where a package was built. Those controls can’t eliminate phishing outright, but they can make a single compromised password far less catastrophic.
For now, the community response was swift, and the malicious versions are no longer available. The takeaway is equally clear. Attackers are investing in high-fidelity impersonation that targets the people who push code. Verifying domains, slowing down on urgent security prompts, and adopting phishing-resistant authentication are no longer optional — they’re the new baseline for protecting the software supply chain.