The 2026 Axios attack: why a clean dependency tree cannot clear a build runner

What happened, and what this article adds

On 31 March 2026, a compromised maintainer account published malicious axios versions 1.14.1 and 0.30.4. The maintainer’s post-mortem identifies the added dependency as plain-crypto-js@4.2.1 and describes cross-platform malware delivery. [1] Microsoft’s analysis places the execution path in package installation, rather than a change to the HTTP client’s normal source logic. [2]

This article proposes a recovery evidence model: determine what was installed, what ran and which authority that execution could reach. Those questions help a product owner decide which systems and release artifacts need attention without treating every dependency mention as a confirmed breach. The analysis uses public records checked on 4 October 2026; it does not claim access to victims’ environments or fresh malware experiments.

Installation is an execution boundary, even without an import

JFrog identifies a postinstall hook; execution did not require an application import. [3] The review implication is that source-level reachability and installation-time reachability need separate investigation. A review limited to whether the application imports a suspicious library can miss the stage at which the machine became exposed.

The diagram below is a conceptual model of the trust transitions, not a claim that every listed downstream system was compromised. Enumerate installers, package-manager settings, scripts, plugins and build tools that run on your agents. Separate the install job from jobs with deployment or signing privileges. That separation matters even for a mobile or desktop product whose shipped application contains no Axios code.

registry publication
  -> dependency resolution
  -> package installation
  -> lifecycle-script execution
  -> runner identity and reachable credentials
  -> repositories, signing systems, deployments

The package tree is one evidence source.
The execution history is a different evidence source.

Why a clean current tree can coexist with past malicious execution

JFrog reports post-execution deletion of the loader and replacement of its manifest. [3] The consequence for an investigator is that a later file inspection can be an incomplete historical record. It does not mean every scanner is ineffective; it means a present-state inspection and an execution-history investigation answer different questions.

Preserve installation logs, lockfile revisions, cached package digests, runner telemetry, network records and release metadata before rebuilding. An empty search in today’s checkout cannot establish what yesterday’s runner installed. Conversely, a malicious version in a lockfile establishes dependency resolution, not automatically successful payload execution or data theft. Report each observation at the level the evidence supports.

Map authority over time, not just environment-variable names

OpenAI reported malicious Axios execution in an app-signing workflow and precautionary certificate rotation, with no evidence of compromised user data or altered software. [4] This illustrates why exposure must be assessed with precise boundaries, not converted into an unsupported breach headline. An investigation should distinguish what the workflow could access from what an attacker demonstrably used.

For your own runner, map what each process could reach at the relevant moment: repository tokens, cloud identities, signing services, mounted files and network-accessible credentials. A secret injected later may not have been available to the first script, but persistence could change that conclusion. A short-lived token can limit duration while still granting valuable authority during its valid window. Treat timing, permissions and persistence as separate evidence questions.

Use three evidence states instead of a binary “affected” label

State one is resolution evidence: a malicious package version appears in an install record, lockfile or package artifact. State two is execution evidence: a lifecycle hook, child process or relevant network action ran. State three is authority exposure: that execution could access a specific credential or privileged operation. These are proposed triage states, not official incident classifications, and one investigation may have different confidence levels for each.

Keep an “unknown” value when logs are missing. Missing execution telemetry does not prove that a script never ran. Equally, credential reach is not proof that an attacker used the credential. Record the asset, time interval, evidence and uncertainty, then let the incident owner choose containment appropriate to the risk. This produces a more useful decision than announcing that an entire organization is either safe or breached from one grep result.

asset_id | workflow_run | install_time_utc
package_name | package_version | package_digest
script_policy | execution_evidence | network_evidence
identity | credential_scope | credential_lifetime
artifact_digest | downstream_destination
containment | credential_revocation | rebuild_evidence

Recovery requires host, identity and artifact evidence

Microsoft recommends examining affected install activity and rotating credentials exposed to compromised systems. [2] Removing the dependency addresses the package state; it does not revoke a stolen token or establish that a runner is clean. Coordinate containment and evidence preservation, revoke exposed access from a trusted environment, and rebuild affected execution environments using a trusted baseline where the investigation requires it.

Trace releases from the affected workflow to artifact digests, signing events and distribution destinations. Determine which outputs need withdrawal, inspection or a clean rebuild. Verify that old credentials fail, replacement credentials have the intended scope and the new build no longer resolves malicious packages. Retain evidence of the actual installed tree and executed workflow, rather than accepting a corrected package.json as the whole recovery report.

Place a control at each trust transition

A committed lockfile and immutable install mode help reproduce dependency resolution; they do not make a malicious pinned package trustworthy. Release-age policies can provide investigation time but cannot prove older packages are benign. Provenance can connect an artifact to a publisher and build, yet an authorized compromised workflow may still produce an unwanted artifact. Use these controls for their specific assurance, not as substitutes for one another.

Google’s supply-chain guidance recommends layered controls such as isolated runners, lifecycle-script restrictions and short-lived workload identities. [5] Review the defaults of the package-manager version actually deployed; do not assume every version runs or blocks scripts in the same way. Permit necessary build hooks explicitly, minimize credentials in install jobs, constrain outbound traffic and test that a denied hook really cannot execute. A security setting only counts as a boundary when its behavior has been verified.

The recovery questions a product owner should ask

Which runner and developer assets resolved the malicious package? Which executed its code? Which identities could they access at that time? Which artifacts and customers, if any, are linked to those runs? What evidence supports credential revocation and clean rebuilding? Ask for an asset-by-asset answer with explicit unknowns, not an unsupported universal assurance or a dramatic estimate of victims.

A focused remediation-verification engagement can check the agreed dependency corrections, workflow permissions, identity changes and rebuilt artifacts. Active incident containment and host forensics may require a dedicated response team; define that responsibility before commissioning work. The reusable outcome is an evidence record that developers, security staff and release owners can revisit when the next trusted dependency crosses the installation boundary.