Axios: How AppSec teams should respond

The compromise of axios, a JavaScript client library, is one of the most significant supply chain breaches ever. Used to enable web requests, the axios library is downloaded nearly 100 million times each week and has more than 174,000 dependent software libraries and applications. 

Starting on Sunday, compromised versions of axios npm packages 1.14.1 and 0.30.4 were detected. The packages did not contain malicious code, and they operated normally, but they included a new software dependency, plain-crypto-js@4.2.1, that ran a post-installation script on systems that downloaded and installed the axios library. The script deployed a RAT (remote access Trojan) that targeted devices using the MacOS, Windows, or Linux operating systems. 

Soon after the axios breach was detected on npm, ReversingLabs observed the compromise spread to the Python Package Index (PyPI) and NuGet ecosystems through JSII modules in version 0.0.194 of the jjrawlins-cdk-iam-policy-builder-helper package, with the compromised versions of axios npm package as a dependency.

Reports attribute the compromise to North Korea-linked threat actors, based on threat indicators. That is consistent with prior operations targeting crypto-adjacent organizations and resulting in the large-scale theft of credentials and source code.

Joshua Wright, a faculty fellow at the SANS Institute and senior technical director at Counter Hack Challenges, told CyberScoop that as many as 600,000 downloads of the malicious axios packages may have occurred, given the length of time the packages were online. The security implications of those compromises could be massive. 

“As soon as you install the software, it scrapes access credentials, and so now threat actors could pivot to AWS [or] other GitHub packages through scraped GitHub keys, and that’s the part that’s really difficult to articulate."
—Joshua Wright

The question for developers and development organizations is how to respond and ensure that they are not impacted by the axios compromise. Here are some suggestions to keep you safe. 

The high-level response

At a high level, development teams should model their response around the attacker's known priorities, which are to maximize the number of compromised organizations, harvest cloud secrets and access tokens, and exfiltrate intellectual property, including application source code. 

A secondary outcome of lower probability is disruption, such as through the deployment of ransomware. 

Immediate-response checklist

Here are steps to take to address the immediate risks of credentials misuse and IP theft:

1. Audit your dependency tree. Confirm whether axios or any transitive dependency was resolved to a compromised version during the exposure window.
2. Rotate all cloud credentials, API tokens, and secrets accessible from environments that ran the compromised package. Regard any secret that existed in those environments as stolen.
3. Review CI/CD pipeline logs for unusual egress, unexpected network calls, or anomalous process spawning during build or test runs.
4. Audit access to source code repositories, artifact stores, and internal package registries for unauthorized access in the relevant time frame.
5. Elevate incident priority for crypto-related products or services, and treat this as a targeted operation rather than an opportunistic exposure.
6. Pin your dependencies to known-good versions and enforce integrity checks — lockfile validation and subresource integrity — before resuming normal builds.
7. Notify downstream consumers of your software if you publish packages that depend on axios, so that they can perform their own triage.

Best practices for ongoing defense

Beyond the steps to address the immediate risk of compromise, development organizations should adopt practices and measures that will prevent similar attacks in the future. Those include: 

• Maintaining continuous dependency inventory: Static, point-in-time software bills of materials (SBOMs) are insufficient. Maintain a live, machine-readable inventory across all build artifacts so you can determine whether your organization was affected within minutes of a disclosure — not hours or days.
• Extending visibility beyond SBOM to xBOM: A traditional SBOM captures software components. An extended bill of materials (xBOM) also surfaces cloud service dependencies (SaaSBOM), cryptographic assets (CBOM), and ML models (AI/ML-BOM) — all relevant attack surfaces for threat actors aiming to compromise supply chains.
• Monitoring OSS packages continuously, not just at intake: Packages that were clean at intake can be compromised post-adoption. Continuously verify the integrity of open-source dependencies against known-good baselines throughout their lifecycle in your codebase.
• Using short-lived credentials in CI/CD contexts: Any build environment that executes third-party code — including transitive dependencies — can steal secrets. Use short-lived credentials with minimal scope. GitHub recommends using OIDC tokens.
• Modeling cascading risk, not just direct exposure: Incidents such as the Shai-hulud npm worm led to downstream incidents like the hack of Trust Wallet, a crypto wallet application, and the theft of an estimated $8 million in crypto assets. That attack chain underscores that initial compromises are just the first act in what is often a long performance by threat actors. To help head off follow-on attacks, development organizations should map which of their downstream consumers, partners, or published packages could be affected if their environment was touched.
• Prioritizing crypto and fintech asset protection: North Korea-linked threat actors consistently target cryptocurrency infrastructure. Teams building or integrating with crypto-adjacent systems should treat supply chain compromises as high-priority targeted incidents, not background noise.

How an xBOM helps

A conventional SBOM tells you what components are present. An xBOM goes further, capturing relationships between components, cloud service dependencies, cryptographic assets, and ML models, all mapped across the full software development lifecycle.

In the context of the axios compromise, this additional insight matters because an SaaSBOM and CBOM would, after a supply chain compromise, sharply reduce your time to:

• Understand exposure: Instead of hunting log files and asking teams if they use Axios, you should already know whether scanned software is within the blast radius of the attack.
• Prioritize response: A CBOM that maps keys, certificates, etc. back to services and software components can help create a more concrete rotation plan instead of ad hoc changes.
• Manage downstream risk: Since software supply chain attacks can be used to steal credentials and attack downstream, it is important to understand which SaaS tenants are affected. 

An xBOM provides additional information on each component and dependency — including relationships between different parts of an application and known vulnerabilities. When responding to the axios incident, practitioners with an xBOM don’t have to ask which packages they have and can focus instead on questions like which cloud services those packages were calling and what cryptographic material was accessible to them They can more precisely and quickly detect, scope, and respond to the incident.

For a full breakdown of what xBOM covers and how it maps to CycloneDX and SPDX export formats, see the ReversingLabs xBOM documentation. For context on why the industry is moving toward xBOM as a baseline requirement, see the RL blog post “Rise of the xBOM: The new go-to tool for software security.”

Check your exposure

RL’s Spectra Assure provides complex binary analysis that enables software buyers to analyze third-party software without the need for source code — giving security teams a comprehensive view of what was present in software at a given point in time. And including binary analysis in the onboarding process enables organizations to have broader visibility across their software portfolio. That capability is critical for scoping exposure after a supply chain compromise and can improve incident-response effectiveness.

RL also hosts the Spectra Assure Community, a free platform where developers, DevOps engineers, and security practitioners can check the security status of open-source packages and developer tools. For the axios compromise specifically, practitioners can use it to check for affected package versions, identify whether their builds pulled in a compromised version, and verify the integrity of other npm dependencies in their pipeline.

The contents of software package and developer tool repositories are continually analyzed by RL, with the latest findings immediately available on the Spectra Assure Community website. And with a free Community API token, teams can automate checks on OSS dependencies and secure their pipeline at every stage of software development.

To automate the checks in a CI/CD pipeline, we recommend using RL-Protect or the RL-Protect GitHub Action, which detect compromised packages to prevent them from being incorporated into your builds.

Get started at docs.secure.software/community, or go directly to the Spectra Assure Community. For CI/CD integration details, see the rl-protect documentation.