What Happened
Between November 2024 and early 2025, threat actors linked to North Korean operations (tracked as UNC1069 and TeamPCP) compromised the Axios npm package—a JavaScript HTTP client library with over 100 million weekly downloads. During a three-hour window, attackers published malicious versions that exfiltrated environment variables, authentication tokens, and credentials from systems that installed or updated the package. The compromised versions reached production environments across multiple industries and geographic regions before detection.
The attack used stolen maintainer credentials to publish versions 1.7.4 through 1.7.7 containing obfuscated data collection code. Organizations that ran npm install or npm update during the compromise window pulled malicious code directly into their build pipelines and production systems.
Timeline
November 2024 (estimated): Initial credential compromise of Axios maintainer account occurs through unknown vector.
Three-hour window (specific dates not disclosed): Attackers publish four malicious package versions (1.7.4-1.7.7) to npm registry. Packages begin downloading to systems worldwide.
Detection point: Security researchers identify anomalous code in published versions. npm security team notified.
Response phase: Malicious versions removed from registry. Organizations globally begin incident response procedures to identify exposure and rotate credentials.
Ongoing: Organizations continue to assess blast radius and investigate potential secondary compromises from stolen credentials.
Which Controls Failed or Were Missing
Package Signing and Verification: No cryptographic verification existed to validate that published packages came from legitimate maintainers. The npm ecosystem lacks mandatory signing requirements, allowing compromised credentials to bypass authenticity checks.
Multi-Factor Authentication on Publishing: The maintainer account either lacked MFA or used an MFA method vulnerable to compromise (such as SMS-based codes or push notification fatigue attacks).
Automated Security Scanning: Organizations pulled packages without automated scanning for suspicious code patterns, environment variable access, or network connections to unexpected domains. The three-hour window suggests detection relied on manual review rather than automated controls.
Dependency Pinning: Systems using version ranges (^1.7.0 or ~1.7.0) automatically pulled malicious updates. Organizations that pinned exact versions avoided exposure but represent a minority of installations.
Build-Time Sandboxing: Installation scripts ran with full access to environment variables and system resources. No isolation prevented the malicious code from accessing sensitive data during the install phase.
Credential Hygiene: The widespread impact indicates many organizations stored production credentials in environment variables accessible to build processes—a practice that amplifies supply chain compromise impact.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that software engineering techniques prevent or mitigate common software attacks, including supply chain risks. Organizations processing payment data must implement controls to verify software integrity before deployment.
NIST 800-53 Rev 5 SR-3 (Supply Chain Protection) requires organizations to employ security safeguards to protect against supply chain threats. This includes integrity verification mechanisms for software components and monitoring for unauthorized changes.
NIST 800-53 Rev 5 SA-10 (Developer Configuration Management) specifies that organizations require developers to identify configuration items throughout the system development life cycle and manage changes to those items. This includes tracking and verifying third-party components.
ISO/IEC 27001:2022 Annex A.8.31 (Separation of Development, Test and Production Environments) requires organizations to separate development, testing, and production environments to reduce supply chain attack impact. Production credentials should never be accessible to build or test processes.
SOC 2 Type II CC7.2 addresses system operations, requiring monitoring of system components and implementation of controls to prevent unauthorized changes. This applies to third-party dependencies that become part of the system.
OWASP Top 10 2021 A06:2021 – Vulnerable and Outdated Components directly addresses supply chain risks, noting that components run with the same privileges as the application and that compromised components can enable serious attacks.
Lessons and Action Items for Your Team
Implement dependency pinning today. Edit your package.json to specify exact versions ("axios": "1.7.3" not "axios": "^1.7.0"). This prevents automatic updates during compromise windows. Use npm shrinkwrap or package-lock.json to lock transitive dependencies.
Add package integrity verification. Enable npm's built-in integrity checking with npm install --integrity. Configure your CI/CD pipeline to fail builds if checksums don't match. For critical dependencies, manually verify package hashes against maintainer-published values.
Scan packages before installation. Integrate tools like Socket Security, Snyk, or npm audit into your pipeline. Configure them to block installations that access environment variables, make network requests, or execute shell commands during install. Set these checks to run before code reaches your build environment.
Isolate build processes from production secrets. Never store production credentials in environment variables accessible to npm install scripts. Use secret management services (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) that require explicit authentication. Configure your CI/CD to inject secrets only after dependency installation completes.
Monitor for package updates. Set up alerts for new versions of your direct dependencies using Dependabot, Renovate, or similar tools. This gives you visibility into unexpected version bumps that might indicate compromise.
Require MFA on all publishing accounts. If your team publishes packages, enforce hardware token-based MFA (YubiKey, Titan Security Key). Disable SMS and push notification methods. Use npm's access tokens with IP restrictions and expiration dates.
Create a dependency incident response plan. Document which packages your systems depend on, where they're used, and who owns each service. When a compromise occurs, you need this information within minutes, not hours. Include procedures for credential rotation across all systems that might have been exposed.
Test your rollback procedures. Can you revert to a known-good package version across all environments in under 30 minutes? Practice this quarterly. The Axios incident shows that three hours is enough time for significant damage.
Audit environment variable usage. Search your codebase for process.env calls. Question whether each secret needs to be in an environment variable or could use a more secure injection method. Reduce the blast radius of the next compromise.
The Axios breach demonstrates that package compromise windows measured in hours can affect millions of systems. Your controls need to work faster than attackers can move.
CVE Details
