Canadian Cyber Security Journal
SOCIAL:
Filed under: Featured, TechTalk

Self-Spreading npm Supply Chain Attack Infects 187 Packages and Jumps to PyPI — What Canadian Developers Must Do Now

What Happened

On April 21, 2026, malicious versions of the pgserve npm package were published to the Node Package Manager registry. Pgserve is an embedded PostgreSQL server for Node.js development projects. The compromised versions — 1.1.11, 1.1.12, and 1.1.13 — inject a 1,143-line credential-harvesting script executing automatically on every npm install via a postinstall hook.

What separates this attack from a standard malicious package is its self-propagation mechanism. When npm publish tokens are found in environment variables or the ~/.npmrc configuration file on the compromised system, the malware identifies every package the victim controls, injects the same malicious payload, and republishes each with an incremented version number. Those newly infected packages then spread to anyone who installs them, repeating the cycle. By the time security researchers detected and removed the campaign, 187 npm packages had been compromised.

The attack does not stop at npm. When PyPI credentials are present on the system, the malware applies an equivalent technique using a .pth-based payload, gaining access to a second major software ecosystem. This cross-ecosystem propagation makes containment significantly more difficult. The attack was documented by BleepingComputer and independently confirmed by the StepSecurity research team.

Why This Matters for Canadian Organizations

Canada’s software development sector is deeply embedded in the npm and PyPI ecosystems. Development teams across Canadian financial services, SaaS companies, government digital services, and e-commerce depend on npm packages in their CI/CD pipelines daily. Any team with a developer who installs a downstream package infected through this self-propagation chain faces the same exposure as if pgserve had been installed directly.

The stolen credentials in this attack are not simple login tokens — they are npm publish keys. An attacker holding those keys sits inside the software distribution chain. Packages published from a trusted author’s compromised account will not raise registry-level alarms. Canadian organizations using automated dependency updates or unpinned version ranges in package.json are at elevated risk, as minor version bumps are often applied without manual review.

From a regulatory standpoint, organizations subject to PIPEDA have a duty to report breaches of security safeguards when there is a real risk of significant harm. A supply chain compromise introducing credential-harvesting malware into production systems likely meets this threshold. Incident response teams should assess whether customer data, authentication secrets, or regulated information transited systems where infected packages ran.

What to Do

Treat versions 1.1.11, 1.1.12, and 1.1.13 of pgserve as confirmed malicious and remove them from all systems and pipelines immediately. Audit your full dependency tree — not just direct dependencies — for any package published from accounts with potentially exposed npm tokens. Rotate all npm and PyPI publish tokens, as well as any secrets stored in environment variables or ~/.npmrc files on affected machines. Review CI/CD logs for unexpected package publishes from accounts your organization controls. Enable two-factor authentication on all registry accounts and enforce token scoping to limit publish permissions to specific packages where the registry supports it.

Enjoy this article? Don’t forget to share.