16 npm Packages Compromised in Self-Propagating Supply Chain Attack

What Happened

On April 21, 2025, attackers published a malicious version of the pgserve package from Namastex Labs. Within days, 16 packages from the same publisher were compromised. The attack used a self-propagating mechanism: malicious code in these packages exfiltrated developer credentials and npm tokens, then used those stolen credentials to compromise additional packages maintained by the victims.

Socket and StepSecurity detected the attack and published indicators of compromise. By the time the security firms raised the alarm, the attack had created a cascade effect—any developer who installed an affected package risked having their entire package portfolio compromised.

Timeline

• April 21, 22:14 UTC: First malicious version of pgserve published to npm registry.
• April 21-24: Attack spreads across 15 additional Namastex Labs packages through automated republishing.
• April 25 (estimated): Socket and StepSecurity tools flag suspicious behavior in package update patterns.
• April 26: Security firms publish indicators of compromise and notify npm registry maintainers.
• Post-disclosure: Unknown number of downstream installations and potential secondary compromises through stolen credentials.

The gap between initial compromise and detection is a critical window where your team could download a malicious package, have credentials exfiltrated, and become an unwitting attack vector—all before any public warning.

Which Controls Failed or Were Missing

• No package integrity verification: Developers installed package updates without verifying cryptographic signatures or comparing checksums against known-good versions. The compromised packages passed through CI/CD pipelines unchallenged.
• Insufficient credential scoping: The stolen npm tokens had broad write permissions, allowing attackers to publish updates to any package the victim maintained.
• Missing runtime monitoring: Malicious code executed during package installation without triggering alerts. No monitoring detected outbound connections to attacker-controlled infrastructure or unusual file system access patterns.
• Absent dependency pinning: Build configurations used version ranges (e.g., ^, ~) rather than exact versions with lock file integrity checks, allowing automatic updates to pull malicious versions without explicit approval.
• No secret rotation policy: Compromised npm tokens remained valid indefinitely. No automated rotation schedule or anomaly detection flagged unusual publishing activity from legitimate accounts.

What the Relevant Standards Require

• OWASP ASVS v4.0.3 Requirement 14.2.1 mandates that all components are identified with a software bill of materials (SBOM) and verified to come from trusted sources. Installing packages without verifying publisher identity or tracking exact versions violates this requirement.
• NIST 800-53 Rev 5 Control SA-10 (Developer Configuration Management) requires organizations to track and control changes to software components. Accepting automatic package updates without approval workflows fails this control.
• NIST 800-53 Rev 5 Control SC-34 (Non-Modifiable Executable Programs) states that systems should verify software integrity before execution. Running install scripts from packages without integrity verification creates the vulnerability exploited here.
• ISO 27001 Control 8.31 (Separation of development, test and production environments) requires that development credentials cannot affect production systems. Npm tokens with organization-wide publishing rights violate this separation principle.
• PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software is developed securely based on industry standards. For organizations processing payment data, unvetted third-party code executing in development environments creates compliance exposure.

Lessons and Action Items for Your Team

• Implement exact version pinning today. Modify package.json to use exact versions (no ^ or ~). Commit your package-lock.json or yarn.lock and configure CI to fail if the lock file doesn't match. This prevents automatic ingestion of compromised updates.
• Scope npm tokens by package. Generate granular access tokens through npm token create --read-only for CI/CD pulls and separate publish-only tokens for each package you maintain. Revoke organization-wide tokens. If a token leaks, the blast radius stays contained.
• Enable Socket or similar SBOM scanning. Integrate supply chain security tools that detect suspicious install scripts, network requests, and obfuscated code. Configure your CI pipeline to block builds when these tools flag anomalies.
• Audit install scripts. Run npm explore <package> -- cat package.json to inspect preinstall, postinstall, and install hooks before adding new dependencies. Any script making network calls or accessing credentials should trigger immediate investigation.
• Rotate tokens quarterly. Set calendar reminders to regenerate npm tokens every 90 days. Use secret management tools (1Password, Vault, AWS Secrets Manager) that support automated rotation rather than storing tokens in environment variables.
• Monitor publishing activity. Configure alerts for package publishes from your organization's account. Any publish outside your deployment windows should trigger an immediate credential audit. The npm registry provides webhook notifications for this purpose.
• Sandbox dependency installation. Run npm install inside containers or VMs without access to your primary development credentials. Mount only the specific directories needed for the build. This limits what exfiltration code can access even if it executes.
• Verify package signatures when available. While npm's signature verification is still emerging, enable it for packages that support it through npm config set sign-git-tag true. As the ecosystem matures, this becomes your first line of defense.

The self-propagating nature of this attack means a single compromised dependency can cascade through your entire package portfolio. Your incident response plan needs to account for this: if you discover one compromised package, assume all packages maintained by affected developers are suspect until proven otherwise.