A recent compromise of the popular Axios npm package has highlighted critical gaps in supply chain security for software development teams. Google's Threat Intelligence Group attributed the breach of Axios versions 1.14.1 and 0.30.4 to UNC1069, a North Korean threat group. This was not a flaw in Axios itself but a deliberate supply chain attack that transformed a trusted dependency into a threat.
What Happened
Attackers published malicious versions of the Axios package to npm, injecting a dependency called 'plain-crypto-js' that contained a backdoor known as WAVESHAPER.V2. This code executed automatically through a postinstall hook in the dependency's package.json file when developers installed or updated the compromised Axios versions. The backdoor communicated with a command-and-control server every 60 seconds, allowing attackers persistent access to affected systems across various operating systems.
Timeline
The attack followed a typical supply chain compromise sequence:
- Initial compromise: Attackers gained the ability to publish malicious versions to the Axios npm package.
- Injection: Malicious versions 1.14.1 and 0.30.4 were published with the plain-crypto-js dependency.
- Installation: Developers installed or updated to the compromised versions through standard processes.
- Execution: The postinstall hook executed the backdoor code automatically.
- Persistence: WAVESHAPER.V2 established command-and-control communications at 60-second intervals.
- Attribution: Google Threat Intelligence Group identified UNC1069 as the responsible actor.
Which Controls Failed or Were Missing
The attack succeeded due to several missing or ineffective security measures:
Package integrity verification: Organizations did not verify package checksums and signatures before installation. Malicious versions were downloaded directly from npm without validation.
Dependency analysis: Build pipelines failed to flag the unexpected appearance of a new dependency in a minor version update. The transition from Axios 1.14.0 to 1.14.1 should not have included new dependencies.
Postinstall script monitoring: Scripts executed without scrutiny. Your build environment should treat any automatically running script during package installation as a potential security risk.
Network egress controls: The backdoor's frequent communication with an external server indicates inadequate monitoring of outbound connections from development environments.
Supply chain risk assessment: There was a lack of understanding of which dependencies are critical and what changes pose unacceptable risks.
What the Standards Require
Several compliance frameworks address supply chain security:
NIST Cybersecurity Framework calls for supply chain risk management under the GOVERN function, including software dependencies.
NIST 800-53 Rev 5 provides prescriptive controls like SA-12 (Supply Chain Protection) and SR-3 (Supply Chain Controls and Processes), requiring monitoring and documentation of supply chain elements.
PCI DSS v4.0.1 Requirement 6.3.2 emphasizes secure development, including managing software dependencies.
ISO/IEC 27001:2022 addresses supplier relationships, requiring defined security requirements with suppliers and monitoring adherence.
Lessons and Action Items for Your Team
Implement package lock and integrity checks: Use package-lock.json or yarn.lock files and commit them to version control. Configure your package manager to verify checksums. Use npm ci instead of npm install in CI/CD pipelines to enforce exact versions from the lock file.
Audit postinstall scripts: Add a pre-commit hook to flag changes introducing new install scripts. Review these scripts manually before merging. Consider using --ignore-scripts during installation and selectively enable scripts only for audited packages.
Monitor dependency changes: Use tools like Dependabot or Renovate to create separate pull requests for each dependency update. Investigate minor version updates that add new dependencies before merging.
Segment build environment network access: Implement egress filtering to allow connections only to necessary destinations. A 60-second beacon to an unknown server should be impossible.
Establish a Software Bill of Materials (SBOM) process: Generate SBOMs for every build using tools like Syft or OWASP CycloneDX. Store these alongside your build outputs to quickly identify affected builds during a compromise.
Create a dependency response plan: Document steps for responding to a compromised package. Define roles for decision-making, identify affected systems, and plan communication for downstream consumers.
The Axios compromise shows that supply chain attacks don't require sophisticated exploits. They need only the ability to inject malicious code into a trusted channel and the absence of controls to detect it. Your dependency management process is a security control, not just a convenience.



