The Axios Breach and Your Salesforce Org's Real Blast Radius

Alex Mracek – March 31, 2026

It's not about whether your platform was compromised. It's about everything connected to it.

On March 31, 2026, attackers hijacked the npm account of the lead maintainer of Axios, one of the most widely used JavaScript libraries worldwide. They published two malicious versions containing a hidden dependency that silently installed a Remote Access Trojan (RAT) on any machine that ran npm install. The compromised packages were live for roughly three hours before npm pulled them.

Three hours. For a library downloaded over 100 million times per week.

If you work in the Salesforce ecosystem, your first instinct might be to shrug this off. Axios isn't a Salesforce product. It's not on the AppExchange. Salesforce's core platform wasn't compromised. And that instinct is exactly the problem.

Your Org Doesn't Exist in Isolation

Salesforce orgs don't run on Salesforce alone. They run on an ecosystem of connected systems: middleware, custom integrations, AppExchange packages, CI/CD pipelines, and tools built by internal teams or SI partners. Many of those systems are built with JavaScript. Many of them use npm packages. And some of them may be running a version of Axios that was weaponized this morning.

The blast radius here isn't defined by what Salesforce builds and maintains. It's defined by everything that touches your org from the outside.

Consider the surface area:

  • Custom integrations built by your team or an SI partner that sync data between Salesforce and external systems. If those run on Node.js (and many do), they likely have Axios or a similar HTTP client in their dependency tree.
  • AppExchange packages with server-side components. You trust the vendor, but do you know what's in their dependency chain?
  • CI/CD pipelines that deploy to your org. If a build server pulled a compromised Axios version during a routine install, it may have exposed credentials, API keys, and deployment tokens.
  • Middleware platforms like MuleSoft, Heroku, or AWS Lambda functions that broker data between Salesforce and the rest of your stack.

None of these are "Salesforce breaches." All of them are your problem.

Supply Chain Attacks Are the New Normal

This isn't an isolated incident. It's an unfortunate pattern.

The ShinyHunters campaign, which dominated Salesforce security headlines throughout 2025 and into 2026, exploited social engineering and third-party integrations (Salesloft/Drift, misconfigured Experience Cloud sites) to exfiltrate data from major enterprise orgs. Salesforce's platform wasn't breached in those attacks either. Customer data was still compromised at scale.

The Axios attack is the same lesson from a different angle. The platform can be rock-solid and your data can still walk out the door through a compromised dependency three layers deep in a tool you didn't even know was running.

Supply chain attacks target the trust relationships between systems. And Salesforce orgs, by design, have many trust relationships.

What You Should Do Today

This isn't about panic. It's about visibility. If you're responsible for a Salesforce org (or the systems connected to it), here's where to focus:

1. Audit your integration layer. Identify every system that reads from or writes to your Salesforce org via API. For each one, determine whether it uses Node.js and whether Axios is in the dependency tree. If anyone ran npm install between approximately 00:21 and 03:15 UTC on March 31, that system should be treated as potentially compromised.

2. Check your CI/CD pipelines. Build servers that deploy to Salesforce (via SFDX, CumulusCI, or custom tooling) may have pulled the compromised version during an automated build. Review your lockfiles for axios@1.14.1, axios@0.30.4, or plain-crypto-js@4.2.1.

3. Talk to your SI partners. If you work with a Salesforce consulting partner that builds or maintains custom integrations on your behalf, ask them directly whether any of their development or build environments were affected. A good partner will already be checking.

4. Review your AppExchange footprint. For packages with server-side components or external callouts, reach out to the vendor and ask whether their infrastructure was exposed. This is a reasonable question to ask right now.

5. Pin your dependencies. If your team manages any custom code that touches Salesforce, stop using floating version ranges in your package files. Lock to specific, verified versions. This is a best practice that prevents exactly this kind of silent upgrade.

6. Rotate credentials proactively. If there's any doubt about whether a connected system was exposed, rotate the API tokens, OAuth credentials, and connected app secrets that link it to your Salesforce org. Don't wait for confirmation.

The Bigger Question

The Salesforce Ben article covering this breach made a sharp observation about "vibe coding," the practice of letting AI tools generate and install packages without fully understanding what's being added. That's a real risk, and it extends beyond individual developers.

The bigger question for Salesforce leaders is this: do you have visibility into the full dependency chain of everything connected to your org? Not just what's installed inside Salesforce, but every external system, every integration, every build pipeline that has credentials to your data?

For most organizations, the honest answer is no. And that gap between what you control and what you're connected to is where the real blast radius lives.

Digital Mass is a developer-led Salesforce consultancy that builds and architects the integrations, automations, and custom solutions that enterprises depend on. If you're unsure about your org's exposure to supply chain risks like this, we can help you find out.