Allbridge Core Loses $1.65M to an Account-Aliasing Flaw

Allbridge lost $1.65 million from its Core pools on Sunday after an attacker passed a single account address into two different roles of the same swap instruction. The instruction accepted the same Pool account in both the sending and the receiving position and never checked that the two were distinct, according to a technical writeup by the security firm BlockSec. The token transfers settled first, and the accounting update written for one role then silently overwrote the update written for the other, leaving the pool's recorded state at odds with the balance actually sitting in its vault. No recovery has been reported.

What a Core Pool Holds: Deposits on One Chain, Payouts on Another

A cross-chain bridge does not carry a token from one blockchain to another, because separate chains cannot read each other's state. What it does instead is hold inventory on both sides. A pool contract on each chain keeps a vault of tokens and a set of internal numbers describing that vault: how much liquidity providers have supplied, how much has been paid out, and what the balance should be after the most recent transfer. A user deposits into the pool on the chain they are leaving, and the protocol releases the matching amount from the pool on the chain they are arriving at.

Everything therefore rests on two records agreeing — the tokens physically held in the vault, and the protocol's own ledger of what those tokens represent. When the ledger and the vault drift apart, the gap is withdrawable by whoever notices it first, and that is what happened here.

Account Aliasing: One Address Presented as Two

Account aliasing is what occurs when a program is handed one address in a place where it expects two different ones and treats it as something it is not. Allbridge's swap instruction takes a pool to draw from and a pool to pay into, and the code assumed those would be separate accounts because in ordinary use they always are. Passing the same Pool account into both slots made a single account play both parts at once. Each role wrote its own accounting update, and because both updates targeted the same account the second overwrote the first, while the token movements had already gone through. The missing safeguard is a single comparison — that the two accounts are not the same address — and its absence is the entire bug.

The failure belongs to a family of bridge incidents in which a contract acted on input it never verified, trusting the shape of a request rather than checking it. Nothing was forged in a cryptographic sense and no key was stolen. The attacker supplied an argument the interface permitted and the logic did not anticipate, then repeated it until the vault no longer matched the books.

July's Ledger: A Small Sum Next to the Month's Larger Failures

At $1.65 million the drain is modest measured against the month's other DeFi losses. Bonzo Lend, a lending market on Hedera, lost $9.05 million on 11 July when a verification flaw in a third-party oracle contract let an attacker post manipulated prices and borrow against 250 low-value tokens. What links the two incidents is not scale but type. Neither involved broken cryptography or a stolen key. In both cases a contract accepted an input it should have rejected, and the money followed the mistake out.

What Is Unresolved: No Funds Back and a Single Public Account

As of Sunday the only published technical account of the mechanism came from BlockSec, and none of the $1.65 million had been returned. The check that was missing costs a line of code, which is the uncomfortable part: a comparison that trivial is easy to leave out of an instruction that no legitimate caller would ever misuse, and it will not surface in testing that only exercises the intended path. The question the incident leaves open for other protocols is how many instructions elsewhere take two accounts of the same type and never confirm they are different. That is an audit exercise rather than a fix, and it applies well beyond Allbridge.