1,700 Malicious npm & PyPI Packages: How to Protect Your Code

In April 2026, the software development community faced one of the most widespread npm supply chain attacks ever documented. Over 1,700 malicious packages were identified across the world's most popular open-source registries, including npm (JavaScript/Node.js), PyPI (Python), the Go module proxy, crates.io (Rust), and Packagist (PHP). The campaign, linked to North Korean state-sponsored threat actors, targeted the one resource every modern development team relies on: third-party dependencies.

Unlike a ransomware attack that locks files or a phishing email that fools a single user, a supply chain attack compromises the very foundation of the software you build and ship. When a developer installs a malicious package, the attacker gains access to that developer's environment — credentials, source code, CI/CD pipelines, cloud accounts, and potentially the production systems that package eventually runs in. This is why this npm supply chain attack demands immediate attention from every engineering team, security professional, and CTO in Canada and beyond.

This guide covers everything: what happened, who is behind it, how the attack works technically, which specific packages are affected, and a step-by-step playbook for detection, remediation, and long-term prevention.

1. What Happened: The Scale of the April 2026 Supply Chain Attack

The discovery was made by multiple independent security firms — Socket.dev, Checkmarx, and Phylum — who independently flagged unusual publication patterns on npm and PyPI in late March 2026. Cross-referencing their findings revealed a coordinated, multi-registry npm supply chain attack of a scale not previously seen in a single campaign.

The breakdown by registry was as follows:

Registry	Packages Affected	Primary Technique	Severity
npm (Node.js)	~820 packages	Typosquatting + dependency confusion + maintainer account takeover	Critical
PyPI (Python)	~610 packages	Typosquatting + malicious postinstall scripts	Critical
Go Module Proxy	~180 modules	Domain name squatting of abandoned module paths	High
crates.io (Rust)	~65 crates	Typosquatting of popular Rust crates	High
Packagist (PHP)	~45 packages	Dependency confusion targeting Laravel/Symfony ecosystems	Medium

The npm registry bore the brunt of the attack for a simple reason: npm has the lowest barrier to publication. A developer can create an account and publish a package in under five minutes, with no mandatory code review or malware scanning before publication. This is a structural vulnerability that has been exploited in previous supply chain attacks including the 2021 ua-parser-js compromise and the 2022 node-ipc incident, but never at this volume.

What distinguishes this npm supply chain attack from those earlier incidents is the use of multiple simultaneous attack vectors working in concert. Attackers did not rely solely on typosquatting (publishing "axois" to catch developers who mistype "axios"). They combined it with dependency confusion — exploiting how corporate npm registries resolve package names — and direct account compromises of legitimate maintainers with weak or reused passwords.

The Axios Compromise: A Notable Variant

The most technically sophisticated element of this supply chain attack was what researchers termed the "Axios compromise variant." Rather than registering a lookalike package, attackers gained access to a contributor account for a package that extends the popular Axios HTTP library. They submitted what appeared to be a legitimate performance optimization pull request. The PR passed automated tests because the malicious code was dormant — it only activated when the installed package detected a CI/CD environment variable pattern consistent with a production deployment pipeline.

This sleeping-payload technique allowed the malicious code to evade standard npm audit checks and static analysis tools that only examine code at publish time. The malicious postinstall hook would silently exfiltrate environment variables (which in a CI/CD context often contain AWS keys, deployment tokens, and database credentials) to an attacker-controlled endpoint disguised as a telemetry service.

2. Who Is Behind It: North Korea's UNC1069 / BlueNoroff

Attribution in cybersecurity is always probabilistic, but in this case the evidence is unusually strong. Multiple threat intelligence firms — Mandiant (Google Cloud), CrowdStrike, and the Recorded Future Insikt Group — have independently attributed the April 2026 npm supply chain attack to UNC1069, a threat cluster also tracked as BlueNoroff, Sapphire Sleet, and TA444.

BlueNoroff is a financially motivated subgroup of the notorious Lazarus Group, which operates under North Korea's Reconnaissance General Bureau (RGB). While Lazarus Group is known for high-profile attacks like the 2014 Sony Pictures hack and the $81 million Bangladesh Bank heist, BlueNoroff has carved out a specialty in targeting financial institutions, cryptocurrency exchanges, and increasingly, software developers who have access to crypto wallet infrastructure.

The Contagious Interview Connection

The April 2026 supply chain attack is the latest and largest escalation of the Contagious Interview campaign, which North Korea hackers began in earnest in late 2023. The modus operandi of Contagious Interview is deceptively simple: North Korea hackers create fake recruiter profiles on LinkedIn, Upwork, and GitHub, then approach software developers with attractive job opportunities. During the "technical interview" phase, the target is asked to complete a coding challenge that requires installing a specific npm package or cloning a GitHub repository. That package or repo contains the malware.

Contagious Interview has been documented targeting developers in Canada, the United States, the United Kingdom, India, and South Korea. The April 2026 campaign represents a significant evolution — rather than requiring individual targeting of each victim, publishing malicious packages to public registries allows passive infection of any developer who happens to install the package.

The technical indicators linking this npm supply chain attack to BlueNoroff include:

• C2 infrastructure overlap: Command-and-control domains used by the malicious packages share registration patterns and ASNs with previously attributed BlueNoroff infrastructure
• Malware family continuity: The RAT (Remote Access Trojan) payload matches BeaverTail and InvisibleFerret malware families previously attributed to Contagious Interview
• Target profile: Victim telemetry from the C2 infrastructure shows disproportionate targeting of developers at cryptocurrency exchanges, DeFi platforms, and fintech companies
• Operational timing: Publication of malicious packages correlates with North Korean working hours (UTC+9), with a notable absence of activity during DPRK national holidays

The ultimate goal of this North Korean-linked supply chain attack, as with previous BlueNoroff operations, is cryptocurrency theft to fund the DPRK's weapons programs. UN Panel of Experts reports estimate that North Korea hackers have stolen over $3 billion USD in cryptocurrency between 2022 and 2025 alone.

3. How the npm Supply Chain Attack Works Technically

Understanding the technical mechanics of this supply chain attack is essential for building effective defenses. The campaign used three distinct infection vectors, often layered together for redundancy.

Vector 1: Typosquatting and Combosquatting

The most common technique in this npm supply chain attack was registering packages with names designed to fool inattentive developers. This included:

• Classic typosquatting: One-character transpositions or substitutions (e.g., chal-k for chalk, lodahs for lodash)
• Prefix/suffix additions: Adding "-utils", "-helper", "-fix", or "-patch" to legitimate package names
• Scope confusion: Publishing packages that mimic scoped packages without the scope (e.g., storybook-react instead of @storybook/react)
• Combosquatting: Combining two legitimate package names to create a plausible-sounding but malicious one (e.g., axios-lodash)

Vector 2: Dependency Confusion

Dependency confusion is a more sophisticated attack against organizations that use private npm registries (e.g., Artifactory, Verdaccio, GitHub Packages). The attack exploits the default behavior of npm when a package name exists in both a private registry and the public npm registry: npm installs the public version with the higher version number.

Attackers research internal package names — often exposed in error messages, job postings, or accidentally committed package.json files — then publish public packages with those names at a very high version number (e.g., version 99.0.0). When a developer or CI/CD pipeline runs npm install, npm fetches the attackers' malicious public package instead of the intended private one.

Vector 3: Malicious Postinstall Hooks

All three variants of the malicious packages in this supply chain attack used npm's postinstall lifecycle hook to execute malware. This hook runs automatically when a package is installed — no user interaction required beyond typing npm install. The malicious postinstall scripts performed the following steps:

4. Affected Packages: The Malicious Packages List

The following table lists confirmed high-risk packages from this supply chain attack. This is a partial list — the full IOC database is maintained by Socket.dev, GitHub Security Advisories, and the npm security team. Always cross-reference the latest sources as new packages continue to be discovered.

Package Name	Registry	Mimics	Threat Type
axios-node-adapter	npm	axios	Credential theft + RAT
node-fetch-polyfill	npm	node-fetch	Credential theft
lodash-utils-extra	npm	lodash	Credential theft + RAT
chal-k	npm	chalk	Infostealer
react-hooks-utils	npm	react / react-hooks	Credential theft + RAT
express-middleware-pack	npm	express	Backdoor
dotenv-expanded-utils	npm	dotenv-expand	Env variable exfiltration
jsonwebtoken-helper	npm	jsonwebtoken	JWT secret theft
requests-extra	PyPI	requests	Credential theft + RAT
boto3-utils	PyPI	boto3	AWS credential theft
pydantic-extra-types-fix	PyPI	pydantic-extra-types	Infostealer
fastapi-security-utils	PyPI	fastapi-security	Backdoor
cryptography-helpers	PyPI	cryptography	Crypto wallet theft

For the most current and complete list of malicious packages identified in this supply chain attack, consult these live threat intelligence resources:

• Socket.dev Threat Feed: socket.dev/npm/issue/malware
• GitHub Advisory Database: github.com/advisories (filter by "malware" + "npm")
• npm security advisories: docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities
• PyPI Security Advisories: pypi.org/security
• CISA Known Exploited Vulnerabilities Catalog: cisa.gov/known-exploited-vulnerabilities-catalog

5. How to Check If You Are Affected

The first priority after learning about this npm supply chain attack is determining whether your projects or developer machines are compromised. Here is a systematic approach.

For Node.js / npm Projects

Run the following in each project directory:

# Check for known vulnerabilities in your dependency tree
npm audit

# Get a detailed JSON report for programmatic processing
npm audit --json > audit-report.json

# Check for outdated packages (may reveal suspicious version jumps)
npm outdated

# List all installed packages with exact versions
npm list --all --depth=0

npm audit queries the npm security advisory database and will flag any packages that have been officially reported as malicious. However, it only covers packages that have been formally reported — newly published malicious packages may not yet be in the database. This is why a multi-tool approach is essential for this supply chain attack.

For Python / PyPI Projects

# Install pip-audit if not already installed
pip install pip-audit

# Audit your current environment
pip-audit

# Audit a specific requirements file
pip-audit -r requirements.txt

# Audit a Pipfile
pip-audit --requirement Pipfile

Inspecting postinstall Scripts Manually

For any package you are suspicious of, examine its package.json for lifecycle scripts before installing:

# View package metadata without installing
npm view <package-name> scripts

# To read the postinstall script before it runs, pack the tarball:
npm pack <package-name>
tar xzf <package-name>-*.tgz
cat package/scripts/install.js

Any postinstall script that makes outbound network requests, reads from ~/.ssh, ~/.aws, or ~/.npmrc, or spawns child processes using exec or spawn with obfuscated arguments should be treated as malicious.

6. Detection Tools for Supply Chain Attacks

Protecting against this class of npm supply chain attack requires tools that go beyond what the default package manager provides. The following tools are recommended for development teams of all sizes.

Tool	Type	Best For	Cost
Socket.dev	Proactive supply chain security	Detecting malicious packages before install via GitHub PR analysis; catches behavior like network access in install scripts, obfuscated code, and new maintainers	Free tier available; paid plans for teams
Snyk	SCA + license compliance	CI/CD integration, developer-friendly fix PRs, both known CVEs and supply chain threats	Free for open source; paid for private repos
npm audit	Vulnerability scanning	Baseline check against the npm advisory database; built into npm 6+	Free (built-in)
pip-audit	Python dependency scanning	Scanning Python environments against the OSV and PyPA advisory databases	Free (open source)
Dependabot	Automated dependency updates	GitHub-native; automatically creates PRs when dependencies have known vulnerabilities	Free on GitHub
OSSF Scorecard	Package health scoring	Assessing the security posture of open-source dependencies (maintenance activity, signed releases, code review practices)	Free (open source)
Phylum CLI	Package origin analysis	Deep behavioral analysis of packages; detected 60%+ of this campaign's packages before npm official advisories	Free tier; paid for enterprise

7. Immediate Remediation Steps

If you have confirmed or suspect that a malicious package from this supply chain attack was installed in your environment, follow these steps immediately. Do not delay — credential exfiltration happens within seconds of package installation, and the longer you wait, the more damage an attacker can do with stolen credentials.

8. Prevention Best Practices for Developers

The most effective defense against npm supply chain attacks is building prevention into your development workflow before a malicious package ever reaches your codebase. The following practices, applied consistently, dramatically reduce your exposure.

Lock Your Dependency Tree

Always commit your lock files (package-lock.json, yarn.lock, Pipfile.lock) to version control and always install from the lock file in CI/CD. Use npm ci instead of npm install in automated pipelines — npm ci installs exactly what is in the lock file and fails if there are any discrepancies, preventing dependency confusion attacks from substituting a different package.

# In CI/CD, always use:
npm ci

# Not:
npm install

Enable Package Signature Verification

npm introduced package provenance attestations in 2023. For packages that support it, you can verify that a package was built from a specific GitHub Actions workflow and commit:

# Verify provenance for all installed packages
npm audit signatures

# This checks that installed packages were built from
# their stated source repositories using verified CI systems

Disable postinstall Scripts During Install

The --ignore-scripts flag prevents npm from running lifecycle scripts (including the malicious postinstall hooks used in this supply chain attack) during installation. For packages that genuinely need postinstall scripts (native module builds, etc.), review the scripts manually before running them:

# Install without running postinstall scripts
npm install --ignore-scripts

# For Yarn:
yarn install --ignore-scripts

Audit New Dependencies Before Adding Them

Before adding any new npm or PyPI dependency, spend two minutes on due diligence:

• Check the package's npm page: when was it first published? Does the maintainer account look legitimate?
• Verify the weekly download count — a package claiming to be a popular utility but with under 100 weekly downloads is suspicious
• Check the GitHub repository: does it have a real commit history? Are there real contributors?
• Look at the package.json scripts section: does it have a postinstall, preinstall, or install script? If so, read it carefully
• Run the package name through Socket.dev's package inspector (socket.dev/npm/package/<name>) for a free security score

Configure a Private Registry with Scope Restrictions

If your organization uses internal packages, configure your npm registry to require explicit scoping for internal packages and block public resolution of those names. In your .npmrc:

# Force all @company-scope packages through your private registry
@company-scope:registry=https://your-private-registry.example.com

# Enable authentication for all requests to prevent dependency confusion
always-auth=true

9. Enterprise Dependency Management

For organizations with multiple development teams, a single infected developer machine can cascade into a much larger incident if proper enterprise controls are not in place. The following recommendations address dependency management at the organizational level.

Implement SCA Scanning as a Hard Gate in CI/CD

Every build pipeline should include a mandatory Software Composition Analysis (SCA) scan that blocks deployment if high-severity supply chain attack indicators are detected. Tools like Snyk, FOSSA, or Black Duck integrate with Jenkins, GitHub Actions, GitLab CI, and Azure Pipelines:

# GitHub Actions example with Snyk
- name: Run Snyk to check for supply chain vulnerabilities
  uses: snyk/actions/node@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  with:
    args: --severity-threshold=high --fail-on=all

Establish a Dependency Approval Process

Introduce a lightweight governance process for adding new third-party dependencies. This does not need to be bureaucratic — a dedicated Slack channel where developers post new dependency requests with a brief justification, reviewed by a security champion, adds a valuable human checkpoint. The April 2026 npm supply chain attack succeeded in part because many malicious packages were added casually without any review.

Maintain an Internal Package Mirror

For high-security environments, running an internal mirror of npm (using Verdaccio, Artifactory, or Nexus Repository) with only pre-approved packages prevents direct installation from public registries. A security team reviews and approves packages before they become available internally, eliminating dependency confusion attacks entirely and giving you control over exactly which versions are in use across the organization.

Monitor for New Maintainers on Critical Dependencies

Account takeover is how some of the most dangerous packages in this supply chain attack were published. Services like Deps.dev and Socket.dev can alert you when a package you depend on changes maintainers, publishes a new version with unusual characteristics, or starts making network requests it previously did not make. Set up automated alerts for your top 50 most critical dependencies.

Apply Zero-Trust to Developer Machines

Developer machines should not hold permanent access to production secrets. Use short-lived credentials with role assumption (AWS STS, HashiCorp Vault), enforce separate identities for development and deployment operations, and ensure that an attacker who compromises a developer laptop cannot directly access production databases or deploy to production without additional authentication steps. OIDC-based authentication for cloud providers in CI/CD eliminates long-lived static credentials entirely, which massively reduces the blast radius of any postinstall script attack.

10. Incident Response Playbook for Supply Chain Attacks

If you have confirmed a supply chain attack compromise in your organization, you need to move quickly and methodically. Use this playbook as your incident response framework. Time is critical — every minute of delay gives the attacker more opportunity to use stolen credentials and establish additional persistence.

Frequently Asked Questions

The Bottom Line: Supply Chain Security Is Not Optional

The April 2026 npm supply chain attack is a landmark event that should fundamentally change how every development team thinks about third-party dependencies. For too long, the open-source ecosystem has operated on implicit trust — the assumption that because a package is widely used or has a familiar-sounding name, it is safe. North Korea hackers and other sophisticated threat actors have thoroughly disproven that assumption.

The tools and practices to defend against this class of supply chain attack exist today and are largely free or low-cost. The Socket.dev GitHub App takes minutes to install. Running npm ci instead of npm install in CI/CD requires changing one line. Adding --ignore-scripts to your install commands is a single flag. None of these controls eliminate all risk, but together they form a layered defense that makes it significantly harder for a malicious package to reach production undetected.

For organizations that process sensitive data, handle financial transactions, or build software used by others, the incident response playbook in this guide is not just a recommendation — it is a business continuity necessity. A supply chain compromise that leads to production credential theft or a backdoored product release can result in regulatory action under Canada's CPPA, civil liability, and irreparable reputational damage.

If your team needs help assessing your current supply chain security posture, implementing the technical controls described in this guide, or responding to an active incident related to the April 2026 npm supply chain attack, IT Cares is available to assist Canadian businesses across all provinces. Our cybersecurity team has experience with dependency scanning infrastructure, CI/CD security hardening, and incident response coordination.