Q3 2026 Crypto Hacks: $1.18 Billion Lost, and 77% Passed Outside Security Reviews

Between 1 July and 28 September 2026, $1,180.8 million was stolen across 107 incidents, 55% more than in the second quarter. That is the finding of Hacken, a blockchain security firm, in its quarterly report. The total is not the part worth reading closely. According to Hacken, 77% of the losses, $906.8 million, came through a compromised supplier, a public fix that had not yet been deployed, or a component outside the most recent security review. This article walks through the cases one by one, using primary sources where they exist, and separates what is documented from what is still an estimate.

The quarter in Hacken's numbers

The report covers 1 July to 28 September 2026. The main figures, all taken from Hacken's document:

• $1,180.8 million stolen across 107 incidents, 55% more in value than in Q2.
• Application smart contracts accounted for 71 of the 107 incidents but only $228.2 million, 19% of losses. Most of the value left through chain-level code, suppliers, custody and wallets.
• By attack type, Hacken attributes 48% of losses to smart contract exploits and 40.4% ($477.6 million) to access control and operational failures.
• Fines issued to crypto-asset service providers worldwide came to just $450,000.

A cautious comparison: other trackers count different numbers for the same period because reference dates, inclusion thresholds and valuation methods differ. Secondary reports put CertiK at about $1.26 billion, for example. We did not read that report directly, so we mention it only as an order of magnitude. What matters is that the estimates converge on a quarter close to $1.2 billion.

The 77%: three routes, eleven incidents

Hacken's table is the core of the document. It says three attack paths concentrated most of the losses in just 11 incidents:

Two points on reading it correctly. First, 77% does not mean "77% the suppliers' fault". Compromised suppliers are the first route, at 35%. The other two cover fixes already public but not yet applied, and components that no recent review had covered. Anyone quoting "77% of hacks come from suppliers" is misreading the table. Second, two supplier incidents alone, $411.5 million, exceed the other 96 incidents combined ($274.0 million). That disproportion, more than the total, is why the subject matters.

One more note for readers following the cases: the three-route table does not include Coldcard. Hacken treats it separately, in the section on incidents where earlier reviews missed the conditions behind the problem. We cover it below.

Bitget: $387.5 million through a third-party security product

What is documented. On 24 September 2026 at 18:31 UTC an attacker began unauthorized transfers from certain Bitget hot and warm wallets; at 19:05 the reconciliation system flagged the anomaly and risk control automatically blocked withdrawals. That is according to Bitget's official incident page. Hacken puts the theft at $387.5 million across 11 blockchains, including Ethereum, the XRP Ledger, TRON, Arbitrum, Base and BNB Chain, with XRP the largest single asset at roughly $158 million. Bitget gives a "final verified" figure of about $388 million across 12 addresses.

How, according to Bitget. The company says the attacker exploited a zero-day vulnerability in a third-party security product, obtained high-privilege internal credentials and wrote forged withdrawal commands into the wallet system, which treated them as normal withdrawals and bypassed risk controls. After the transfers, Bitget adds, the attackers deleted traces. Private keys and cold wallets, the exchange says, were untouched. On 30 September Bitget published two independent reports, from Mandiant (Google Cloud) and SlowMist, which it says confirm the attack path. Hacken adds that the reports, released by Bitget, trace the entry point to the third-party product and date the earliest malicious activity in the available logs to 31 August, almost four weeks before the theft.

What is not documented. In the sources we could read, the vendor of the product is not named. We therefore cannot assign responsibility to any specific company, and we do not. Hacken also reports that Bitget considers North Korean involvement "very likely", citing IP behavior. That is a party's assessment, not an attribution confirmed by an authority, and we report it as such. We read the Mandiant and SlowMist reports only through Bitget's page and Hacken's report.

Users. Bitget states that user balances were unaffected and the impact is covered by its own protection fund. Hacken records that operators covered about $410 million for users from their own funds, of which $387.5 million was Bitget's user protection fund. Withdrawals were restored in stages: BTC on 28 September, ETH on 29, USDT on 30, everything else on 2 October. One reading note: Bitget's page gives different figures for the protection fund in different places (3,705 BTC and over $314 million in the header, 5,500 BTC and over $464 million in the FAQ). They may refer to different dates, but anyone who wants to verify the number should look at the on-chain addresses the exchange declares, not the summary.

Recovery. According to Hacken, Circle and Tether froze only about $0.34 million from the Bitget theft. Bitget says fund tracking continues and offers a 5% bounty on frozen or recovered amounts traced through reported leads.

Liquid Network: 36 minutes and a half-fix

Liquid is the case that best illustrates Hacken's second route, "public fix exploited before deployment". The sequence, from the report and from the Elements repository on which Liquid is built:

• 1 September: a partial fix, adding transaction context to the cache key, is public in the Elements repository. It leaves the encoding ambiguous.
• 6 September: an attacker exploits the ambiguity in the range-proof verification cache, the checks that prove an amount is valid without revealing it. A proof validated for one asset and context is reused for another. Result: 3,998.5 L-BTC minted with no BTC behind them. A peg-out of about 4,000 BTC is then confirmed on Bitcoin.
• 7 September: the attacker, who describes themselves as a white hat, returns about 3,400 BTC ($272 million) on condition that the flaw be fixed, and keeps 598.5 BTC, about $47 million, as a self-assigned bounty.
• 8 September: the complete fix is merged (pull request #1600 in the Elements repository, which we checked). 9 September: Elements 23.3.4 ships.

Two cautions. The return of 85% is a fact documented by Hacken, but "white hat" is the attacker's own label, not a third-party judgment: in the sources we read there is no record of any prior authorization to keep those $47 million, and calling it a bounty is the attacker's own definition. Second, Hacken's lesson concerns the handling of the fix cycle: eight days separated the partial public patch from the definitive release. The public record shows the chronology; it does not establish how the attacker found the flaw, and we do not claim to know.

Tectonic and Cronos: a correct price that could not be used

On 30 August, according to the post-mortem published by Cronos and reported by crypto.news, an attacker manipulated the price of TONIC, the thinly traded governance token of the lending protocol Tectonic, and used it as collateral to borrow $120.4 million across nine markets. Hacken adds that the price was pushed up against thin liquidity in about 11 minutes and that Tectonic accepted the inflated price as collateral value.

The point, which Hacken derives from the protocol's published parameters, is that none of three controls that could have stopped it was in place: a liquidity-depth limit, a velocity limit on how fast borrowing power could follow the spot price, and a working borrow cap. Tectonic's parameters list a borrow cap of 0 for every market, and in its Compound-derived code a zero means "no cap". RedStone co-founder Marcin Kazmierczak told crypto.news that this was not an oracle failure: the oracle correctly reported the price in the market it monitored, and the protocol accepted it without considering whether enough liquidity existed to sell the collateral at that value. Tectonic's code had been through four audits, one of them on the core lending logic. Hacken draws an important distinction: checking that a contract calculates collateral correctly does not establish that the parameters for one collateral asset are safe in its real market. This is what the table calls a "component outside the most recent review".

The response was unusual. Cronos validators halted the chain at block 90,907,150 and restored it to block 90,896,188, the last before the attack, discarding 10,961 blocks, or 1 hour and 54 minutes of history. About $111.2 million of the $120.4 million involved was reversed. $9.19 million (7.6%) that had already left the chain remains outside reach. The Cronos post-mortem acknowledges it was a "hard decision" and that the rollback also erased the transactions of ordinary users in the same window. The price of recovery was giving up, in that case, the irreversibility of recorded history, a principle many consider central to public blockchains. Hacken flags this as a regulatory gap: none of the frameworks it reviewed requires firms to disclose whether settlement on a chain can be reversed.

Coldcard: a build error that survived five years

Here Hacken is not describing a compromised supplier. Coldcard is about entropy, the randomness used to generate seeds. For that reason we treat it separately from the 77% table, and keep it distinct from the Ledger case, which is an attack on distribution, not a design flaw.

What the manufacturer says. Coinkite, which makes Coldcard, published a technical analysis. According to the company, a 2021 change when moving to a library for elliptic-curve operations caused seed generation to draw on MicroPython's software pseudorandom generator instead of the hardware generator. Coinkite describes an integration error at build and link time, not a design choice: in its words, "there was no intentional weak-entropy fallback". The code guard checked whether a setting was defined rather than whether it was enabled, so the build did not stop. Affected versions are firmware 4.0.1 to 4.1.9 for Mk2 and Mk3, plus the equivalent releases for later models. Coinkite estimates, preliminarily, an effective search space of about 40 bits on Mk2 and Mk3 and about 72 bits on Mk4, Mk5 and Q, against the 128 bits intended for a 12-word seed. The company also states that the devices were not hacked or remotely accessed: attackers regenerated the corresponding keys offline.

What the theft data says. The first drains began on 30 July. TRM Labs, in an analysis dated 5 August, already counted about 1,816 BTC (around $116 million) from more than 5,200 addresses in four waves, citing Galaxy Research's tally, and stressed that the data was preliminary and that transaction patterns suggested more than one attacker: TRM did not attribute the theft to a specific actor. In its later report, Hacken gives 1,789.28 BTC across 8,865 addresses attributed by Galaxy Research to the incident, about $114.7 million at the time of theft, and puts losses at roughly $115 million. The figures differ because they have different dates and methods. A figure of about $130 million circulated among outside researchers in early August; Coinkite said it would not speculate on the extent of losses and would publish a full analysis when safe to do so.

The point that matters for this investigation. Hacken writes that a paid review in March 2022 covered entropy hardening but did not identify the build condition. Coinkite confirms the substance: the existing review "confirmed that the intended TRNG implementation was present in the firmware binary, but did not verify which implementation the wallet seed-generation path actually reached". That is the theme of the report: a check that looks at the right component can miss the wrong connection. The defect, says Hacken, went undetected for more than five years. Coinkite adds that a few weeks before the incident it used one of the best available AI models to review its code, and it did not find the problem. That is the company's own statement; we have not verified it.

What it means for owners. A firmware update does not repair seeds already generated. According to Coinkite, seeds created on affected firmware without at least 50 independent, private dice rolls and without a strong, unique BIP-39 passphrase should be treated as at risk and replaced by generating a new seed on fixed firmware and moving the funds. The company does not consider seeds created with at least 50 dice rolls at risk from this flaw alone. The full instructions are in its official advisory: follow them from there, not from a summary.

Not in the quarter's data: the Ledger case

Hacken's period ends on 28 September. The Ledger/CryptoBilis incident is from October: the first drains were reported on 9 October, and only third-party estimates of the losses exist, between $86 and $103 million. It is therefore not in this article's numbers, and Ledger has not published a total. But it is the same pattern in a different form: one part of the chain, here distribution, sits outside what security reviews inspect. We reconstructed the case, with what is confirmed and what is not, in our article Ledger LTE Implant: What Is Confirmed, What Is Not.

One passage in Hacken's report connects the two worlds. Its review of European rules notes that none of the frameworks examined covers devices that clients buy for self-custody, and that DORA reaches a hardware supplier only when it provides services to a regulated firm. The Coldcard defect, Hacken notes, went undetected for more than five years. Someone buying a hardware wallet today is, in practice, outside almost all regulatory protections on component security.

Recovery: a third, by very different mechanisms

Hacken calculates that about $387 million, 33% of gross losses, was returned or reversed. The report separates three mechanisms that work differently and are not equivalent:

• Attacker return: $272 million (Liquid Network, 85% of the $319 million taken). It depends entirely on the will of the person who took the funds.
• Chain-state intervention: about $116 million, including the Cronos rollback ($111.2 million of the $120.4 million involved), a BounceBit snapshot restore and a $2.1 million sweep of ATOM on Cosmos Hub. It depends on validators, and it costs finality.
• Issuer freeze: about $0.34 million (Circle and Tether, from the Bitget theft). It depends on the issuer and on speed.

On top of that, operators covered about $410 million for users from their own funds; those users were made whole while the stolen assets stayed with the attackers. The picture is plain: real recovery from the market was small, and the safety net was mostly the balance-sheet strength of whoever ran the funds.

What regulators are doing, according to Hacken

The regulatory part of the report is shorter but carries two signals. First, regulators are starting to test whether controls hold up in continuous operation, not just at a single point of review. Second, Hacken notes that regulators increasingly hold specific founders and senior executives personally responsible for exploits and incidents. Worldwide fines on crypto service providers, $450,000, are tiny next to $1.18 billion stolen. We flag the comparison without drawing a conclusion about the penalty system: they are data on different things (sanctions issued and losses suffered) and cover different jurisdictions.

What it means for you

This section is general information, not financial advice.

If you keep funds on an exchange

The Bitget case shows that proof of reserves measures one thing and an attack hits another. A proof of reserves tells you whether the exchange declares enough assets to cover balances; it says nothing about how well internal access and withdrawal systems are protected. It remains a useful tool, but it does not answer the question of how a company manages its suppliers. How to read and verify one is in our proof of reserves guide. This quarter, according to Hacken, users of the affected exchanges were made whole by the operators: that is not a guarantee for all future cases, it is an observed fact of this period.

If you self-custody

• If you own a Coldcard, check Coinkite's official advisory for your model and the date your seed was created. Updating the firmware is not enough.
• If you are buying a hardware wallet, buy from the manufacturer and distrust unofficial channels. The Ledger case is the demonstration.
• Do not rely on one device for a large sum. TRM Labs, commenting on Coldcard, observes that multisignature setups combining independently designed devices and independently generated entropy offer defense in depth, because they reduce reliance on a single implementation. It is a setup that needs care: our 2-of-3 multisig guide explains how. And remember that a complete custody plan also covers who can reach the funds if you cannot: the Bitcoin inheritance plan.

If you use decentralized finance

The Tectonic case is not about wrong code in the narrow sense. It is about the parameters of a single asset in a lending protocol. When a protocol accepts a thinly traded token as collateral, the "correct" price may not be a usable price. Before depositing into a protocol, it is worth knowing which assets it accepts as collateral and whether real borrow limits exist, not set to zero.

What we still do not know

• The name of the vendor of the security product used by Bitget. It does not appear in the sources consulted.
• The identity of the attackers in Bitget, Liquid, Tectonic and Coldcard. Bitget considers North Korean responsibility likely, but that is a party's assessment.
• The final tally for Coldcard: TRM and Hacken both call the data preliminary, and Coinkite has yet to publish its full analysis.
• Whether the Mandiant and SlowMist reports on Bitget will be made public in full. We read them only in Bitget's and Hacken's summaries.
• The share of the quarter's losses not yet counted. Hacken and TRM warn that victims often emerge months later.
• How far Hacken's choice, as a firm that sells security reviews, to classify losses as "outside the most recent review" depends on how it drew its categories. The classification is its own, and another analyst could draw the boundaries differently.

Our assessment

The documented facts say something precise and less comfortable than the usual story about hacks. In the third quarter of 2026 the largest part of the money did not leave through a badly written contract, but through points in the chain that no review was looking at: a supplier's security tool, a flaw whose fix was public but incomplete, a risk parameter, a line of compiler configuration. Application smart contracts, the traditional target of audits, produced most of the incidents but only 19% of the losses.

This does not make audits useless, and it does not license the claim that suppliers are to blame. Whoever runs an exchange or a protocol chooses its suppliers, and Hacken itself notes that reviews did not cover components that could nonetheless touch prices, messages, governance or lending. For the ordinary reader the lesson is a practical test: the question to ask about a service is not only "was it verified?" but "what was not verified?". Few operators answer that second question explicitly, and this quarter's data suggest it is the one that matters most.

We will update this article if Coinkite publishes its full analysis, if Bitget makes its independent reports public or names the vendor involved, or if Hacken revises its figures.

Frequently asked questions