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
rekt_dev_ 19 minutes is fast for crypto but the attacker still moved 8M worth of TAO in that window. response time matters less when the key is already gone
19 minutes from first transfer to war room is genuinely fast for a crypto project. most teams take hours to even notice. the 8M was already gone tho
freeze_hook_ response time was fast but version 6.12.2 being live on PyPi for days before anyone noticed is the real failure. supply chain monitoring needs to be continuous not reactive
version 6.12.2 sat on PyPi for days before anyone noticed. the 19 minute response after detection is great but the detection itself was embarrassingly slow
Sora T. 6.12.2 sat on PyPi for days before detection. the 19 minute response is great PR but the real story is their monitoring had zero automated checks for a compromised package version
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
Yuki Tanaka disagree on the small take. 8M from a single malicious package version is scary because the same attack on a top 10 library would drain billions
stack_overflow_ pip install is treated like a trust primitive by the entire dev world. crypto just amplified the consequences because keys live in the same environment as deps
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
19 minutes from first drain to safe mode is genuinely impressive incident response. most projects take hours just to acknowledge something is wrong on Discord
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
checksum_verify exactly. version pinning doesnt help if the pinned version IS the malicious one. hash verification against maintainer checksums is the only real defense
pip_freeze_ checksums against maintainer published hashes is the only defense. but who actually does that before pip install. maybe 1% of devs, maybe
coldkey details were stored unencrypted on disk. in 2024. these are the people securing an $8M treasury
pinning versions AND verifying checksums together would have stopped this. either one alone is not enough if the upstream is compromised
19 minutes from detection to safe mode is genuinely impressive incident response. most projects take hours just to acknowledge somethings wrong
pkg_historian_ 19 minutes from detection to safe mode is great but 6.12.2 sat live for days. the response time only matters if you know youre bleeding
pkg_historian_ detection was the slow part though. 6.12.2 was live for days before anyone noticed. fast response doesnt matter if you dont know youre bleeding
coldkey stored unencrypted on disk while securing an 8M treasury. supply chain security in crypto is years behind smart contract security
maybe 1% of devs verify pip checksums. the other 99% are running pip install with sudo on the same machine holding their treasury keys
coldkey unencrypted on disk while holding an 8M treasury in 2024. crypto security is still in the stone age compared to traditional fintech
pip_whisperer_ traditional fintech doesnt store signing keys unencrypted either. the gap is that crypto projects treat key management as an afterthought while fintech builds entire HSM infra around it
19 minute response time sounds great until you realize 6.12.2 was live for days. detection was the failure not response