Axios Was Compromised. Here’s What Laravel Developers Need to Check

A compromised npm release of Axios created real risk for Laravel apps that use modern frontend tooling. This was not a Laravel vulnerability. It was not a Composer incident. It was a JavaScript supply chain issue that could hit your local machine, CI runner, preview environment, or deploy process if that environment resolved the poisoned packages on March 31, 2026.

The affected versions widely reported so far are axios@1.14.1 and axios@0.30.4. Those releases pulled in plain-crypto-js@4.2.1, a malicious dependency described in security writeups as a post-install malware path with cross-platform remote access trojan behavior. That distinction matters because this story is about package versions, not Laravel versions.

What happened

Early incident reporting from Socket and StepSecurity points to a compromised Axios maintainer account that was used to publish malicious npm releases. Those releases introduced plain-crypto-js@4.2.1, which existed to execute during install rather than to provide any legitimate Axios functionality.

The bad releases were reported and then removed from npm later on March 31, 2026. That is helpful, but it does not eliminate the real problem. If a developer laptop, CI job, or Docker build resolved those versions while they were live, the risk is on the machine that performed the install.

Which versions are affected

Be explicit here: the versions reported so far are axios@1.14.1, axios@0.30.4, and the transitive malicious dependency plain-crypto-js@4.2.1.

These are Axios package versions, not Laravel framework versions.

Which Laravel apps should care

Laravel teams should care because modern Laravel apps usually carry an npm attack surface whether they think about it that way or not. Laravel’s own CSRF documentation still notes that the default resources/js/bootstrap.js file includes Axios and automatically sends the X-XSRF-TOKEN header on same-origin requests. That means Axios is still a normal dependency in many Laravel projects, especially when teams start from Laravel’s standard frontend scaffolding.

The highest-risk cases are the environments that performed fresh dependency resolution while the malicious releases were live:

• Laravel apps using Vite with a JavaScript frontend, including Inertia, Vue, and React setups
• Starter-kit based projects that kept the default Axios instance for same-origin or Sanctum-style AJAX flows
• CI pipelines, ephemeral preview environments, and build servers that ran npm install, pnpm install, yarn install, or similar commands on March 31, 2026
• Docker builds that resolved frontend dependencies during image creation instead of relying on a known-good lockfile

Teams with pinned safe versions and committed lockfiles are in much better shape. The practical risk is highest where installs were fresh, automatic, and allowed to resolve new versions during the exposure window.

How to check a Laravel project

Start with the lockfile, not guesswork. If your lockfile or installed tree never resolved the poisoned versions, you may have little to do beyond confirming that your pipeline stayed on known-good versions.

# npm lockfiles
grep -RInE 'axios@1\.14\.1|axios@0\.30\.4|plain-crypto-js' package-lock.json npm-shrinkwrap.json 2>/dev/null

# npm
grep -RInE '"axios"|plain-crypto-js' package-lock.json

# yarn
grep -RInE 'axios@|plain-crypto-js' yarn.lock

# pnpm
grep -RInE 'axios|plain-crypto-js' pnpm-lock.yaml

# bun
grep -RInE 'axios|plain-crypto-js' bun.lock bun.lockb 2>/dev/null

The exact strings worth searching for are:

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

If node_modules still exists, inspect the installed tree directly:

npm ls axios
npm ls plain-crypto-js
find node_modules -type d -name "plain-crypto-js"

If you want the npm-specific version checks in a form that is easy to copy into incident response notes, use:

# Check what is currently installed
npm ls axios --all 2>/dev/null
npm ls plain-crypto-js --all 2>/dev/null

# Narrow to the known bad versions
npm ls axios --all 2>/dev/null | grep -E '1\.14\.1|0\.30\.4'
npm ls plain-crypto-js --all 2>/dev/null

# Search the repo and any saved build artifacts or logs
grep -RInE 'axios@1\.14\.1|axios@0\.30\.4|plain-crypto-js|sfrclak\.com' . 2>/dev/null

Then widen the check beyond the repository. Review CI logs, recent Docker builds, dependency cache layers, and any preview or deploy workflows that may have installed packages during the March 31, 2026 window. The question is not only whether the application source references Axios. The question is whether any machine in the build path fetched the poisoned release.

If you deploy through Laravel Cloud, Laravel Forge, or any similar platform that runs frontend dependency installation during build or deploy, check there too. A safe local machine does not help much if a hosted deploy step ran npm install against the bad versions during the exposure window.

There is one more edge case worth checking: an unmerged branch, commit, or pull request that updated the lockfile to one of the poisoned versions. Even if that change never reached production, the developer machine or CI environment that created the branch may still have resolved and executed the malicious install path.

What to do if you find it

If you confirm exposure, respond like an installer-path compromise, not like a routine dependency bump.

1. Treat the affected machine, runner, or image build environment as potentially compromised.
2. Do not just upgrade Axios and move on. That may fix the dependency tree, but it does not answer whether secrets were exposed during installation.
3. Rotate anything that may have been present in that environment, including .env values, cloud credentials, deploy tokens, npm tokens, GitHub tokens, database credentials, and third-party API keys.
4. Rebuild from a known-clean environment with pinned safe versions and a refreshed lockfile.
5. Audit recent install activity, CI logs, build logs, and image history to see where those versions may have resolved.
6. If your security team wants to go deeper, review the current indicators of compromise and host-level findings published by incident responders.

This is the part many teams get wrong. They ask whether the frontend bundle is safe now. The harder question is whether the machine that ran the install can still be trusted.

How Laravel teams should harden now

Pin Axios to a known-safe release, commit the lockfile, and prefer npm ci in CI so builds use the dependency tree you already reviewed instead of resolving a fresh one under pressure. Audit Dockerfiles and CI workflows for any step that does ad hoc package resolution during deployment, because production deploys are a bad time to discover you handed dependency selection to the public registry.

This is also a good moment to add dependency monitoring or malware scanning to CI if you have not already. Pinned dependencies and committed lockfiles are not glamorous, but this is exactly why they matter.

Why this matters for Laravel specifically

Laravel developers are used to thinking about Composer risk first. That is understandable, but incomplete. A modern Laravel app often has two supply chains: PHP packages and JavaScript packages. When the JavaScript side is compromised, the blast radius is often larger than people expect because the install path can touch .env, cloud credentials, deploy tokens, repository tokens, and build caches long before a browser ever loads the bundle.

For Laravel teams, the real danger is the machine that ran the install. That is also why we care so much about keeping secret access local, explicit, and auditable. If you want the architectural version of that boundary, Ghostable’s zero-knowledge security overview explains why local encryption and decryption matter when build systems or shared environments go sideways.

Final takeaway

If your Laravel app or pipeline resolved axios@1.14.1 or axios@0.30.4, do not frame this as “the frontend dependency was briefly bad.” Frame it as “a build or developer environment may have executed malicious install-time code on March 31, 2026.”

That is the right level of seriousness. This was not a Laravel bug. But Laravel teams were absolutely in the blast radius.