IoTeX ioTube, February 2026: an ownership signal 14 minutes before the first withdrawal

On February 21, 2026 an attacker took over the ioTube bridge on Ethereum. About $4.4M of reserves left the bridge, and hundreds of millions of CIOTX were minted out of nothing¹². IoTeX detected the incident at 08:01 UTC, almost seven hours after the first on-chain step¹.

This post does not retell IoTeX's review. It asks three questions. When did the chain first show that something was wrong? How much time was left after that? And what could a team do in that time?

How ioTube works

ioTube moves tokens between IoTeX and other chains. On Ethereum it is a handful of contracts, and the attack makes sense only once you know who owns what³.

• TokenSafe holds the real tokens users bridged from Ethereum: USDT, USDC, WETH, WBTC and others. When someone bridges back, TokenSafe releases them.
• MinterPool mints and burns the wrapped tokens of the bridge on Ethereum. The best known is CIOTX, the IOTX token on Ethereum.
• Witnesses are independent operators. They watch both chains and sign each transfer. A transfer needs signatures from more than two thirds of them³.
• TransferValidator checks those signatures. If they are valid, it tells TokenSafe to release tokens or MinterPool to mint them. To do that, it is the owner of both TokenSafe and MinterPool.

So witnesses protect each transfer, but the Validator has the last word: TokenSafe and MinterPool do what their owner asks. And the Validator itself had an owner too: one ordinary address, 0x6dd3…148e, with no multisig and no timelock in front of it⁴⁵.

That was the weak point. Whoever controls the Validator's owner key does not need any witness.

The attack, step by step

All times are UTC, block times from Ethereum. We read every transaction below on-chain ourselves⁶.

01:07:35 — the Validator gets a new owner

The owner key 0x6dd3…148e called transferOwnership on the Validator (0xE7eB…59d5) and handed it to 0xE6A1…55d9, an address the attacker controlled. Transaction 0xe9e7…c9f0.

According to IoTeX, the attacker got the owner key through a compromised employee machine, most likely by social engineering, and had been inside for a long time before the attack¹.

On a bridge Validator a change of owner is rare and planned. This one was neither. The contract emitted OwnershipTransferred, and that one event is the whole attack in short: from this block on, the attacker could take everything the Validator controlled.

Two minutes later, at 01:09:23, another address sent the attacker 0.1 ETH for gas (0x561b…2fa6).

01:20:35 — TokenSafe and MinterPool change hands

The attacker called upgrade on the Validator (0xc9c5…51b8). Despite the name, this is not a code upgrade. The function is meant for moving the bridge to a new Validator. It passes ownership of every contract the Validator owns to the address it is given³.

The attacker gave it their own address. In this one transaction, TokenSafe (0xC2e0…0d7a) and MinterPool (0x964F…3B45) each emitted OwnershipTransferred, from the Validator to 0xE6A1…55d9⁶.

From here on, the attacker did not need the witnesses or the Validator. They could call TokenSafe and MinterPool directly as owner.

IoTeX's review says the attacker "upgraded the Validator" at 01:51¹. On-chain this step happened at 01:20:35, 13 minutes after the change of owner, and no new code was deployed.

01:25:47 to 02:02:47 — TokenSafe is emptied

The attacker called TokenSafe.mint twelve times. Again the name misleads: on TokenSafe, mint releases real tokens that it holds. Everything went to one address, 0x6487…442f⁶.

Two more calls, at 01:33:23 and 01:38:35, moved nothing. IoTeX puts the total at about $4.4M². The stolen tokens were then swapped to about 2,183 ETH, and most of it went through THORChain to Bitcoin²⁴.

02:39 to 02:44 — CCS is pulled out

The attacker minted 9,298,560 CCCS through MinterPool, in two calls at 02:39:11 and 02:43:23, and swapped them with withdrawTo for the same amount of the underlying CCS token at 02:41:47 (0xe6c1…7aa5) and 02:44:11 (0x3ef1…ceb7)⁶. According to Rekt, the CCS was never sold⁴.

04:05 to 07:43 — CIOTX out of nothing

Then the attacker used MinterPool for what it does best: minting CIOTX with no IOTX locked behind it. Ten calls, small at first, then large⁶:

On-chain these mints add up to about 821M CIOTX, as Rekt also counts⁴⁶. IoTeX's posts name 410M². We do not know why the numbers differ. Our count is the sum of the mint transactions above.

08:01 and after — the response

IoTeX detected the incident at 08:01 and posted the first public alert at 09:39. At 10:03 its validators halted the IoTeX chain. The chain came back on February 24¹. Over the next weeks IoTeX blacklisted 29 attacker wallets, froze about 45M IOTX, offered a 10% bounty, retired CIOTX on other chains, moved the bridge contracts to a multisig with hardware keys and circuit breakers, and promised users 100% compensation from its treasury¹⁸.

Almost all of the damage happened between the first possible alert at 01:10 and detection at 08:01.

What no rule would have changed

How to set up these rules in SmartAlert

1. Add the contracts that own other contracts. For a bridge like ioTube that is the Validator, TokenSafe and MinterPool. If the ABI has OwnershipTransferred, SmartAlert offers the ownership change rule on its own. Keep it checked on each.
2. Check the rule on history. You see every past change of owner, so a planned handover is no surprise, and an unplanned one stands out.
3. Watch withdrawals from the vault. Add each token the vault holds and create a transfer above an amount in $ rule with from = the vault. Pro and above.
4. Watch your own wrapped token for mints. Add the token and create a large transfer rule with a threshold above your normal bridge volume. Mints show up as transfers from the zero address.
5. Watch the total. A "Total address balance in $ below threshold" rule adds up every token of the vault in dollars. Set the floor a little under the normal total, and it fires on a large outflow of any token, native ETH included.
6. Choose where alerts go. Telegram is free. Send ownership alerts to a channel someone reads at 1 a.m.

The same works for proxy upgrades (Upgraded) and Safe owner changes. See all alert recipes.