JUDAO HACK ANALYSIC
JUDAO is a decentralized finance (DeFi) project deployed on the BNB Smart Chain (BSC), offering token-based financial services through its on-chain liquidity and trading ecosystem. On April 28, 2026, JUDAO on the BSC chain was exploited in an attack that resulted in an estimated loss of approximately $228,000 at the time of the incident. The exploit appears to have involved a flash loan attack that manipulated the liquidity pair reserves, allowing the attacker to extract profit through distorted pricing.
Overview
Attacker: 0x5384B34C74024d6563B323351a4bBFA18432161B
Attacker’s contract 1: 0x3B9bc53Af5012b12B6886a665Bb22382211aE432
Attacker’s contract 2: 0x3B9bc53Af5012b12B6886a665Bb22382211aE432
JUDAO token: 0xf55DFF7898930a2D28cDbC39D615b1624ac86888
Vulnerable contract: 0x5D7b61e91cB59E90f7fAE8d0FE2e73976161592F
Analysis
At the beginning of the attack, the attacker deployed two nested contracts and granted unlimited token approvals to both the PancakeSwap Router and the Moolad Proxy. The attacker then obtained a flash loan of approximately $2.3 million in USDT, swapped the funds for roughly 5.5 million JUDAO tokens, and immediately sold the acquired JUDAO tokens.
Everything appeared normal at first, until we noticed an unusual inconsistency:
At step 29, approximately $2.3 million USDT was swapped for around 5.5 million JUDAO tokens.
At step 237, approximately 5.3 million JUDAO tokens were swapped back for nearly $2.6 million USDT.
This immediately revealed a critical anomaly: the attacker was able to swap fewer JUDAO tokens for a larger amount of USDT, indicating that the liquidity pair reserves or pricing mechanism had been manipulated.
A closer inspection of the code execution between these steps reveals that the reserve balances of the Cake-LP pool were updated twice prior to the malicious second swap. Notably, both updates retained the same _reserve0 value while _reserve1 differed between the two states.
From our perspective, the first reserve update appears to be correct, while the second seems incorrect. This is because the first update reflects a larger _reserve1 value, which should represent the actual post-swap reserve state. To understand why two different reserve updates occurred, we need to examine the JUDAO token source code more closely.
In the customized _update function of the JUDAO token, there is a code path that updates the pool reserves twice. First, during the sync() call, JUDAO burns deadAmount from the pool and transfers the remaining portion to itself (events 149 and 154 in our trace), then invokes basePair.sync().
Later, execution returns to the _update() function, where isBurnPair may be set to true by getSellFee() if the price increase does not exceed 5% compared to the previous day. In that case, JUDAO burns half of the amount again, transfers the other half to itself, and triggers another basePair.sync() call, causing the pool reserves to be updated a second time.
This overlap causes _reserve1 (the reserve corresponding to the JUDAO token itself) to become lower than its correct value. As a result, the price of JUDAO in the pool is artificially inflated, allowing the attacker to profit by selling JUDAO at an elevated price. This constitutes the root cause of the incident.
At the end of the attack, the attacker used a portion of the drained USDT to purchase 36 BNB, then transferred all available assets to his own address.
Summary
The root cause of this incident was a flaw in the token’s customized liquidity and balance update logic. Due to incorrect reserve accounting, the liquidity pool temporarily calculated an artificially high token price, which the attacker exploited to sell tokens at inflated values and drain a significant amount of assets from the pool. This incident demonstrates how small mistakes in custom smart contract logic - especially around liquidity pool interactions, token burns, or balance synchronization - can result in severe financial damage. Projects introducing non-standard token mechanics should always undergo comprehensive smart contract audits and security reviews before deployment to identify these edge cases early.