Orion Protocol Swap Reentrancy

On February 2, 2023, the decentralised trading protocol Orion Protocol was exploited for approximately $3 million — $2.84M on Ethereum and $191K on BSC. The doSwapThroughOrionPool function accepted a user-supplied swap path without validating the tokens and without reentrancy protection, letting the attacker insert a fake token whose transfer callback re-entered the deposit logic.

What happened

Orion's doSwapThroughOrionPool let users execute swaps through a caller-supplied path of token addresses. Two omissions combined fatally:

1. No token validation — the function accepted any token addresses in the path, including attacker-deployed contracts.
2. No reentrancy guard — the swap could be re-entered while its accounting was incomplete.

The attack:

1. Deployed a fake token ATK via a self-destructing contract, with a malicious transfer callback.
2. Took a flash swap of ~$2.84M USDT from a Uniswap V2 pair.
3. Called doSwapThroughOrionPool with a path including the fake ATK token.
4. When Orion's swap logic invoked ATK's transfer, the callback re-entered Orion's deposit function before the original swap's accounting settled — crediting the attacker's internal balance without real funds backing it.
5. Withdrew the inflated balance as real assets, repaid the flash swap, and laundered ~1,100 ETH through Tornado Cash.

Aftermath

• Orion Protocol paused the affected functions and reimbursed affected users from protocol reserves; the team stated all user funds would be made whole.
• The team attributed the issue partly to a third-party library dependency in the swap path, though the missing reentrancy guard was Orion's own.
• The protocol later rebranded to Lumia.

Why it matters

Orion Protocol is one more entry in the "unvalidated swap path + missing reentrancy guard" lineage that runs through BurgerSwap (2021), Transit Swap (2022), and Exactly Protocol (2023). The recurring shape:

• A routing/swap function accepts caller-supplied token addresses.
• The function makes external calls to those tokens (transfers).
• Those external calls can re-enter the protocol because the function lacks a reentrancy guard.
• An attacker supplies a malicious token whose transfer callback exploits the reentrancy.

The defensive answer is two well-documented primitives applied together: validate every token/contract address against an allowlist AND apply a reentrancy guard to every state-mutating path that makes external calls. Either alone is insufficient; Orion had neither on the exploited path.

The frequency with which this exact compound bug recurs — across years, chains, and teams — is one of the catalogue's clearest demonstrations that DeFi security knowledge does not automatically propagate. Every new routing/aggregation contract is a fresh opportunity to omit one or both primitives, and the omission keeps being made because routing code is complex, ships fast, and is often less rigorously audited than core pool logic.