Supply Chain - @jfrog-boost/boost Package Install or Binary Execution

How the attack works

An agent or CI process installs or invokes the @jfrog-boost/boost package, either through a package manager command or by running the shim binary it places in node_modules/.bin. Because npm lifecycle scripts and installed binaries run unsandboxed, any malicious code in a compromised release would execute inside the same process tree as the agent or build job, inheriting its file access, credentials, and network reach. The rule flags any command line containing this specific package name or its installed binary path.

Netzilo detection

Why it matters

If this package were ever compromised or swapped for a lookalike, an organization using it could have attacker code running with the same access as its CI pipeline or AI agent — including secrets, source code, and deployment credentials reachable from that process.

What you can do

• →Confirm who added @jfrog-boost/boost to your dependencies and verify it was an intentional, vetted choice, not a typosquat of a similarly named package.
• →Pin the package to a specific known-good version and hash rather than allowing floating version ranges.
• →Review what privileges the process installing or running this package has, and restrict CI/agent service accounts to the minimum needed.
• →Treat this as an inventory signal, not proof of compromise — there is no known CVE or confirmed malicious release at this time, so investigate context (who ran it, from where) before taking action.

Known benign look-alikes

• First-time or routine installation of @jfrog-boost/boost by a developer or CI job that has legitimately vetted the publisher. Installation is not itself malicious, which is why this rule reports rather than blocks.
• Automated dependency bots (Renovate, Dependabot) re-resolving the dependency on every scheduled run in a repository that already depends on the package.
• SBOM, SCA or provenance tooling (syft, osv-scanner, trivy, cyclonedx) that passes the package coordinate or purl to a child process. Read-only npm/pnpm/yarn/bun metadata subcommands are filtered, but third-party scanners that shell out with the name as an argument are not and will surface.
• Manifest maintenance that rewrites the dependency string via sed/awk/jq against package.json or a lockfile.
• An unrelated package that also ships a bin named "boost" into node_modules/.bin. The C++ Boost toolchain does not install there, so this collision is rare.

References

• https://attack.mitre.org/techniques/T1195/002/
• https://atlas.mitre.org/techniques/AML.T0010

Related threats