Largest NPM Compromise in History – Supply Chain Attack consequences of the QIX Account Takeover in debug and chalk

TL;DR: A phished maintainer account published malicious versions of core npm utilities used across the web (see original post bluesky and tracker post . The payload intercepts crypto addresses in browser sessions, rewriting transactions to attacker wallets. If your build pulled any of the versions below, treat it as a security incident. Tracked in Github here. 

Then shift from scanner-driven noise to ownership-driven, remediation-aware exposure management so you can contain incidents faster the next time.

What happened

A prolific npm maintainer confirmed their account was hijacked via a forged 2FA reset email sent from a spoofed domain: support@npmjs.help. The attacker pushed tainted releases of widely used packages (list below), then used browser-only interceptors to tamper with crypto transactions. BleepingComputer traced the credential exfiltration form to a public VM endpoint and documented the phishing lure content in detail, including the “your account will be locked on September 10, 2025” scare line. Aikido’s analysis explains how the injected index.js acts as a web-layer interceptor and rewrites wallet destinations across Ethereum, Bitcoin, Solana, Tron, Litecoin, and Bitcoin Cash before signatures occur. GitHub issues from impacted projects corroborate the compromised versions and show maintainers racing to roll back and republish. 

Bleeping Computer: https://www.bleepingcomputer.com/news/security/hackers-hijack-npm-packages-with-2-billion-weekly-downloads-in-supply-chain-attack/ 

Key, verifiable signals from public sources:

• Maintainer statement: “It was a 2FA reset email… slipped past me… I’m locked out of my npm account.” The list of affected versions appears in the same thread.
  
• Phish domain and exfil URL observed: npmjs[.]help and https://websocket-api2[.]publicvm.com/… used to steal credentials.
  
• Payload behavior: browser-only interceptor changing wallet destinations; not a Node-only runtime payload.
• other domain compromise / Phishing npmjs.help
• The phishing domain once resolved to 185.7.81.108, but is no longer accessible.
• Victims were redirected to a fake settings page at https://www.npmjs[.]help/settings/qix/tfa/manageTfa?action=setup-totp.
• The page loaded malicious scripts from attacker-controlled BunnyCDN buckets:

What is the impact on me/you?

This is a bit of the question we asked after the initial assessment, on one end the fixes were super fast

At around 9:30 AM ET, an attacker compromised all packages published by Qix, including extremely popular packages such as chalk and debug-js. On the same day, the packages were recalled. This is to be celebrated, very fast reaction, thanks to the early notification from Aikido Security to the maintainer. Collectively, these libraries account for over 2 billion downloads per week, making this the largest supply chain attack in history.

Despite the scale, the attacker has stolen very little:

• Roughly $0.05 in ETH
• About $20 in a low-volume memecoin

The real damage is operational:

• Thousands of engineering and security hours wasted cleaning up build pipelines.
• Millions of dollars in scanning and services will follow /assessment, hence why we open source our scanner for this: https://github.com/Security-Phoenix-demo/Qxi-npm-compromise-checker
• Another stark reminder that registry trust is brittle and can collapse with a single phished maintainer.

Affected packages and versions (as declared by the maintainer)

• ansi-styles@6.2.2
  
• debug@4.4.2
  
• chalk@5.6.1
  
• supports-color@10.2.1
  
• strip-ansi@7.1.1
  
• ansi-regex@6.2.1
  
• wrap-ansi@9.0.1
  
• color-convert@3.1.1
  
• color-name@2.0.1
  
• is-arrayish@0.3.3
  
• slice-ansi@7.1.1
  
• color@5.0.1
  
• color-string@2.1.1
  
• simple-swizzle@0.2.3
  
• supports-hyperlinks@4.1.1
  
• has-ansi@6.0.1
  
• chalk-template@1.1.1
  
• backslash@0.2.1
  

Note: Some packages were yanked quickly; do not assume “missing bad version” means safety. Validate your lockfiles and any cached artifacts pulled during the window. 

Why does this incident bites deep

Every product that renders text in a terminal, formats console output, or inspects strings likely touches one or more of these packages transitively. That reach turns one phished maintainer into a planet-scale blast radius—and that’s before counting caches, CI mirrors, or internal registries.

The kicker: the payload focuses on the browser. Many teams saw “Node runtime seems fine” and relaxed. Then they remembered their webpack/Vite/Rollup pipelines happily ship transitive utilities to the front end.

This is the modern reality for vulnerability management in the JavaScript ecosystem: dependency trees are dense, code moves from code to container to browser in minutes, and attackers optimize for reachability and user proximity.

This follows previous attacks in July, when attackers compromised eslint-config-prettier, a package with over 30 million weekly downloads, while in March, ten other widely used npm libraries were hijacked and turned into info-stealers.

Immediate response playbook for engineering leaders

Detect if you got the malware version: Made a quick script that will run npm cache ls on every affected package and will tell you if you pulled any vulnerable version. 

For a quick scanner and verification tool, refer to: https://github.com/Security-Phoenix-demo/Qxi-npm-compromise-checker 

other IOC to be aware (especially in crypto cybersecurity)

IOC Summary

• Domains: npmjs[.]help, websocket-api2.publicvm[.]com
• Wallets: 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976, 19111111111111111111111111111111
• Packages: chalk, debug, ansi-styles, ansi-regex, strip-ansi, supports-color, wrap-ansi, color-convert, color-name, color-string, simple-swizzle, chalk-template, backslash, and others.

Quick Usage

Option 1: Shell Script (Fast)

# Scan current directory

./quick_check.sh

# Scan specific directory

./quick_check.sh /path/to/your/project

Option 2: Python Tool (Comprehensive)

# Install Python 3.7+ first, then:

# Scan current directory

python3 npm_compromise_detector.py

# Scan specific directory with full options

python3 npm_compromise_detector.py /path/to/project –output report.txt –check-cache

# Quiet mode (only show critical findings)

python3 npm_compromise_detector.py –quiet

Alternative steps : 

1. Freeze dependency resolution.
   
   • Lock to last-known-good yarn.lock, package-lock.json, or pnpm-lock.yaml.
     
   • Enforce overrides/pins to safe versions across workspaces. (Yarn v1 supports “resolutions”, npm supports “overrides”.)
     
   • If you rely on CI caching, purge it.
     
2. Scan for the exact compromised versions and known IOC URLs using the detection tool below.
   
3. Rebuild with pinned versions and redeploy.
   
   • If your app ever handled crypto flows, rotate secrets and audit on-chain transactions during the exposure window.
     
   • Add response headers (CSP/SRI) to limit future script tampering paths.
     
4. Instrument your metrics.
   
   • Track SLA/SLO non-compliance by severity and MTTR from “team informed”—two metrics that keep you honest on both the macro and the micro. Community veterans consistently prioritize them for real-world signal over vanity counts. (Shoutouts to Matt Boddy on SLA/SLO + MTTR, James Berthoty and Chris Romeo on “time since informed,” and Katie Norton on escape rate and density.)
     
   • Avoid tallying “# of critical CVSS fixed” as your north star; it rewards volume, not risk reduction.
     

How the Malware Works (Step by Step)

1. Injects into the browser

The malicious code ships inside compromised npm packages. Once bundled into front-end builds, it hooks into browser primitives like fetch, XMLHttpRequest, and wallet APIs (window.ethereum, Solana, Tron, etc.). This guarantees visibility over both web traffic and crypto wallet activity.

2. Watches for sensitive data

With hooks in place, the malware continuously scans network responses and transaction payloads. It recognizes wallet formats for Ethereum, Bitcoin, Solana, Tron, Litecoin, and Bitcoin Cash. Anything that resembles a transfer request or crypto address is flagged.

3. Rewrites the targets

When a transaction is spotted, the payload silently replaces the real destination with an attacker-controlled address. Lookalike patterns are often used so the swapped address still resembles the original, lowering the chance of human detection.

4. Hijacks transactions before signing

The exploit manipulates transaction parameters—recipients, approvals, allowances—before the wallet signs them. Even if the UI appears correct, the signed message ultimately routes funds to the attacker.

5. Stays stealthy

To avoid detection, the malware suppresses obvious anomalies in the UI. Silent hooks keep running in the background, quietly intercepting and rewriting data without raising alerts.

What this says about DevSecOps & ASPM maturity

Attackers exploited human trust, registry trust, and transitive trust in one move. Tooling that fires off a million “Critical” alerts does little when minutes matter.

Teams that performed best in similar events share a pattern:

• Ownership & Attribution: they can tell “who owns what, where” in seconds.
  
• Contextual correlation: they tie code, containers, cloud, and runtime exposure in one view.
  
• Remediation-aware exposure management: they route the right fix to the right team, first time—and track its completion against SLAs.
  

That’s exactly the operating model Phoenix Security customers use: precise team ownership, code-to-cloud mapping, and agent-assisted remediation on top of deduplicated, prioritized vuln sets. Case studies from fintech and retail show double-digit to near-total reductions in active container risk and massive productivity wins when you eliminate noise and direct action to owners.

Prevention checklist for npm teams

• Adding malware scanning capabilities link to analysis post: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised
• Guardrail coverage beats heroics.
  • Unified allow/deny lists for registry domains; deny typosquats like npmjs.help/npnjs.com. (Multiple phishing waves used such domains in 2025.)   
  • Enforce publish-time 2FA and monitor for unusual publish metadata/diff sizes.
  • Mirror + quarantine: new versions wait in a staging registry until automated checks pass.
• Code-to-cloud lineage + reachability.
  • Trace which libraries ship to browser bundles and are actually reachable at runtime; don’t waste hours on artifacts that never load. Phoenix customers cut active container vulns by 78–98% by slicing out inactive/stale images and duplicates.
• Ownership-by-default.
  • Tie every app, service, and container to a team and a remediation workflow. Phoenix’s team inheritance and “who does what, where” mapping short-circuit the blame game and accelerate the handoff to the actual fixers.
• Agent-assisted remediation, not agent-generated noise.
  • Phoenix AI Agents (Researcher, Analyzer, Remediator) operate after data is deduped and contextualized, so you get precise campaigns, not more triage.

FAQ / Updates

Was Node-only code execution impacted?

The injected payload targets browser contexts and leverages web APIs; multiple analyses indicate it does not execute in pure Node environments. Validate your bundlers, nevertheless, because many utilities cross the boundary. 

How can I prevent this and similar npm compromises?

In short, apply good hygiene, pinning the versions, and be aware of potential compromise. Full details

1. Registry Hygiene & Controls to prevent NPM compromise

• Pin dependencies to exact versions and lockfiles (yarn.lock, package-lock.json, pnpm-lock.yaml).
• Mirror npm packages internally and enforce a quarantine period before promoting new versions.
• Deny or flag external calls to typosquat domains (npmjs.help, npnjs.com).

2. CI/CD Guardrails to prevent NPM compromise

• Add pre-build checks to scan for known IOCs (domains, wallet addresses, regex signatures).
• Require cryptographic signing for critical dependencies.
• Enable SLSA or Sigstore verification for provenance tracking.

Which domains are indicators of compromise?

At minimum: npmjs.help (phish delivery) and websocket-api2.publicvm.com (credential exfiltration). Search code, build artifacts, and logs for hits. 

How do we know if we pulled a bad version?

Check your lockfiles and CI cache timestamps; use the script above; compare against your artifact store and SBOMs.

What should we measure post-incident?

SLA/SLO breach by severity and MTTR from “team informed,” plus escape rate and density to improve your SDLC.

Related sources

• Incident summary, IOC URL, crypto-interceptor behavior, package list & volumes. 
• Maintainer confirmation and affected versions, ongoing updates. 
• Malware analysis Post

Get on top of your code and container vulnerabilities with Phoenix Security Actionable ASPM

Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.

Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis. This innovative approach correlates runtime data with code analysis to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues. Why do people talk about Phoenix

• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.

• Contextual Deduplication: Utilizing canary token-based traceability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.

• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.

Get on top of your code and container vulnerabilities with Phoenix Security Actionable ASPM powered by AI-based Reachability Analysis

Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.

Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis. This innovative approach correlates runtime data with code analysis to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues.

Why do people talk about Phoenix?

• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.

• Contextual Deduplication with reachability analysis: Utilizing canary token-based traceability for network reachability and static and dynamic runtime reachability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.

• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.