If you are using Bolt Open to build, package, test, or deploy JavaScript and TypeScript applications, this is the kind of warning you should not postpone until later.
Following the recent Axios npm supply chain compromise, any environment that installed the malicious versions axios 1.14.1 or axios 0.30.4 should be treated as potentially compromised. According to the official Axios post-mortem, both versions injected a malicious dependency, plain-crypto-js@4.2.1, and were live on npm for about three hours before being removed.
If you have not read the full background yet, start here: Axios npm Supply Chain Compromise: When a Trusted Package Becomes the Attack Path.
Most developers hear “package compromise” and assume the risk only applies to teams that manually updated dependencies during the attack window.
That assumption is dangerous.
If you use Bolt Open in a workflow that automatically installs dependencies, rebuilds projects, syncs environments, or runs CI jobs on fresh machines, then a compromised Axios version could have been pulled in without anyone consciously choosing it. This is especially true if your project used permissive version ranges such as ^1.14.0 or ^0.30.0.
Microsoft’s guidance is explicit: users who installed axios 1.14.1 or 0.30.4 should rotate secrets immediately and downgrade to safe versions. Safe targets are axios 1.14.0 for the 1.x line and axios 0.30.3 for the 0.x line, or any earlier clean version appropriate for your project.
This incident is not just about one package.
It is about how modern software gets built.
You do not need a dramatic breach of your own app for your environment to become exposed. A poisoned dependency can enter through a normal install, run during a routine build, touch a developer workstation, land inside CI, and quietly turn into a credential exposure problem before anyone notices.
That is what makes this kind of incident so frustrating. Everything can look normal right up until the moment you realize trust itself was the attack path.
You should act immediately if any of the following applies:
package.json and performed installs around March 31, 2026plain-crypto-js anywhere in your lockfile, node_modules, or install logsAccording to the Axios post-mortem, if you were already pinned to a clean version and did not run a fresh install between 00:21 and 03:15 UTC on March 31, 2026, you are likely fine. But if you are not sure, do not assume safety just because the window was short.
Microsoft also recommends avoiding automatic minor and patch upgrades for Axios until your team explicitly approves them.
Search your lockfiles and installed modules for compromised versions or the malicious dependency:
grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" package-lock.json yarn.lock 2>/dev/nullYou should also inspect CI logs, container build logs, and any Bolt Open build or deployment logs that include dependency installation output.
If your project depends on Axios directly, update package.json to an exact safe version instead of using a loose range.
{
"dependencies": {
"axios": "1.14.0"
}
}If your project is on the older line:
{
"dependencies": {
"axios": "0.30.3"
}
}If Axios is pulled in indirectly, use overrides so the safe version is enforced across the dependency tree:
{
"overrides": {
"axios": "1.14.0"
}
}Or:
{
"overrides": {
"axios": "0.30.3"
}
}Remove the malicious dependency, clean caches, and reinstall from a known-safe state:
rm -rf node_modules
npm cache clean --force
npm installIf you specifically find the malicious dependency, remove it as part of the cleanup:
rm -rf node_modules/plain-crypto-jsThis is the part teams most want to skip. Do not skip it.
If a machine installed one of the compromised Axios versions, the official guidance is to treat that machine as potentially compromised. That means rotating:
If the installation occurred on a CI runner, rotate every secret that runner had access to during the affected job.
The Axios post-mortem and Microsoft both recommend reviewing logs for outbound connections related to the malicious infrastructure, including:
sfrclak[.]com142.11.206.73 or closely related IP indicators mentioned by responders8000If your organization keeps egress logs, this is worth checking even if the dependency was only briefly present.
Until your team is comfortable again, replace ^ and ~ ranges with exact versions for Axios. This reduces the chance that a future patch release is pulled automatically into a sensitive workflow.
If your Bolt Open project uses tools like Dependabot or Renovate, consider temporarily restricting Axios updates until your review process is tightened.
Where possible, avoid running install scripts in high-trust environments unless they are necessary. Microsoft recommends using script restrictions when the scenario allows it.
npm ci --ignore-scriptsThat is not suitable for every project, but it is a useful hardening option for controlled environments.
A dependency added only to trigger install-time behavior can be easy to miss if a team reviews only runtime source changes. This incident is a reminder that dependency manifest changes deserve the same seriousness as code changes.
If you are a Bolt Open user and your project touched Axios during the affected period, this is not the time for “probably fine.”
Check the version. Pin the safe version. Clean the environment. Rotate secrets if necessary.
Supply chain compromises are dangerous precisely because they hide inside ordinary workflows. The installer looks normal. The build looks normal. The package name looks normal. And that is exactly why teams lose time before reacting.
Do not give this incident that extra time.
npm install axios@1.14.0 --save-exactnpm install axios@0.30.3 --save-exactyarn add axios@1.14.0 --exactpnpm add axios@1.14.0 --save-exactThe Axios compromise is already over as a registry event, but it is not over as a lesson.
For Bolt Open users, the practical takeaway is simple: move to a safe Axios version now, and treat any affected environment with the seriousness of a possible compromise.
If you want the broader context behind this warning, read our earlier breakdown here: Axios npm Supply Chain Compromise: When a Trusted Package Becomes the Attack Path.