Sui Bridge $392K: Claim Bot Paid the Cetus Attacker

TL;DR

On October 16, 2026, between 04:39 and 04:40 UTC, an automated "unclaimed funds" bot run by lostandfound.eth finalized eight old Sui Bridge withdrawals on Ethereum in three transactions. Every one of them was sent from the Cetus exploiter's Sui address to the exploiter's Ethereum address. The attacker received 86 ETH, 109,000 USDT and 0.9 WBTC, which the operator itself put at about $392K. The Sui Bridge contract paid the recipient named in a validly signed message, as designed, and the bot submitted every valid message it found without asking who the recipient was. The attacker had deposited those transfers on May 22, 2025, the day of the Cetus exploit, and never claimed them. Why is not on record. The Sui validator freeze that stopped most of the Cetus funds could not touch them, because claiming them needs nothing from the frozen Sui address. It was the second such delivery: one more of the attacker's stale withdrawals, 1 LBTC, was claimed for it in August 2025. Sixty-seven hours after the October claims, the USDT, the one asset here with an issuer blacklist, was still sitting unfrozen in the attacker's wallet.

What Happened on October 16?

The claim bot at 0x7f2ee458...6671 sent the first batch at 04:39:35 UTC in block 26,202,756, a Multicall3 aggregate3Value that bundled fifteen calls. Five of those calls were Sui Bridge claims. The other ten settled unrelated wallets' positions: nine on a WithdrawQueue contract that burns ezETH, one on an OptimismPortal2. Two more batches followed at 04:39:59 and 04:40:11. The bridge's own TokensClaimed events for those claims name the same sender and recipient on every line: Sui address 0xe28b50ce...ff06 to Ethereum address 0x89012a55...919b.

Both addresses are public. Rekt's write-up of the original incident lists them as the Cetus attacker's Sui and Ethereum addresses.

At 04:42 UTC, under three minutes after the last claim, the bot did what it does for every wallet it helps. It sent an on-chain message to the attacker listing the eight "unclaimed amounts", each one described as a Sui to Ethereum bridge transfer "that was approved but never claimed", and suggested an optional tip of 5% to 10%. By the bot's own arithmetic that was $19,598 to $39,196, requested from an address Rekt had published as the Cetus attacker's 17 months earlier.

The first person to notice was a stranger. At 05:08 UTC an address signing as tanuki42 messaged the bot on-chain that its claims had sent "~$390k of stale Sui Bridge withdrawals" to "an address publicly associated with the Cetus exploit." Thirty minutes later the operator replied on-chain: "you're right, our mistake." The reply says nothing had moved yet, asks for help routing the case to Tether and Cetus so the USDT can be frozen, and says the bot now screens every recipient against known exploit and sanctioned addresses.

What Did the Attacker Actually Receive?

Our reconstruction from the attacker's internal transactions and our decoding of the bridge's claim events:

Sui Bridge nonce	Asset	Amount	Ethereum batch
7031	USDT	93,000	1 (04:39:35)
7028	WBTC	0.9	1
7025, 7027, 7030	ETH	3 x 28	1
two transfers	USDT	2 x 8,000	2 (04:39:59)
one transfer	ETH	2	3 (04:40:11)

That totals 86 ETH, 109,000 USDT and 0.9 WBTC. The bridge holds ether as WETH in its BridgeVault and unwraps it on the way out, so the 86 ETH arrived as native ether.

On the dollar figure. The $392K comes from the operator's own message, which prices each line at claim time (28 ETH at "about $68,196", 93,000 USDT at "about $92,904"), and the PandaSecurity write-up repeats it. The token amounts are on-chain fact. The dollar total moves with ETH and BTC, so treat it as a claim-time estimate. The selector that flagged this story for us carried "93,000 USDT", which is the first batch only. The two 8,000 USDT claims in the second batch take it to 109,000.

Why Were Cetus Funds Still Claimable 17 Months Later?

Rewind to May 22, 2025. Cetus, the largest DEX on Sui, lost about $223 million to a misapplied overflow check in its inter_mate math library. Sui validators froze the addresses holding about $162 million, but roughly $60 million had already reached Ethereum.

The Sui Bridge was one of the exits. Its Sui to Ethereum path works in two halves. The user locks tokens on Sui. Bridge nodes sign the transfer, and the approval is recorded on Sui. Then, per Mysten's own architecture post, "users must submit the claiming transaction manually on Ethereum," carrying the bridge nodes' signatures in calldata.

The attacker used the full path once. At 11:12 UTC on May 22, 2025, 0x89012a55 claimed a 3,000 USDT transfer itself, and its TokensClaimed event records nonce 7034 from the same Sui sender. All eight nonces the bot settled in October fall between 7020 and 7031, lower than that one, so those deposits came first, earlier the same day. They were never claimed.

At 12:52:47 UTC the bridge committee paused the Ethereum contract through executeEmergencyOpWithSignatures. It unpaused at 22:13:35 UTC the same day. Why the attacker took one small transfer and then left nine larger ones on the table is not in the public record. It may have been rate limits, the pause, or simple distraction. What is on record is the result. Once the bridge reopened, those nine approved messages were valid claims on the vault, payable to the attacker, and executable by anyone.

The freeze stopped the attacker's Sui address from signing new transactions on Sui. It could not reach a message that had already left Sui with committee approval attached. A signed bridge withdrawal works like a bearer instrument with the payee already written on it: whoever presents it, the payee named on it gets paid.

Our query of the Sui Bridge's deposit events for the attacker's Sui address returns ten transfers to Ethereum, all made on May 22, 2025. The attacker claimed one. The bot claimed eight. The tenth, nonce 7029 for 1 LBTC, was claimed on August 31, 2025 and paid to 0x89012a55, per its TokensClaimed event. The submitter was 0xCa8d0B47...839B, the same address that sent the May 22 emergency pause. Its transaction history mixes committee-signed pause and limit updates with many claim submissions, which in our reading is the pattern of a relay account rather than a single user. Submitting any of those takes only the committee's signatures in calldata, not committee membership. Who controls it, and whether the August claim was deliberate or one more unscreened item in a queue, is not public. What is on-chain is that someone other than the attacker delivered Cetus proceeds out of the bridge more than a year before anyone flagged the October batch. With all ten settled, nothing from that Sui address is left to claim.

The Attack, Step by Step

The attacker did nothing in October. The table runs the whole 17-month path, because the release depended on choices made in May 2025.

#	When (UTC)	Actor	What happened
1	2025-05-22, morning	Cetus attacker	Drains Cetus pools, starts moving proceeds off Sui
2	2025-05-22, before 11:12	Cetus attacker	Locks tokens in Sui Bridge at nine nonces between 7020 and 7031, recipient `0x89012a55`
3	2025-05-22, 11:12	Cetus attacker	Claims nonce 7034 (3,000 USDT) on Ethereum, leaves the rest
4	2025-05-22, 12:52	Bridge committee	Emergency pause on the Ethereum contract
5	2025-05-22	Sui validators	Freeze about $162M on Sui. Already-approved bridge messages are untouched
6	2025-05-22, 22:13	Bridge committee	Unpause. The nine unclaimed messages are claimable again, by anyone
7	2025-08-31, 18:17	`0xCa8d0B47`	Claims nonce 7029 (1 LBTC) to the attacker's Ethereum address
8	2026-10-16, 04:39 to 04:40	lostandfound.eth bot	Submits the other eight inside three multicalls, no recipient check
9	2026-10-16, 04:42	Bot	On-chain note to the attacker suggesting a 5% to 10% tip
10	2026-10-16, 05:08	tanuki42	Flags the recipient as the Cetus exploiter
11	2026-10-16, 05:38	Bot operator	"our mistake", adds recipient screening, asks for a USDT freeze

What Is a Claim Bot, and Why Does One Touch Exploit Funds?

The bot's note to the attacker spells out the model: "I paid the gas. The funds are already in your wallet; there is nothing to approve." It signs off with a pointer to lostandfound.eth.limo, a one-page site that offers to recover stuck bridge withdrawals and other forgotten payouts, with the protocol paying the owner directly and an optional tip of 5% to 10% afterwards.

Most of the time that is a public service. The design problem is that its job is to find every claim the protocol will honor and submit it. The protocol will honor a claim for an exploiter as readily as for anyone else, so a bot that does not ask who the payee is will, sooner or later, pay one.

The MakerDAO keeper case earlier this month has the same shape. A stranger settled four Black Thursday auctions that a keeper had won in 2020 and never finalized, and took the 200 ETH. That one was a deliberate theft, and it began the same way as this one, with a claim left open for years that anyone could execute.

Did the Bridge Do Anything Wrong?

No. The code behaved as specified. Certora's assessment says it formally verified both the EVM and the Move side of the bridge, "with every transfer and governance decision approved by a committee of Sui validators." The October claims are what correct behavior looks like: a valid committee signature, an unspent nonce, a payout to the recipient in the message. Formal verification proves the contract follows its specification, and the specification says to pay this message.

Two decisions outside the contract shaped this outcome:

Who may submit a claim. Permissionless relaying is a feature, because users should not lose funds when a frontend dies. The cost is that the screening decision moves off-chain, into whichever relayer shows up. The PandaSecurity write-up makes exactly this point.
What incident response covers. The May 2025 response froze balances. Nothing public shows it inventoried the attacker's outstanding signed messages on the bridge, which a balance freeze does not cover, and the August 2025 LBTC claim went out without any public notice.

What Could Monitoring Have Changed?

No outside party could have stopped the claims. Each claim was a single transaction carrying a valid signature, and the bridge's pause is a committee-signed emergency operation, so nothing outside the committee could have stepped in during the 36 seconds the three batches took.

These events were all observable, on-chain, in the first block:

A TokensClaimed event on the Sui Bridge contract whose senderAddress is 0xe28b50ce...ff06, the Sui address frozen in one of the most public incidents of 2025.
93,000 USDT, 0.9 WBTC and 84 ETH leaving BridgeVault for 0x89012a55 in one transaction, followed by two more batches within 36 seconds.
Eight nonces between 7020 and 7031 being settled 512 days after the deposits they redeem.

The first human to flag it was a stranger, 29 minutes later. The operator's acknowledgement came at the one-hour mark. At block 26,222,825 (23:45 UTC on October 18), Tether's isBlackListed still returned false for the address in our own call against the USDT contract, and the attacker's token balances still showed all 109,000 USDT and 0.9 WBTC. The wallet has sent nothing since the claims. Its last outgoing transactions in its transaction history are three 100 ETH deposits into the Tornado Cash router in June 2026, and it still holds about 2,330 ETH. It has not answered the tip request either. We found no public response from Tether or Cetus to the operator's freeze request as of October 18.

So the slow step is the issuer response. An alert only matters if it starts a freeze request, and that request needs someone with standing to file it, such as Cetus, and a case packet the issuer will act on. The 86 ETH arrived as native ether, which no request can freeze at all.

Why This Matters Beyond Sui

Every bridge with a manual claim step carries a backlog of approved, unexecuted withdrawals. Most of them belong to users who forgot. Some belong to people the ecosystem has spent a year trying to stop. The difference is invisible to the contract and to any relayer that does not check.

The precedent cuts both ways. Freezes are now a normal part of large-incident response on chains that can do them, and Sui's was among the largest. But a freeze is a list of addresses, and a bridge holds promises that were signed before the list existed. If the response team does not write those promises down, anyone holding the signatures can execute them.

We have a stake in this. Fund tracing that stops at the balances leaves exactly this kind of live claim behind. In an incident-response engagement we trace pending bridge withdrawals alongside balances, hand the nonces and recipient addresses to the bridge operator and to the relayers we can reach, and pre-draft the issuer freeze request for every freezable asset in those withdrawals, so a claim never waits on paperwork.

Operator Takeaways

Inventory signed-but-unexecuted messages during incident response. Pull every outstanding withdrawal from the attacker's addresses on every bridge, list the nonces, share them with the bridge operator and known relayers, and pre-draft the issuer freeze request for each freezable asset. Eight of them waited 17 months here.
Screen recipients in every keeper, relayer and rescue bot. Check sender and recipient against public exploit and sanctions lists before submitting. The operator added this after the fact, in one line of its reply.
Give bridges a way to refuse a known-bad claim. A committee-signed blocklist on claim recipients, or the ability to cancel a specific nonce, is far narrower than pausing the whole bridge, which is the control the committee reached for in May 2025.
Alert on claims that touch flagged addresses. A rule on the bridge's own TokensClaimed event, keyed on sender and recipient, gives whoever handles the freeze request the transaction hash in the same block.
Prepare the issuer contact before you need it. USDT can be frozen until it moves. Have the issuer contact and the case packet ready before you need them.

Frequently Asked Questions

Was the Sui Bridge hacked?

No. The bridge contract executed eight validly signed withdrawals exactly as designed. The failure was a third-party claim bot that submitted them without checking that the recipient was the Cetus attacker, plus a 2025 incident response that, as far as the public record shows, froze balances without dealing with the attacker's pending bridge messages.

How much did the Cetus attacker receive?

86 ETH, 109,000 USDT and 0.9 WBTC, about $392K at the operator's claim-time prices. The figure that first circulated, 93,000 USDT, covers the first batch only.

Can the funds still be frozen?

Yes, the USDT can, because Tether keeps a blacklist and the 109,000 USDT had not moved as of 23:45 UTC on October 18. The ETH arrived as native ether, which no issuer can freeze.

Are any of the attacker's Sui Bridge withdrawals still unclaimed?

No. The attacker's Sui address made ten Sui Bridge transfers to Ethereum on May 22, 2025. The attacker claimed one that day, nonce 7029 (1 LBTC) was claimed for it in August 2025, and the lostandfound.eth bot claimed the last eight in October 2026.

Why didn't the Sui validator freeze cover this?

The freeze stopped the attacker's Sui address from acting on Sui. These withdrawals had already been deposited into the bridge on Sui, and claiming them on Ethereum needs no action from the Sui address at all. Anyone holding the committee's signatures can submit the claim.

Sui Bridge $392K: A Claim Bot Paid the Cetus Attacker From 17-Month-Old Withdrawals