Malicious npm Package indexed-btree Bypasses Install-Time Security Checks

What Checkmarx found

Researchers at Checkmarx identified indexed-btree as a package impersonating the legitimate sorted-btree library, and traced it to a wider operation controlling at least nine other npm packages. Checkmarx says nine additional packages linked to the operation were removed from npm. Together with indexed-btree, one of those packages, btree-core, had itself pulled in 1,951,274 downloads, giving a sense of how far this tooling had spread through dependency trees before anyone noticed.

Checkmarx also flagged a wallet associated with the campaign holding 109 ETH, though its report stops short of saying those funds came from stolen cryptocurrency. The attackers reportedly went to considerable lengths to make the project look genuine, building out a convincing GitHub repository, fabricating a plausible commit history, and cultivating a credible-looking developer account — the kind of social engineering that defeats a quick manual review just as easily as it defeats an automated scan.

Why the runtime trick works

The technical innovation here is where the malicious loader sits. Rather than firing during npm install, the code is embedded in the package's BTree.prototype.set() method — a function Checkmarx describes as one every user would call constantly — and only activates when the application invokes it with a specific key value. Because nothing runs at install time, the package looks completely clean to any tool checking install-time behaviour, and the trigger only fires once the code is genuinely in production use.

Once activated, the malware pulls in an obfuscated first-stage payload, harvests system details such as architecture, hostname, CPU, memory and uptime, and exfiltrates that data via hardcoded Slack and Telegram channels. Command-and-control instructions are then retrieved by polling a smart contract on the Ethereum Sepolia test network, using X25519 key exchange to derive an AES key that decrypts a second-stage payload stored on-chain. When operators want to disappear, the malware can delete its own files and strip the trigger out of the package code, erasing much of the forensic trail.

Where npm v12's defences fall short

GitHub's June 2026 npm security overhaul was built specifically to stop the last generation of supply chain attacks: it blocks lifecycle scripts such as preinstall, install and postinstall unless a developer explicitly approves them, and it stops npm from silently fetching dependencies from Git repositories or remote URLs. Those controls are genuinely useful against the attack patterns that dominated late 2025 and early 2026.

But indexed-btree simply avoids the mechanisms npm v12 was designed to police. It needs no lifecycle script and no unauthorised remote fetch, so it never trips the approval workflow at all. As Checkmarx put it, hiding the loader inside a function every user calls constantly is "a well-built way to sneak past standard taint-analysis tools and most static scanners." That's a meaningful gap for any organisation that treated npm v12 approvals as a finished answer to supply chain risk.

Part of a bigger pattern hitting UK pipelines

This isn't an isolated incident. It follows another npm worm attack that spread through hundreds of packages, and separate reporting linking major credential-stealing npm campaigns to North Korea npm supply chain operations. Taken together, these incidents show attackers deliberately probing for the weak seams left by each new registry defence, and UK development teams relying heavily on open-source JavaScript tooling are squarely in the blast radius given how deeply npm packages are woven into CI/CD pipelines and cloud-native builds.

The broader push toward stronger ecosystem controls, including the kind of measures discussed around GitHub PyPI supply chain security, is welcome, but this campaign is proof that registry-level gatekeeping has to be paired with monitoring inside the organisation, not treated as a substitute for it.

What UK infrastructure buyers should do now

Anyone who has installed indexed-btree or any of the nine linked packages — ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map or sliding-score-window — should treat their environment as potentially compromised. That means rotating all secrets, credentials and API keys touched by affected machines, and restoring development environments from a known-clean backup rather than assuming a clean-looking install log means a clean system.

For procurement and security leads, the strategic lesson is that install-time scanning alone is now an insufficient control. Checkmarx's findings suggest runtime behavioural analysis should sit alongside it, ideally through Managed Detection and Response services watching developer laptops and build runners, not just production. Teams weighing up options should also look at choosing the best EDR platform for endpoint coverage across CI/CD infrastructure, and consider implementing a Zero Trust model so a single compromised dependency can't reach broadly across cloud credentials and repositories.

• •Audit dependency trees for indexed-btree and the nine linked packages
• •Rotate all secrets and API keys on any affected machine
• •Restore development environments from verified clean backups
• •Add runtime behavioural monitoring, not just install-time scanning
• •Restrict blast radius with least-privilege and Zero Trust segmentation

The bottom line for security budgets

This campaign didn't need a zero-day or a stolen credential to reach millions of installs — it just needed patience, a convincing GitHub history, and a payload placed one function call deeper than most scanners look. That's a cheap trick to pull off and an expensive one to clean up if it lands inside a UK enterprise's build pipeline.

Budget conversations for the rest of 2026 should reflect that reality: pair registry-level trust signals with robust endpoint security solutions on developer machines, keep comprehensive backup and recovery in place so a compromised environment can be rebuilt fast, and treat every popular open-source dependency as a live attack surface rather than a solved problem.