Malicious npm package “indexed-btree” concealed its payload in application runtime code rather than lifecycle scripts, evading security controls that monitor npm install hooks, according to Checkmarx researchers who disclosed the package on September 22, 2026.
The package mimics the legitimate “sorted-btree” library, a B-tree and indexing utility. The tactical shift to runtime execution instead of lifecycle-based malware represents an evolution in how threat actors bypass npm security mechanisms. The package has been removed from the npm registry.
indexed-btree Mimics Legitimate sorted-btree Library
The malicious package used the name “indexed-btree,” closely resembling the legitimate “sorted-btree” npm package. Developers searching for B-tree implementations or indexed data structure utilities could encounter the malicious package alongside the authentic library.
B-tree packages are commonly used in applications requiring ordered data storage, indexing, and efficient search operations. Developers working on database tools, caching layers, or search functionality might install a B-tree package without exhaustive vetting, particularly if the package name suggests a variant or extended version of a known library.
Malicious Behavior Executes During Application Runtime, Not Install Lifecycle
Traditional malicious npm packages hide their payloads in lifecycle scripts—preinstall, postinstall, or preuninstall hooks that execute during npm install or npm uninstall commands. These lifecycle events trigger automatically when a package is added or removed, making them a natural injection point for malicious code.
npm security tools, static analysis scanners, and registry monitoring systems focus heavily on lifecycle scripts as the primary risk vector for malicious packages. Packages with suspicious postinstall scripts trigger warnings, automated reviews, or outright blocks in some environments.
indexed-btree evaded this detection layer by placing its malicious logic in the package’s runtime code—the code executed when the application imports and uses the package, not when the package is installed. Developers installing the package would not see malicious activity during npm install. The payload activates only when the application runs and calls functions from the indexed-btree module.
Checkmarx Researchers Disclosed Package September 22
Checkmarx published the indexed-btree analysis on September 22, 2026. The researchers identified the package as a tactical shift by threat actors seeking to evade lifecycle-script-focused security controls.
The disclosure did not specify when the package was uploaded to npm, how many downloads occurred before detection, or what specific malicious actions the runtime payload performed. The absence of a timeline means organizations cannot easily determine their exposure window or assess whether their build systems downloaded the package.
Runtime Execution Evasion Challenges npm Security Controls
npm security tools and registry scanners primarily analyze lifecycle scripts for malicious behavior. This focus reflects the historical reality that most malicious npm packages hid their payloads in postinstall hooks, making lifecycle analysis the highest-yield detection strategy.
indexed-btree’s runtime execution model bypasses this detection paradigm. A package with clean lifecycle scripts passes automated security checks, even if its runtime code contains malicious functions. Detection requires deeper static or dynamic analysis of the package’s actual codebase—examining every function, tracing data flows, and identifying credential access or exfiltration logic embedded in seemingly benign utility functions.
Developers Must Audit Runtime Code, Not Just Lifecycle Scripts
The indexed-btree disclosure shifts the security burden from install-time checks to runtime code review. Developers auditing dependencies must inspect the package source code, not just the package.json lifecycle hooks.
For many development teams, this level of scrutiny is impractical. Modern applications pull in hundreds or thousands of npm dependencies, each with its own transitive dependencies. Manually reviewing every package’s runtime code before installation does not scale.
Automated tools can help, but runtime malware detection requires more sophisticated analysis than lifecycle script scanning. Static analysis must identify suspicious function calls—network requests to unknown domains, file system writes to sensitive paths, environment variable exfiltration—hidden within otherwise legitimate-looking code.
Implications for npm Supply Chain Defense
The shift to runtime execution malware in npm packages indicates threat actors are adapting to security controls. As lifecycle-script monitoring becomes widespread, attackers move payloads to execution contexts those tools do not inspect.
Organizations relying on npm packages should audit their dependencies for “indexed-btree” in package-lock.json or node_modules. If the package was installed, treat it as a credential compromise incident—rotate API keys, review application logs for exfiltration, and scan build systems for persistence mechanisms.
The package has been removed from the npm registry, but packages downloaded before removal remain in local caches, private registries, and deployed applications. Teams must actively search for and remove the package, not assume registry removal solved the problem retroactively.
Future npm security strategies must account for runtime execution as a malware vector. Lifecycle script analysis remains necessary but insufficient. Sandboxed package execution, runtime behavior monitoring, and comprehensive static analysis of package codebases will become essential components of supply chain defense as attackers continue to shift tactics.
Checkmarx’s disclosure demonstrates that npm malware detection is an evolving arms race. Every improvement in detection drives attackers to new evasion techniques. Organizations cannot rely on a single detection mechanism—lifecycle script scanning, dependency version pinning, or registry curation—and must layer multiple controls to catch threats that evade any single tool.
