Security: install.js runs bare npm install, exposed users to axios@1.14.1 supply chain attack

[SethCalkins]

Summary

@ladybugdb/core's install.js runs a bare npm install when building from source (line 67):

childProcess.execSync("npm install", {
  cwd: path.join(__dirname, "lbug-source", "tools", "nodejs_api"),
  stdio: "inherit",
});

This npm install resolves dependencies from the public registry at install time with no lockfile pinning. While the compromised axios@1.14.1 was live on npm (before it was yanked), this bare install could resolve to the malicious version, which contained a setup.js dropper that deployed a RAT on macOS, Windows, and Linux.

Any downstream package that depends on @ladybugdb/core (e.g., GitNexus) inherited this exposure.

The Problem

The npm install inside install.js has no package-lock.json to pin versions. It resolves whatever is latest on the registry at install time. This is a known anti-pattern that makes the build process vulnerable to any supply chain compromise on transitive dependencies.

Attack Chain

npm install <package-that-depends-on-@ladybugdb/core>
  → @ladybugdb/core install.js runs
    → bare "npm install" inside lbug-source/tools/nodejs_api/
      → npm resolves axios@1.14.1 from registry (compromised)
        → axios postinstall executes setup.js dropper
          → RAT deployed on victim machine

Huntress Advisory IOCs

This is part of a broader campaign tracked by Huntress:

Type	Indicator
Package	axios@1.14.1 (yanked, SHA1: 2553649f232204966871cea80a5d0d6adc700ca)
Package	axios@0.30.4 (yanked, SHA1: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71)
Package	plain-crypto-js@4.2.1 (SHA1: 07d889e2dadce6f3910dcbc253317d28ca61c766)
File	setup.js dropper (SHA256: e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09)
File	/Library/Caches/com.apple.act.mond (macOS RAT, SHA256: 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a)
Domain	sfrclak[.]com, callnrwise[.]com
IP	142.11.206[.]73
npm account	jasonsaayman (compromised axios maintainer)

Recommendations

1. Add a package-lock.json to lbug-source/tools/nodejs_api/ and commit it, so the internal npm install uses pinned, integrity-verified versions
2. Use npm ci instead of npm install in install.js to enforce lockfile resolution
3. Audit the dependency tree of lbug-source/tools/nodejs_api/package.json for any remaining references to compromised packages
4. Add npm audit to CI to catch yanked packages before publishing
5. Consider prebuilt-only distribution to eliminate the need for running npm install during package installation entirely (the prebuilt path in install.js already handles this correctly when binaries are available)

References

• Huntress advisory on the axios supply chain compromise (March 2026)
• axios@1.14.1 was published via the compromised jasonsaayman npm account and has since been removed from the registry

[adsharma]

Fixed by: LadybugDB/ladybug-nodejs#6