Malicious axios versions hit CI/CD pipelines - rotate your secrets now

TL;DR - If any build - developer workstation, CI runner, or Azure Pipelines job - installed [email protected] or [email protected], treat every secret available to that job as exposed. Rotate credentials, reimage agents, and purge dependency caches before you rebuild.

What happened

axios is a widely-used JavaScript HTTP client. On March 31, 2026, two malicious versions - 1.14.1 and 0.30.4 - were briefly published to npm as part of a supply chain attack.

Both versions carried a hidden malicious dependency, [email protected]. When npm install ran, that dependency executed install-time code, reached out to attacker-controlled C2 infrastructure, and fetched a second-stage payload. Azure DevOps published explicit guidance because CI/CD jobs run npm install constantly and the blast radius here is directly proportional to how many secrets the job can see.

Importantly, Azure was clear about what this is not:

"This incident does not represent a compromise of Azure Pipelines itself."

The platform is fine. The problem is what ran inside your pipelines.

This is the canonical supply-chain attack pattern: install-time execution plus CI secrets equals full job context exposure. If the install happened inside your pipeline, the attacker's code ran with the same access as your build.

Who is impacted

• Teams whose builds resolved [email protected] or [email protected] during the compromise window.
• Highest risk: pipelines running on self-hosted agents, containerised build environments, or using custom scripts and third-party extensions or tasks that install Node dependencies at build time.
• Secret-heavy jobs are the primary danger - specifically those with:
  • secure pipeline variables
  • service connection tokens
  • deployment credentials
• Lower risk: customers using Microsoft-hosted agents running only Microsoft-authored built-in tasks are not affected by any compromise of Azure Pipelines platform or hosted agent infrastructure as a result of this attack.

What to do now

• Review pipeline logs for any dependency installs that resolved [email protected], [email protected], or [email protected].
• Review network and endpoint telemetry for outbound connections to sfrclak[.]com or 142.11.206.73:8000.
• Reimage or rebuild affected self-hosted agents that executed builds during the relevant timeframe.
• Rotate all credentials used by affected agents - service connections, pipeline variables, and any secrets in scope during those runs.
• Purge dependency caches that could reintroduce compromised packages: workspace caches, npm, yarn, and pnpm caches, container layers, and generated artifacts.
• Treat outputs from affected runs as untrusted - replace artifacts and container images with clean rebuilds from verified sources.
• Harden your pipelines going forward:
  • commit lockfiles and use deterministic installs (npm ci rather than npm install)
  • avoid loose semver ranges that can silently float to newly published versions
  • limit secret scope to only the steps that genuinely require them