On March 31, 2026, malicious versions of the widely used JavaScript HTTP client library Axios were briefly published to the npm registry as part of a supply chain attack.

The affected versions — 1.14.1 and 0.30.4 — included a hidden malicious dependency that executed during installation and connected to attacker-controlled command-and-control (C2) infrastructure to retrieve a second-stage payload.

Because modern development workflows frequently rely on automated dependency resolution during CI/CD builds, environments such as developer workstations and build agents—including those used in Azure Pipelines—may have been exposed if they resolved the compromised versions during installation or update.

For a detailed technical analysis of the attack and recommended mitigations, please refer to the Microsoft Security Blog:

Mitigating the Axios npm Supply Chain Compromise on the Microsoft Security Blog.

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

Customers who:

• Use Microsoft-hosted agents, and
• Run only Microsoft-authored built-in tasks

are not affected by any compromise of the Azure Pipelines platform or hosted agent infrastructure as a result of this npm ecosystem attack.

Azure Pipelines Microsoft-hosted agents execute jobs on Microsoft-managed virtual machines. Each pipeline job runs on a newly provisioned VM that is discarded after the job completes. Any changes made during a job are not persisted to subsequent jobs. See Microsoft-hosted agents for Azure Pipelines and Azure Pipelines agents on Microsoft Learn.

However, CI/CD pipelines execute customer-defined workflows, including installing third-party dependencies during build time. If a pipeline run installed one of the malicious Axios versions, code executed during package installation, and any credentials or secrets available to that affected job should be treated as potentially exposed.

You may be at risk if your Azure Pipelines workflows include:

• Custom pipeline scripts
• Third-party extensions installed from the Marketplace
• Self-hosted agents
• Containerized build environments

Self-hosted agents are customer-managed compute infrastructure used to run pipeline jobs. See Azure Pipelines agents on Microsoft Learn.

Self-hosted agents that executed pipeline builds during the compromise window may have:

• Installed malicious dependencies
• Persisted compromised packages in local caches
• Exposed credentials accessible during pipeline execution

We recommend:

• Reimaging or rebuilding affected agents
• Reviewing agent activity logs during the relevant timeframe
• Rotating credentials used by affected agents

Review whether any:

• Marketplace extensions
• Custom tasks
• Inline scripts

used in your pipelines depend directly or transitively on Axios and executed npm install or update operations during pipeline execution.

Pipeline steps that resolve compromised dependencies may have access to:

• Secure pipeline variables
• Service connection tokens
• Deployment credentials

Azure Pipelines uses service connections to authenticate pipelines to external or remote services such as:

• Azure subscriptions
• Container registries
• Kubernetes clusters
• External build or artifact systems (see Service connections on Microsoft Learn)

If compromised dependencies executed within a pipeline job, identities or credentials associated with service connections used during that run may have been exposed.

We recommend:

• Rotating credentials associated with affected service connections
• Reviewing actions taken by pipelines using those connections

Compromised dependencies may persist in:

• Pipeline workspace caches
• npm/yarn/pnpm cache directories
• Container build layers
• Generated artifacts
• Package-manager caches

Clear dependency caches associated with affected repositories or agents to prevent reuse of compromised packages in future builds.

Artifacts generated from runs that installed the malicious package versions should be treated as untrusted and replaced with clean builds.

Review any pipeline runs that may have installed the affected Axios versions, especially in workflows that use self-hosted agents, custom tasks, third-party extensions, or containerized build environments.

For detailed attack analysis, indicators of compromise, and mitigation guidance, see Mitigating the Axios npm Supply Chain Compromise on the Microsoft Security Blog.

• Custom pipeline scripts
• Third-party extensions installed from the Marketplace
• Self-hosted agents
• Containerized build environments

Avoid loose semantic version ranges such as:

"axios": "^1.13.0"

Loose constraints may automatically resolve to newly published versions during routine installs — including compromised ones.

Ensure your pipelines:

• Commit package-lock.json / yarn.lock / pnpm-lock.yaml
• Use deterministic install commands (e.g. npm ci)

This helps prevent unexpected dependency resolution during CI/CD runs.

Minimize exposure by:

• Using least-privilege service connections
• Injecting secrets only into steps that require them
• Avoiding global environment variable exposure across jobs

Do not assume that:

• Container images
• Deployment bundles
• Published packages

produced during a compromised pipeline run are safe.

Rebuild affected outputs after remediating dependencies.

• Pin dependency versions
• Use lockfiles and deterministic installs
• Limit secret scope in pipelines
• Rebuild build outputs after remediation

To understand the attack mechanics, indicators of compromise, and Microsoft’s mitigation guidance, please review: Mitigating the Axios npm Supply Chain Compromise on the Microsoft Security Blog.

Self-hosted agents that executed pipeline builds during the relevant timeframe should be reviewed for signs that they installed the malicious package versions or the injected dependency plain-crypto-js@4.2.1.

We recommend:

• Reviewing pipeline and agent logs for npm install or npm ci runs that resolved axios@1.14.1, axios@0.30.4, or plain-crypto-js@4.2.1
• Reviewing network activity for connections to sfrclak[.]com or 142.11.206.73 on port 8000
• Reimaging or rebuilding affected agents where practical
• Rotating credentials that were available to affected runs

If an affected pipeline run had access to service connections or deployment credentials, those credentials should be treated as potentially exposed.

We recommend:

• Rotating credentials associated with service connections used by affected runs
• Reviewing service connection usage history and actions taken by those identities during the relevant timeframe

Review pipeline logs for npm install or npm ci executions that resolved:

• axios@1.14.1
• axios@0.30.4
• plain-crypto-js@4.2.1

Also review network and endpoint telemetry for the following indicators:

• sfrclak[.]com
• 142.11.206.73
• hxxp://sfrclak[.]com:8000/6202033