Back to Blog

[Not All Tokens Are Good] The Quick Analysis of the Paraluni Attack

Code Auditing
March 13, 2022

The Paraluni project was attacked on the morning of March 13 (UTC +8 time). The attacker leveraged two vulnerabilities to attack the protocol. The first vulnerability is the lack of the verification of passed tokens, and the second is the traditional reentrancy. The attacker launched a couple of attack transactions. In the following, we will use one of them 0xf2bba649019ce40a67f0fb74e5e800257d359d9094b6ba6faea14ffa4d3446b1 to illustrate the whole attack process.

Step I: add liquidity to paraRouter

The attacker invoked addLiquidity to the BTCB-WBNB pool (index = 9) and the pool will mint the lp token to UBT (a token created by the attacker.) After this operation, the UBT token holds the pool's lp token. Note that, the BTCB and WBNB is borrowed from the flash loan.

Step II: invoke depositByAddLiquidity of MasterChef The attacker invoked depositByAddLiquidity by providing the _pid as 9 and using the UGT and UBT token as the parameters. However, the function does not check whether the pool’s reserve tokens are equal to the passed tokens (UGT and UBT).

Then the function invokes the depositByAddLiquidityInternal which then invokes addLiquidity of paraRouter. This function will invoke the UGT and UBT token’s transferFrom function. However, these two tokens are controlled by the attacker. In the transferFrom function of UBT, the attacker invoked deposit function of the MasterChef contract to deposit the LP token obtained in the first step into MasterChef contract.

Unfortunately, due to the balance change in the deposit function, the newBalance after addLiquidity is much larger than the oldBalance. In this way, the attacker got double credits in MasterChef contract.

Step III: get profit

The attacker finally invoked UBT.withdrawAsset and MasterChef.withdraw to redeem the lptoken to get BTCB and WBNB. Since the number of liquidity is more than the attacker should have, the attacker will get profits.

Lessons

Besides the reentrancy problem, the passed tokens have not been verified is one of the root causes. We have seen other cases with similar issue, as in the Visor case and the Coin98 case.

About BlockSec

BlockSec is a pioneering blockchain security company established in 2021 by a group of globally distinguished security experts. The company is committed to enhancing security and usability for the emerging Web3 world in order to facilitate its mass adoption. To this end, BlockSec provides smart contract and EVM chain security auditing services, the Phalcon platform for security development and blocking threats proactively, the MetaSleuth platform for fund tracking and investigation, and MetaSuites extension for web3 builders surfing efficiently in the crypto world.

To date, the company has served over 300 esteemed clients such as MetaMask, Uniswap Foundation, Compound, Forta, and PancakeSwap, and received tens of millions of US dollars in two rounds of financing from preeminent investors, including Matrix Partners, Vitalbridge Capital, and Fenbushi Capital.

Official website: https://blocksec.com/

Official Twitter account: https://twitter.com/BlockSecTeam

Sign up for the latest updates
~$9.4M Lost: Injective, Aquifer Exploits | BlockSec Weekly
Security Insights

~$9.4M Lost: Injective, Aquifer Exploits | BlockSec Weekly

During the past week (2026/08/31 - 2026/09/06), four security incidents caused approximately $9.4M in losses across Injective, Solana, Ethereum, and Flow EVM. The largest was the Injective exploit, where an insurance fund identifier collided with a binary options market identifier and the settlement path never compared their denominations, draining about $4.8M; Aquifer on Solana lost about $2.47M because its swap path invoked an unvalidated caller-supplied Token Program, and Notional Finance V1 on Ethereum lost about $1.73M to an unchecked `uint128` cast that valued a debt at zero. Ankr FLOW on Flow EVM closed out the week with about $410K drained through a staking entry point that skipped its pause guard and minted against a stale ratio.

From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing
Security Services

From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing

Exchanges, payment firms, custodians, and wallet providers now lose the most money beyond the smart contract—in signing, custody, keys, people, and supply chains. Code-level audit and transaction-level monitoring each leave a gap, and traditional penetration tests may miss crypto's signing and fund semantics. This article opens our blockchain penetration testing series with the two legs of the case for institutions in scope: where the risk actually comes from, and how NYDFS, DORA, VARA, SFC, and MAS treat adversarial testing across five jurisdictions.

What Is Blockchain Penetration Testing? Definitions and Boundaries
Security Services

What Is Blockchain Penetration Testing? Definitions and Boundaries

No widely accepted definition of blockchain penetration testing exists, and many proposed ones tangle it with audit, scanning, and bug bounty. This article sets out a working definition—an adversarial, hands-on assessment of a running system, under agreed scope and rules of engagement, that validates exploitable paths and control chains—and what web3 adds: a money-handling threat model whose defining composition gap is the off-chain-to-on-chain handoff. It then maps the five testable capabilities of that chain and routes nearby objectives to code audit, wallet security audit, web3 security testing, scanning, and bug bounty.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit