On July 19, 2026, Allbridge Core lost about $1.65M when an attacker manipulated the internal exchange-rate math of its stablecoin pool inside a single transaction. The pool derived its rate from balances that one transaction could move, so the attacker took a roughly $1.12M USDC flash loan from Kamino, traded USDC and USDT back and forth through the pool to distort the rate, withdrew liquidity at the skewed rate, and repaid the loan in the same transaction, keeping about $1.65M and bridging it to Ethereum. No key was stolen and no bridge message was forged. The swap accounting itself failed to conserve pool value.

The detail that matters most about this one isn't the mechanism. It's that Allbridge had already been hit by this exact class before, had designed the fix, and never applied it to the deployment that got drained.

Background

A stableswap pool prices trades from the balances it holds. If those balances can be moved within the same transaction that reads them, the price the pool quotes is a price the trader can choose. The defense against this is well understood: make same-transaction manipulation structurally impossible, so that no single atomic sequence can both distort the rate and profit from it.

Allbridge knew this defense specifically, because it had already paid to learn it. In April 2023, the same class of flaw cost the protocol about $573K. Their own post-mortem committed to a concrete structural fix: run one liquidity pool per chain, so the multi-stablecoin configuration that makes flash-loan rate manipulation possible would no longer exist. The remediation was correct. It closed the exact hole that was later reopened.

Root Cause

The pool's exchange rate was derived from balances that a single transaction could move, with no same-transaction manipulation resistance. Trading USDC and USDT repeatedly through the pool distorted its internal rate math, and liquidity withdrawn at the distorted rate returned more than it should have.

In the virtual-pool framing, a USDT to vUSD to USDT path ran the send-pool and receive-pool at the same address by input, so only the receive-pool state finalized. Each swap skewed the reserves instead of rebalancing them, and repeating the loop let the attacker extract net value the pool's accounting should never have released.

The deeper root cause sits one level up from the code. The Solana deployment was still running USDC and USDT side by side, the exact multi-stablecoin configuration the 2023 fix was designed to eliminate. The one-pool-per-chain remediation that made this attack structurally impossible on the chains it reached had simply never been applied here. The vulnerability class was known, the fix was designed and committed to, and it wasn't applied uniformly across deployments.

Attack Flow

1. The attacker took a flash loan of about 1.12M USDC from Kamino, to be repaid in the same transaction.
2. They traded USDC and USDT back and forth through Allbridge Core's stablecoin pool, running a loop of swaps that distorted the pool's internal exchange-rate math.
3. Because the rate derived from balances the same transaction was moving, each swap skewed the pool's reserves rather than rebalancing them.
4. They withdrew liquidity at the manipulated rate, extracting more value than the pool should have released.
5. They repaid the flash loan in the same transaction and kept about $1.65M, which was bridged to Ethereum.

Impact

The protocol released roughly $1.65M more than its pool accounting should have allowed, all inside one atomic transaction. Because the flash loan opened and closed within that transaction, the attacker needed no starting capital beyond gas, and because the manipulation and the withdrawal were a single sequence, there was no window in which the pool looked wrong to an outside observer before the value was gone.

The Problem With Audit-Only Security

This exploit is a precise illustration of why an audit, on its own, is not a security model, and it's a cleaner illustration than most, because the audit here wasn't wrong. The fix was known and correct.

An audit examines a scope. It tells you what a reviewer found inside the code they were given, in the time they had. What it does not do, and was never designed to do, is guarantee that a fix proven necessary on one deployment has been carried across every other deployment of the same protocol. Allbridge's chains that received the one-pool-per-chain fix were sound against this attack. The Solana deployment, running the old multi-stablecoin configuration, was not. Each deployment could pass its own review and the protocol as a whole could still carry the 2023 vulnerability, because no single scoped review is responsible for the consistency between deployments.

That's the shape of the gap. It isn't that anyone skipped a step or shipped carelessly. It's that security batched to individual scopes leaves the space between those scopes untested, and here the space between two deployments of the same pool math is exactly where $1.65M left. A review of each part in isolation will keep missing the property that only exists across the parts: that the fix reached all of them.

What a Retrospective Scan Found

The property that broke is stateable and testable: a pool's exchange rate must not be movable within the same transaction that reads it, and a swap round-trip must conserve total pool value. To be clear about what follows, Olympix did not scan this code before the exploit. After the incident, we ran BugPOCer retrospectively to test one question, whether the analysis lands on the function that failed, and the honest result is worth stating with its limits intact.

First, the scope limit, because it's the same cross-deployment story that caused the loss. Allbridge doesn't publish the exploited Solana program, so the scan ran against the public EVM implementation of the same pool math, not the bytecode that was drained. The findings describe code that can be read, not the exact code that lost the funds. That's a real caveat, and it's also the point: the same math lived in multiple places, and analyzing the readable copy surfaces the class the Solana deployment still carried.

On that readable copy, two High findings landed directly on the exploited surface. The first flagged that the pool's deposit path omits the balance-ratio guard that its swap functions carry, so a caller can breach the minimum balance ratio that swaps are explicitly forbidden from breaching, and that this can distort the balance-derived price. That is the exact guard the real attack defeated. The second flagged a repeatable deposit-and-withdraw cycle that drains a reserve unit per iteration from the existing liquidity providers through rounding. Structurally it's the same failure as the incident, distort the curve state and extract at the resulting rate, reached through rounding rather than flash-loaned swap volume.

Now the calibration, which matters more than the hits. The scan returned well over a hundred findings, nineteen of them High, and generated no automatic proof-of-concept. The two findings that matter were in that set, but unranked among the other Highs, and everything landed in a bucket that means a human still has to review it. So the honest claim is not that Olympix caught this, or would have caught it automatically. It's narrower: had this scan run before deployment, it would have put a reviewer on the exact function that failed, with the exact failure pattern described. That's a meaningful difference from a blind review of the whole contract, and it's a smaller claim than "we'd have stopped it on our own." Both of those are true at once, and a post-mortem that only told you the first half wouldn't be worth trusting on the second.

The takeaway isn't that a tool replaces the reviewer. It's that the reviewer's attention is the scarce resource, and pointing it at the precise function carrying a known-class defect, on every deployment of the same math, is what a scoped one-time audit doesn't do on its own.

Takeaway

Allbridge had already been charged for this lesson once, wrote down the right fix, and shipped it to some deployments but not the one that got drained. The vulnerability wasn't unknown and the remediation wasn't wrong, so this loss isn't a story about a missed bug. It's a story about a proven fix that didn't reach uniformly, and about the space between deployments that no single scoped review is asked to check. A pool rate you can move in one transaction is a testable property, and had the same pool math been analyzed before deployment, the scan would have pointed a reviewer straight at the deposit path that dropped the balance-ratio guard, on every deployment running it. That's the difference between fixing a class once and actually being rid of it: not trusting that a known fix reached everywhere, but testing each deployment against the rule and flagging the one that still fails it. You can see Olympix run that analysis against your own contracts, and see exactly which function it puts in front of a reviewer, in a technical walkthrough.

On-Chain References

Protocol:          Allbridge Core
Chain:             Solana (Rust). Exploited program not published; public EVM and Soroban
                  implementations share the same pool math.
Date:              July 19, 2026, 17:51 UTC
Loss:              ~$1.65M, bridged to Ethereum (0x651591b68A9c9650FB23F642162353306281ffDe)
Exploit tx:        3LNLaGi36bqoSBFBqcQ3ZvDbnGCxrxu4rqahZrnfHZjKSYxfR1mqiCXtBXjjeBmoRQDeSiKxZ7c1nFb8pBgTY39Q
Flash loan:        1,121,956.99 USDC from Kamino (FlashBorrow -> 7x Allbridge Core swap -> FlashRepay)
Prior incident:    ~$573K, same class, April 2023. Fix committed (one pool per chain) but never
                  applied to this deployment.
Flaw:              pool exchange rate derived from balances a single transaction can move, no
                  same-transaction manipulation resistance; repeated swaps skew reserves instead
                  of rebalancing, and withdrawal at the skewed rate releases net value


The class that drained Allbridge Core was known, and the fix existed on other deployments. Run before deployment, that same analysis surfaces the failed function for a reviewer, on every deployment carrying it, before the next one gets drained. See Olympix run it against your own contracts. Book a technical walkthrough.