Allbridge CCTP's $190K Loss and How Olympix Would Have Prevented It

Loss

Exploit date

August 19, 2026

Date: August 19, 2026

Chain: Base

Loss: 190,155.98 USDC, about $190K

Class: cross-chain message accepted as a deposit without checking where it came from or that funds arrived

At 01:47:17 UTC on August 19, 2026, the USDC balance of Allbridge's Router on Base fell from 191,155.98 to exactly 1,000 in a single transaction. Six seconds earlier, a genuine user transfer had landed 191,112.34 USDC in that same Router on its way through Allbridge's Circle CCTP route, and that deposit is the money that left.

This incident is separate from the July 19 exploit of Allbridge Core's Solana pool, which Olympix covered in its own post. This one hit a different piece of the system: the contracts Allbridge deployed on Base in April 2026 to move USDC through Circle's Cross-Chain Transfer Protocol.

How the CCTP Route Was Supposed to Work

Circle's Cross-Chain Transfer Protocol moves USDC between chains by burning it on one side and minting it on the other. Circle's attestation service signs a message describing the burn, and a contract called MessageTransmitter on the destination chain checks that signature before anything is minted.

Allbridge built on top of this. Its CCTPTokenMessenger contract on Base receives CCTP messages and records that a user has a deposit waiting, and its Router pays users out against those records. Both contracts are verified on BaseScan and were deployed on April 28, 2026 from the same Allbridge deployer address.

The arrangement has a subtlety that matters here. A Circle attestation proves that Circle saw and signed a message. It doesn't prove that the message was the burn-and-mint Allbridge expects, sent by Allbridge's own contract on the other chain, with USDC actually arriving at Allbridge's Router. Those are separate facts, and an integration has to check them itself.

The Missing Checks

According to SlowMist's analysis, Circle's contracts did their job: the message in this attack carried a valid attestation. The flaw sat in Allbridge's CCTPTokenMessenger, which treated any validly attested message as proof of a real deposit.

SlowMist names three checks the contract didn't make. It didn't confirm that the message came from Allbridge's trusted contract on the source chain. It didn't confirm that the message was addressed to Circle's own token messenger, the contract that actually mints USDC. And it didn't confirm that the Router's USDC balance had gone up before it recorded a deposit someone could redeem.

With all three missing, the contract could be made to record a deposit that no USDC stood behind, and the Router would pay that record out of whatever genuine user funds it happened to be holding. SlowMist titled its write-up "a cross-chain attack spanning one month," because the preparation began weeks before the money moved.

The lesson for builders is that a valid signature from a trusted party answers only the question that party was asked. Circle vouches that a message is authentic. Whether that message represents money your contract actually received is a question only your contract can answer, and it should answer it by looking at its own balance.

What Happened on August 19

The attacker's address, 0x2419...360e, used a contract it had deployed on July 25, 2026. In block 50,157,345 that contract drained the Router to its last 1,000 USDC. SlowMist notes the timing was chosen for a moment when genuine deposits had temporarily raised the Router's balance, and the 191,112.34 USDC transfer that had just arrived is the money that went.

After the transaction settled, the attacker held 189,751.55 USDC. At 06:28 UTC the funds moved from the attack contract to the attacker's wallet, and between 06:34 and 06:37 UTC they went into the LI.FI cross-chain router in three transfers of 1,000, 88,000 and 100,751 USDC. Less than one USDC remains in the wallet.

Response

SlowMist published its root-cause analysis on August 22. As of October 20, 2026, Allbridge's X account hasn't posted a statement about this incident, and no recovery or reimbursement for the Base CCTP route has been announced. The compensation Allbridge distributed in September relates to the July 19 Allbridge Core incident.

How Olympix Would Have Caught the Unbacked Deposit

Olympix reads a contract the way an attacker would: as states, transitions and entry points. It takes in the context around the code, here the fact that CCTPTokenMessenger sits downstream of Circle's MessageTransmitter and upstream of a Router holding user funds, to infer the invariants the system depends on. Then it maps the paths through those entry points and uses signals in the code to narrow from all paths to the feasible ones, and from those to the ones that touch an invariant.

The signal Olympix's static analysis surfaces in a contract like this is a credit written from external message data with no check on who sent the message and no check against the contract's own token balance. Recording a balance that can later be redeemed, based only on fields inside an incoming message, is the pattern that marks this entry point as worth attacking.

The invariant is one sentence: the total of redeemable deposit records the Router honors should never exceed the USDC that actually arrived to back them. BugPoCer infers that rule from how deposits are recorded and how the Router pays out, then runs Counterexample-Guided Invariant Refutation, working from the system outward until it finds a path that breaks it.

The counterexample it returns is a sequence of state changes in which a deposit record is created while the Router's USDC balance stays flat, followed by a payout against that record from funds that belong to someone else. The minimal condition is simply that the message passes Circle's signature check. BugPoCer packages the sequence with a generated Forge test that replays it, so the team would see the unbacked payout at the merge that introduced receiving the CCTP message, before the contracts went live in April. Because Olympix runs at every merge and before every release, the same invariant would be checked again whenever the route changed.

Trust the Balance, Not Just the Signature

Bridges and cross-chain routes inherit trust from the messaging layer they sit on, and that trust is narrower than it looks. Circle's attestation covers authenticity, and everything after that, including who sent the message, where it was meant to go and whether real tokens arrived, belongs to the integrating contract. The cheapest check of all, comparing the balance before and after, would have stopped this one. To see how Olympix maps the paths between your message handlers and the funds they release, book a technical walkthrough.