indexed-btree is the subject of a September 17 technical disclosure explaining how a removed npm package waited for normal application calls before activating, shifting detection from installation to runtime behavior.
Key takeaways
- Checkmarx says the package triggered when software called BTree.prototype.set, not through an install script.
- Snyk records the package as malicious and removed; Socket shows npm replaced version 0.0.1 with a security holding package.
- The September 17 update adds technical mechanism detail to a malicious-package status that was public earlier in September.
What the indexed-btree disclosure changes
The indexed-btree incident is not newly dated malware. Its malicious status was already public in early September. What changed on September 17 was the level of technical disclosure: Checkmarx documented a runtime activation path that did not depend on the install hooks many defenders monitor or disable. That distinction matters because it turns an apparently ordinary library call into the execution boundary.
According to Checkmarx, the code waited until an application called BTree.prototype.set. It then gathered host information, tested whether the machine looked useful, and contacted external infrastructure. That sequence makes the package a useful case study in why supply-chain controls cannot end at installation. A clean install log does not prove that imported code will remain inert once the application starts using it.
Why normal install defenses missed the trigger
Security teams often give special attention to lifecycle scripts because malicious packages have repeatedly abused preinstall, install, and postinstall. Disabling those scripts reduces a real class of risk. It does not stop code that is loaded later and executed through an exported method. In this case, the trigger was attached to behavior a developer would reasonably expect from a B-tree library.
Checkmarx's analysis says the malware collected system details and could exfiltrate through Slack or Telegram webhooks. It also described a more elaborate second-stage path: a Sepolia smart contract supplied command-and-control data, while X25519 key exchange and AES encryption protected the payload channel. The researchers said the code attempted to remove traces after running. Those details are from the September 17 research and should be treated as the researchers' findings, not as evidence that every downloader was compromised.
What is independently confirmed
Snyk's vulnerability record labels every listed version malicious, maps the issue to CWE-506, and says the package was removed from npm. Its record says the issue was disclosed on September 4 and published on September 7. Socket's package page independently shows version 0.0.1 as a malware-detected security holding package published by npm. BleepingComputer separately reported the runtime-trigger technique after reviewing the Checkmarx findings.
The timelines solve an important freshness question. The removal and malicious classification were known before this seven-day recovery window. The publishable event here is therefore the later technical explanation of how the package evaded install-script-centered defenses. It is an analysis update, not a claim that the underlying compromise was first discovered on September 17.
Exposure is not the same as compromise
Checkmarx cited roughly two million weekly downloads for indexed-btree. Download volume describes potential distribution, not confirmed victim count. Automated builds, mirrors, caches, abandoned projects and repeated installs can all inflate the number of downloads relative to active systems. Neither the primary report nor the independent records establish that two million users executed the malicious path.
For incident responders, the useful question is narrower: did a relevant version enter a build, was it imported, and did an application call the affected method on a host with network access? Teams should search lockfiles, software bills of materials, package-manager caches and artifact repositories. They should then correlate that evidence with process creation, outbound webhook traffic and access to Sepolia endpoints during the relevant period.
A practical response sequence
First, remove the package and rebuild from a known-good dependency graph. Do not assume deleting node_modules on a developer laptop remediates deployed artifacts or cached containers. Rotate credentials only where telemetry or execution evidence justifies it, but prioritize secrets available to CI runners and developer environments because those machines often hold broad tokens.
Second, hunt for behavior rather than a single hash. The report describes multiple sibling package names, external webhook channels and a smart-contract-assisted command path. A signature tied to one archive can miss repackaged code. Runtime monitoring should flag unexpected child processes, network destinations and credential access from dependency code that normally performs in-memory data operations.
Third, keep install controls. They still eliminate a large attack surface. The lesson is additive: combine registry reputation, lockfile review, provenance, isolated builds and runtime controls. GitHub has separately announced stronger npm authentication and publishing safeguards, but publisher controls cannot by themselves identify a package whose code becomes harmful only after a normal method call.
The larger supply-chain lesson
The indexed-btree disclosure exposes a boundary problem. Package managers know what was fetched and installed; they do not know whether an exported function later behaves consistently with its purpose. Static review can spot suspicious strings, yet encrypted or staged behavior raises the cost. Sandboxed builds help, but the production process still needs least privilege and network policy.
That is why this case should change review questions. Teams should ask not only whether a dependency runs scripts during installation, but also what privileges it receives when imported, which methods can reach the network, and whether sensitive build or developer credentials are available to the application process. The September 17 findings make that runtime blind spot concrete without overstating the known victim count.
Facts at a glance
| Fact | Value | Source |
|---|---|---|
| Disclosure used for this update | 17 September 2026 | Checkmarx |
| Earlier malicious-package record | Disclosed 4 September; published 7 September | Snyk |
| Activation point | BTree.prototype.set at runtime | Checkmarx |
| Package reach cited | About 2 million weekly downloads | Checkmarx |
| Registry status | Removed / security holding package | Snyk and Socket |
| Command channel described | Sepolia smart contract with encrypted second stage | Checkmarx |
Related Lapaas Voice coverage
FAQs
Was indexed-btree newly discovered on September 17?
No. Snyk records disclosure on September 4. September 17 is the date of Checkmarx’s detailed runtime-mechanism report.
Did two million users get compromised?
No confirmed victim count was published. The cited figure is weekly downloads, which is not equivalent to successful execution.
Why did disabling install scripts not stop it?
The reported trigger ran when application code called an exported B-tree method after installation.
What should teams check first?
Lockfiles, SBOMs, caches and deployed artifacts, followed by runtime and outbound-network telemetry.
Sources
- Checkmarx technical disclosure — primary
- Snyk advisory — independent
- Socket package record — independent
- BleepingComputer report — independent
- GitHub npm v12 safeguards — context
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.
