On May 22, 2025, a major exploit targeted Cetus Protocol on the Sui blockchain, resulting in an estimated $223 million in damages. This incident drew immediate attention across the ecosystem, especially from technical observers due to the unusual mechanics involved. What follows is a comprehensive analysis of the attack from flash swaps and tick manipulations to a silent vulnerability in overflow detection logic.

https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x

The Setup

The attacker initiated the exploit by using flash_swap to borrow a large amount of SUI tokens in exchange for haSUI. Unlike traditional flashloans, flash_swap in Cetus allows a user to receive token1 (SUI in this case) upfront and then repay token0 (haSUI) within the same transaction. This mechanism is central to the attacker’s setup.

In this particular instance, the attacker successfully acquired 5.76 million SUI and was obligated to repay 10.02 million haSUI. But during this swap, the price of haSUI in the liquidity pool was manipulated drastically. The pool’s price was dropped from a tick representing a ratio of 1.056 to a tick so low that the price reached merely 0.0000009977—an enormous devaluation to 0.00009% of its original price.

The price range corresponding to the tick range is:

Strategic Liquidity Injection

Following this price crash, the attacker used open_position to create a narrow-range liquidity position, choosing a highly specific tick range (tickLower: 300000, tickUpper: 300200). Within this manipulated environment, they injected an astronomical amount of liquidity: more than 10^34 units, all within the ultra-compressed price range created by the tick collapse.

This was made possible by a seemingly innocuous function: get_amount_by_liquidity. Under normal conditions, this function calculates how much of token A and token B is needed to match a certain liquidity level. It does this using helper functions like get_delta_a, which relies on get_sqrt_price_at_tick.

However, due to the manipulated current tick being -138185, and the chosen tick range being well outside that (starting at 300000), the logic path inside get_amount_by_liquidity ensured that calculations would pass through a vulnerable section of code where a left shift operation (checked_shlw) was involved.

Overflow and Truncation: The Core Vulnerability

Here’s where the exploit gets truly technical. The function checked_shlw is supposed to handle left-shifting a 256-bit number by 64 bits. In Solidity-like environments, such an operation is risky since it may overflow. This particular implementation attempted to detect overflows by checking whether the input exceeded a predefined threshold: 0xffffffffffffffff << 192.

The actual threshold for detecting a safe shift by 64 bits should be 2^(256 - 64) - 1. However, (0xffffffffffffffff << 192) is larger than 2^192. This means that a carefully chosen input could bypass the overflow check by being below the threshold used in the code, but still large enough to cause an overflow during execution.

he attacker supplied such an input, where the multiplication of liquidity and price difference overflowed silently, returning a much smaller value than intended—in fact, nearly zero.

As a result, the protocol calculated that the attacker only needed to pay a trivial amount of token A—essentially one unit—to add massive liquidity to the pool. This miscalculation enabled the attacker to inject massive liquidity at no real cost.

Subsequently, the attacker removed the added liquidity through remove_liquidity and completed the attack by paying the unpaid tokens of flash_swap through repay_flash_swap. The attacker made a profit of 5,765,124 SUI and 10,024,321 haSUI. Finally, the Cetus team fixed the vulnerability through two PRs:

https://github.com/CetusProtocol/integer-mate/pull/6/files

Cetus quickly released a patch on their integer-mate repository, with the first pull request attempting to refine the overflow detection. However, that initial fix was inadequate. It used a mask of 1 << 192, which still allowed edge-case values to slip through.

A second pull request followed with a stricter comparison, checking that the input is greater than or equal to 2^192, ensuring proper bounds for safe left-shifting. Only with this correction was the vulnerability effectively mitigated.

https://github.com/CetusProtocol/integer-mate/pull/7/files