On September 8, 2025, a maintainer’s npm account was phished and used to publish malicious versions of widely used packages (including debug and multiple packages in the chalk ecosystem). The injected code appears designed to execute in the browser, hooking web APIs to silently rewrite cryptocurrency addresses and wallet interactions, while being largely inert in pure Node.js/server contexts. npm and maintainers have since removed/overwritten the tainted versions and begun account recovery, but organizations that installed these versions during the exposure window should assume user-browser impact is possible, audit build artifacts, and rotate secrets where appropriate.

What component was compromised?

• Maintainer account takeover: The attacker tricked the maintainer (Qix-) with a high-quality phishing email impersonating npm support (domain npmjs[.]help) and gained the ability to publish new versions directly to the npm registry without source-repo changes.
• Registry-only poison: At least one malicious publish (debug@4.4.2) did not match the GitHub repo, indicating a registry-side publish from the compromised account/token rather than a code PR.

Known timeline (all dates 2025)

This incident is evolving; times below reflect currently available public reports.

• Sep 8 ~09:00–11:30 ET (13:00–15:30 UTC | 16:00–18:30 IDT): Window when malicious versions were available and installs could have pulled them. Multiple packages were yanked/overwritten shortly afterward.
• Sep 8: Community reports flag debug@4.4.2 as compromised; issue opened in the debug repo.
• Sep 8 (later): chalk maintainer publishes fixed releases (e.g., chalk@5.6.2) to overwrite the compromised builds; related packages get patched bumps.
• Sep 8–9: News outlets report npm’s takedown of malicious versions and summarize the phishing vector and browser-side payload behavior.

Impacted packages & versions (initial set)

The following versions were reported as malicious during the window (now removed/overwritten). Treat as evolving; verify against the package page and GHSA/OSV entries:

• debug@4.4.2
• chalk@5.6.1 (patched as 5.6.2)
• supports-hyperlinks@4.1.1, chalk-template@1.1.1, slice-ansi@7.1.1, wrap-ansi@9.0.1, has-ansi@6.0.1, strip-ansi@7.1.1, ansi-styles@6.2.2, supports-color@10.2.1, ansi-regex@6.2.1, plus additional Qix-maintained packages in the color/ansi family (e.g., color-convert@3.1.1, color-name@2.0.1, color-string@2.1.1, is-arrayish@0.3.3, simple-swizzle@0.2.3, backslash@0.2.1). See in-progress GHSA tracking.

Who is likely affected?

Web apps that installed or rebuilt during the exposure window and shipped bundles that include the tainted versions to browsers. BleepingComputer summarizes additional criteria (fresh install during the window, lockfile created then, vulnerable transitives). Server-only consumers may be less exposed since the payload tries to run in a window context.

How the attack worked (current understanding)

1. Phishing & account control The attacker used a convincing npm support email from support@npmjs.help to capture credentials/2FA reset, then published new versions under the maintainer’s authority.

2. Registry publish without repo changes Malicious packages were pushed to npm even though the GitHub source did not contain the changes (classic registry-only supply-chain poison).

3. Browser-side interceptor payload The injected code obfuscates strings and hooks fetch, XMLHttpRequest, and common Web3 wallet APIs (e.g., window.ethereum) to detect/replace crypto recipients and approvals with attacker-controlled addresses. This appears to target frontend usage rather than Node-only execution.

How npq could have prevented this attack

The npq security auditing tool that I built a decade ago provides pre-installation package verification that could have significantly mitigated this supply-chain attack from harming end users (not the maintainer).

Here’s how npq’s security marshalls would have flagged the malicious packages:

1. Age-based detection

npq’s Age Marshall warns about packages published within 22 days, which would have immediately flagged all malicious versions published on September 8:

$ npq install debug@4.4.2
Packages with issues found:
┌─
│ >  debug@4.4.2
│
│ ✖ Supply Chain Security · Detected a recently published version: published 1 day ago
└─
Continue install ? (y/N)

Would you have installed the package? I hope not! If you did, then you took the risk knowingly.

But how would you have known about this? if you had only relied on npm or pnpm or yarn, you would have had no idea that the package was freshly published and potentially suspicious. If you had used npq, you would have been warned and given the chance to abort the installation.

2. Version maturity checks

The version-maturity marshall provides an additional layer by warning about specific versions published within 7 days, catching freshly published malicious releases:

$ npq install chalk@5.6.1
│ ⚠ Supply Chain Security · Recently published version detected: published 6 hours ago

3. Registry integrity verification

npq’s signature and provenance verification would have detected the registry/repository discrepancy that characterized this attack:

• Signature verification: Validates npm registry signatures for published packages
• Provenance verification: Checks build attestations to ensure packages were built from the expected source repository

Since the malicious versions were published directly to the registry without corresponding source changes, these checks would likely have failed or shown mismatches.

4. Interactive security gates

Unlike automated package managers, npq forces explicit user decision-making when security issues are detected:

• Errors halt installation until user explicitly chooses to proceed
• Warnings trigger countdown with abort options, preventing automatic installation of suspicious packages
• Clear security context helps users make informed decisions

5. Ecosystem-wide protection

If organizations had adopted npq as their primary package installation tool (via aliases like alias npm='npq-hero'), the attack’s impact would have been dramatically reduced:

• Fresh installs during the exposure window would have been flagged and required manual approval
• CI/CD pipelines using npq would have halted on security warnings
• Developer awareness would have been raised immediately upon installation attempts

Deployment recommendations

To protect against similar future attacks, consider:

# Install npq globally
npm install -g npq
# Alias your package manager to use npq
alias npm='npq-hero'
alias yarn='NPQ_PKG_MGR=yarn npq-hero'
alias pnpm='NPQ_PKG_MGR=pnpm npq-hero'
# Enable all security features (default behavior)
npq install <package>  # Includes age, signature, provenance checks

Note: While npq significantly improves security posture, it works best as part of a defense-in-depth strategy including lockfile usage, SCA scanning, and secure development practices.

Why this matters (ecosystem takeaways)

• Registry/source drift: Attackers exploited the gap between GitHub and the registry: published code ≠ repo code. Teams must verify what’s actually in the tarball (e.g., provenance/signatures and SBOM verification), not just the repo diff.
• Browser is a juicy target: Even “utility” libs can end up in front-end bundles; poisoning them lets attackers man-in-the-browser at scale.
• Defense in depth for publishers: Strong 2FA requirements, tokenless CI publishing, and rapid revocation paths reduce blast radius (but social-engineering remains a risk).
• Pre-installation auditing is critical: Tools like npq that audit packages before installation can prevent malicious code from ever reaching your systems, especially for freshly published or suspicious releases.y download users”

Detection & triage

A. Identify if you consumed bad versions

• Check lockfiles and installs during Sep 8 ~09:00–11:30 ET (13:00–15:30 UTC | 16:00–18:30 IDT). Search your repos and CI logs for the exact versions listed above.
• Run npm ls <pkg> or pnpm why <pkg> / yarn why <pkg> across services to reveal transitive usage paths.

B. Inspect built artifacts shipped to browsers

• Examine production bundles (source maps where available) for obfuscated JS patterns typical of low-effort obfuscators (e.g., long hex arrays with _0x index decoders and numeric lookups). This is a heuristic, not a signature. (See news analysis indicating a browser-hooking interceptor.)

C. IOC hints (from public reporting)

• Phishing domain: npmjs[.]help.
• Credential exfil path observed by reporters: https://websocket-api2[.]publicvm.com/images/jpg-to-png.php?... Use your proxy/DNS logs to look for egress to that host during developer logins.

D. SCA/Advisory references

• Track GHSA issues that are being filed/updated for impacted packages to drive alerts in GitHub/OSV/SCA tools.

1. Pin & rebuild safely

   • Blocklist the malicious versions in your internal registry or with package-resolution overrides.
   • Upgrade to fixed releases where available (e.g., chalk@5.6.2 and related) and rebuild artifacts.

2. Lock down installs

   • Enforce lockfiles + reproducible installs (npm ci, pnpm install --frozen-lockfile, yarn install --immutable) to prevent surprise minor bumps.
   • Consider save-exact=true for critical apps and explicit resolutions for risky transitive trees.

3. Rotate secrets if exposure is plausible

   • If developer workstations or build agents executed unknown scripts or built bundles that ran in browsers of sensitive operators, rotate tokens/keys and audit auth logs. (Some advisories take a “assume compromise” stance for malware installs; use your risk threshold.)

4. Harden maintainer security (for orgs that publish)

   • Require 2FA for publishing & settings across all packages; prefer trusted publishing / OIDC for CI to reduce token sprawl. (Note: while OIDC mitigates token theft, it doesn’t prevent social-engineering of an account; layered controls still required.)

5. Use pre-installation security auditing

   • Install and configure npq to audit packages before installation: npm install -g npq && alias npm='npq-hero'
   • Enable all security marshalls (age, signature, provenance verification) to catch future supply-chain attacks
   • Consider organizational policies requiring security auditing tools for package installation

6. Report sightings

   • If you encounter additional suspicious versions, report malware to npm Security via the official process.

Why this matters (ecosystem takeaways)

• Registry/source drift: Attackers exploited the gap between GitHub and the registry: published code ≠ repo code. Teams must verify what’s actually in the tarball (e.g., provenance/signatures and SBOM verification), not just the repo diff.
• Browser is a juicy target: Even “utility” libs can end up in front-end bundles; poisoning them lets attackers man-in-the-browser at scale.
• Defense in depth for publishers: Strong 2FA requirements, tokenless CI publishing, and rapid revocation paths reduce blast radius (but social-engineering remains a risk).

Current status (as of Sep 9, 2025, IDT)

• Multiple malicious versions were removed/overwritten; at least the chalk family has fixed releases (e.g., 5.6.2). The debug malicious version (4.4.2) has been removed from npm. Continue to monitor GHSA/OSV and package pages for authoritative version guidance.

Appendix: quick operator checklist

1. Freeze deploys that include debug / chalk family until verified clean.
2. Verify no builds pulled the listed versions during Sep 8 window.
3. Rebuild with pinned, patched versions; republish frontend bundles.
4. Rotate secrets/tokens if developer or CI machines likely executed tainted code.
5. Search logs for npmjs[.]help phish and publicvm.com egress; block and alert.

References & further reading

This write-up consolidates public reporting and maintainer statements available at publish time. Continue tracking upstream issues/advisories for updates.