According to the firm's analysis, the attacker gained control of a primary maintainer's npm account and used a long-lived access token to publish both versions. Registry records made the releases appear to come from the legitimate maintainer, but they departed from the project's normal release pattern. The 1.x package lacked the OpenID Connect binding and repository commit reference associated with legitimate builds published through GitHub Actions, StepSecurity reported.
The Axios code itself contained no malicious lines. Instead, the packages declared plain-crypto-js 4.2.1 as a dependency even though Axios never imported it. That package supplied a post-install script, which ran automatically during dependency installation and contacted a command-and-control server. Separate second-stage payloads targeted macOS, Windows and Linux.
StepSecurity said the dropper then removed evidence of its activity and replaced its package manifest with a clean-looking file. The substituted manifest reported version 4.2.0, potentially causing routine package-listing commands to show the benign version after execution. The surrounding cryptographic source files were copied unchanged from the legitimate crypto-js package, leaving the post-install configuration as the crucial difference.
The operation was prepared before the Axios releases appeared. A clean-looking plain-crypto-js 4.2.0 package was published first, followed about 18 hours later by the malicious 4.2.1 version, according to the investigation. The two Axios branches were then poisoned within 39 minutes of one another. StepSecurity said the callback could begin within seconds of installation.
The incident surfaced through StepSecurity's package-analysis service and Harden-Runner product, which flagged an unfamiliar outbound connection during continuous integration activity. One public detection occurred in a Backstage workflow. The Backstage team said that workflow was intentionally sandboxed and that the installation did not affect the project, the security firm reported.
For development teams, the disclosure illustrates why a familiar package name and valid maintainer identity do not alone establish release integrity. Indicators such as trusted-publisher metadata, repository tags, lockfile changes and unexpected install scripts can expose deviations in the publishing chain. Teams that pulled either named Axios version should follow incident-response procedures, rotate secrets accessible to the environment, review network and endpoint evidence, and rebuild from known-clean dependencies rather than relying only on the package's post-infection appearance.
The firm said it responsibly disclosed the issue to Axios maintainers. Its account emphasizes that automated installation behavior allowed the attack to operate before a developer manually inspected the dependency tree.
