The decentralized AI network Bittensor is recovering from a devastating supply chain attack that resulted in the theft of approximately $8 million worth of TAO tokens. The post-mortem, published by the Opentensor Foundation, reveals a sophisticated attack vector that targeted the project’s Python package repository, exposing critical vulnerabilities in how crypto projects manage their software dependencies.
On July 2, 2024, at 7:06 PM UTC, an attacker began transferring funds from compromised Bittensor wallets. Within 19 minutes, the Opentensor Foundation detected abnormal transfer volumes and immediately convened a war room. By 7:41 PM UTC, chain validators were placed behind a firewall and the network entered safe mode, halting all transactions.
The Exploit Mechanics
The attack was traced to a malicious version of the Bittensor package uploaded to the Python Package Index (PyPi). Specifically, version 6.12.2 of the package contained obfuscated code designed to steal unencrypted coldkey details from users’ machines.
When users downloaded this compromised package and performed operations requiring key decryption — such as staking, wallet transfers, or delegation — the malicious code silently captured the decrypted bytecode and transmitted it to a remote server controlled by the attacker. The stolen credentials were then used to drain funds from affected wallets, with an estimated 32,000 TAO tokens, valued at approximately $8 million at the time, siphoned to a wallet beginning with the prefix 5FbWTr.
The malicious package was available on PyPi between May 22 and May 29, 2024, meaning users who downloaded it during that window were exposed for over a month before the attack was executed in early July.
Affected Systems
The vulnerability specifically impacted users who performed any of the following operations using Bittensor version 6.12.2:
- btcli stake add — adding stake to the network
- btcli stake remove — removing stake from validators
- btcli wallet transfer — transferring TAO between wallets
- btcli root delegate — delegating stake to root network
- btcli root undelegate — removing delegation
- btcli root set_take — setting delegation parameters
- btcli subnet register — registering on a subnet
Users who were solely delegating stake without performing these operations, using third-party applications, or holding funds without moving them during the affected period were not compromised. Critically, the Bittensor blockchain itself and the Subtensor protocol remained uncompromised — the attack targeted only the client-side tooling.
The Mitigation Strategy
The Opentensor Foundation responded with a multi-pronged approach. The malicious 6.12.2 package was immediately removed from PyPi. The team conducted a comprehensive code audit of both Subtensor and Bittensor repositories to identify any remaining attack vectors, finding no additional vulnerabilities.
The network was gradually brought back online after the code review was completed. The foundation also collaborated with cryptocurrency exchanges to trace the attacker and potentially recover stolen funds, while community members contributed independent analysis to support the investigation.
For affected users, the recommended remediation was to create entirely new wallets and transfer any remaining funds once the network resumed normal operations. This approach, while inconvenient, ensures that any compromised keys are fully abandoned.
Lessons Learned
The Bittensor incident underscores a fundamental truth in cryptocurrency security: the weakest link is often not the blockchain protocol itself, but the software supply chain surrounding it. Package managers like PyPi, npm, and others are common targets for attackers because they serve as trusted distribution channels.
Several key takeaways emerge from this incident. First, projects must implement rigorous code signing and verification for all published packages. Second, users should verify package checksums before installation. Third, hardware wallets and air-gapped key management should be standard practice for holding significant crypto assets. Fourth, the 19-minute detection and response time demonstrates the value of real-time monitoring systems.
User Action Required
Anyone who used Bittensor version 6.12.2 between May 22 and July 2, 2024 should assume their keys are compromised. If you performed any wallet operations during this period, create a new wallet immediately and transfer your funds. Monitor the official Bittensor communication channels for updates on fund recovery efforts and network status changes.
For the broader crypto community, this incident serves as a stark reminder to treat software dependencies with the same caution as private keys. As the crypto industry matures and attracts more sophisticated attackers, supply chain security will become increasingly critical to protecting digital assets.
Disclaimer: This article is for informational purposes only and does not constitute financial or security advice. Always conduct your own research and consult with security professionals regarding the protection of digital assets.
19 minutes from first transfer to war room is actually pretty fast. most projects take hours to respond. the damage was already done tho
The fact that a PyPi package with obfuscated code stealing coldkey details went undetected is alarming. Who audits their pip dependencies before installing?
^ literally nobody. thats the problem. pip install feels safe because everyone does it. this is going to happen again and for way more than 8M
8M is actually small for a supply chain attack. imagine if this hit a more widely used library. could have been hundreds of millions
nobody audits pip deps because the ecosystem treats requirements.txt as an afterthought. crypto projects need dedicated supply chain security, not just smart contract audits
version 6.12.2 specifically. always pin your versions and verify checksums people. this was completely preventable
pinning versions wouldnt help if 6.12.2 was the first malicious version. you need to verify hashes against the maintainers published checksums
pinning versions AND verifying checksums together would have stopped this. either one alone is not enough if the upstream is compromised