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.

Incident Overview

Date: Apr 05, 2026

Platform: Linea

Attacker Address: 0x8d6778d7fae00ad2e0bc12194cf03b756fed9db3

Vulnerable Contract: 0xb68396dd4230253d27589e2004ac37389836ae17 (PerpPair on Linea)

Attack Transaction: 0xcb0744a0d453e5556f162608fae8275dabd14292bffbfcd8394af4610c606447

Exploit Mechanics

First, the attacker used a flash loan from AAVE as initial capital and deployed multiple helper contracts acting as LPs and traders.

Next, the attacker provided one-sided liquidity as an LP (only vUSD, zero asset). At this moment the contract snapshots the inverse of the current liquidityM matrix into the attacker’s position:

// perpLiquidity.sol line 147
liquidityPos.inverseSnapshotM = MatrixMath.inverseTwoByTwo(liquidityM, decimals.liquidityMDecimals);

Following that, the helper trader executed a trade. During trade execution, liquidityM is updated using an asymmetric rounding scheme in perpTrade.sol:

// perpTrade.sol lines 295-298 (LONG trade path)
liquidityM[0][0] += aY * m10 / liqMDec;                 // floor division (rounds DOWN)
liquidityM[0][1] += aY * m11 / liqMDec;                      // floor division
liquidityM[1][0] = m10 - UtilMath.divCeil(aX * m10, liqMDec); // divCeil (rounds UP)
liquidityM[1][1] = m11 - UtilMath.divCeil(aX * m11, liqMDec); // divCeil (rounds UP)

The divCeil function rounds up on subtractions, while additions use standard floor division. This means each trade subtracts slightly more than the exact math dictates — a net loss of ~1 wei per trade that accumulates in liquidityM.

When getLpLiquidityBalance() was subsequently called, it computed actualM = M(t) * M^-1(t0) using the drifted liquidityM and the previously snapshotted inverse. Due to the accumulated divCeil rounding, actualM[1][0] evaluated to -1 instead of 0:

// internalPerpLogic.sol lines 38-54
int256[2][2] memory actualM =
    MatrixMath.matMulTwoByTwo(liquidityM, position.inverseSnapshotM, decimals.liquidityMDecimals);

int256 m10 = actualM[1][0]; // becomes -1 due to divCeil rounding

// VULNERABILITY: direct unsafe cast from int256 to uint256
lpAssetBalance = uint256((initialStableBalance * m10 + initialAssetBalance * m11) / d);

With the attacker’s stable-only deposit (initialStableBalance = D + 1, initialAssetBalance = 0), the dot product resolved to:

((D+1) * (-1) + 0 * m11)/D  =  -(D+1) / D = -1(Solidity integer division toward zero)

The unsafe cast then triggered a full uint256 underflow:

uint256(-1) == 115792089237316195423570985008687907853269984665640564039457584007913129639935
            == type(uint256).max

A subsequent cap guard clamped this to globalLiquidityAsset, effectively giving the attacker a claim over 100% of the asset pool. The attacker then called realizePnL to convert this inflated balance into USDC and withdraw from the vault, draining $165,618 USDC.

Root Cause

The root cause is the interaction between two issues:

1. Rounding asymmetry in trade execution (perpTrade.sol): Additions use floor division while subtractions use divCeil. Each trade erodes matrix elements by ~1 wei more than exact math. After ~8 trades, this accumulated error makes actualM[1][0] go from 0 to 1.

2. Unsafe int256 → uint256 cast (internalPerpLogic.sol lines 53-54): The dot-product result is cast directly without checking for negativity. When the result is 1, the cast wraps to type(uint256).max.

Individually, neither issue would have been critical. The rounding alone only introduces sub-wei inaccuracies, and the unsafe cast is harmless without a negative input. Their combination made the exploit possible.

Lesson learned

• Never Use Unsafe int256 → uint256 Casts

  Always check value >= 0 before casting, or use SafeCast.toUint256() which reverts on negative inputs. A result of -1 silently becomes type(uint256).max — the largest possible number — and no amount of downstream capping fully mitigates this once it has happened.

• Beware of Asymmetric Rounding in Matrix Arithmetic

  When using floor for additions and divCeil for subtractions in fixed-point matrix operations, each operation creates a net loss of ~1 wei. Over multiple trades, this one-sided rounding accumulates and can flip the sign of matrix elements that should theoretically remain non-negative. Symmetric rounding or explicit rounding-error bounds checks are essential.

• Beware of Post-Audit Refactors

  The rounding flaw was introduced in a refactor carried out after the completion of the external audit by Consensys Diligence. Any code modification to mathematical core logic must undergo a secondary security review and regression testing before deployment.

Overview

Attacker: 0x81Fe3D7d35dFeFa15b9E6800B6aeFC3358E7b156

Vulnerable Implementation: 0x5f0ad32c00641d1d2bb628ff341e0d4bb4494318

Exploit TX: 0x5edb66a4c2ea55bba95d36d27713e3bb1c67c3c4199a8a1759e754c6f25482e5

Exploit Analysis

GiddyVaultV3 uses a signed authorization struct called VaultAuth. Every deposit, withdraw, and compound operation validates this authorization before executing.

The swap objects are not just metadata. They decide which token is moved, how much is approved, which contract receives the approval, and which contract is called.

The problem is that the EIP-712 hash does not cover the full SwapInfo.

The Signed Message

The declared type hash only includes nonce, deadline, top-level amount, and bytes[] data.

Inside _validateAuthorization, the contract loops over the swap arrays and hashes only each swap’s data field.

The following fields are present in calldata but are not signed:

• swap.fromToken

• swap.toToken

• swap.amount

• swap.aggregator

That is the core bug.

The nonce check means this should not be described as a simple replay of an already-used signature. A successful authorization burns its nonce; the same validation path reverts when nonceUsed[auth.nonce] is already true and later marks the nonce as used.

The more precise description is: the attacker submitted a valid authorization, but rebound the unsigned swap wrapper fields to attacker-controlled values. The contract accepted the signature because the signed digest still matched.

Why the Unsigned Fields Were Dangerous

The dangerous part is in GiddyLibraryV3.executeSwap().

These four unsigned fields control real effects:

• fromToken controls which token the vault or strategy approves.

• amount controls how much allowance is granted.

• aggregator controls the spender and external call target.

• toToken controls which token balance is checked after the call.

So the signature covered only swap.data, while the unsigned wrapper decided the approval and external call environment around that data.

This is like signing the inside of an envelope while letting the transaction sender rewrite the destination address, the asset, and the amount on the outside.

Attack Flow

The exploit transaction created the attacker contract and used it to interact with multiple Giddy vaults in one transaction.

At a high level:

1. The attacker submitted a VaultAuth that passed _validateAuthorization().

2. The attacker kept the signed data hash valid but changed unsigned SwapInfo fields.

3. fromToken was set to real gauge tokens held by the strategy.

4. aggregator was set to attacker-controlled 0x7326...4528.

5. executeSwap() called forceApprove(fromToken, aggregator, amount).

6. The malicious aggregator used that allowance path to move the approved gauge tokens.

7. The fake toToken behavior satisfied the vault’s post-swap received-token check.

The Root Cause

The root cause was incomplete signature coverage.

The contract treated SwapInfo.data as if it represented the whole swap. It did not. The actual swap identity was fromToken + toToken + amount + aggregator + data, and only one component of that tuple was signed.

Because aggregator was unsigned, the attacker could choose the call target. Because fromToken and amount were unsigned, the attacker could choose the token allowance. Because toToken was unsigned, the attacker could satisfy the output check with a fake or attacker-controlled token.

The post-call checks were not enough:

These checks only prove that the selected fromToken balance decreased and the selected toToken balance increased. If the attacker can select both tokens and the aggregator, those checks are no longer meaningful security boundaries.

Conclusion

When using off-chain signatures to authorize on-chain execution, always proceed with caution. EIP-712 only protects the fields included in the signed digest. Any field left unsigned should be treated as user-controlled, because it can be altered in calldata and may become part of the exploit path.

Furthermore, conducting a security audit is strongly recommended for all projects, even though they are smart contracts, backends, wallets, or dapps.

What makes this incident particularly ironic? Just twelve days earlier, on April 1, Hyperbridge had published a satirical post joking about suffering a catastrophic exploit - boasting their protocol was “un-hackable.” Reality had other plans.

• Date: April 13, 2026, 03:39 – 05:08 UTC

• Protocol: Hyperbridge / ISMP Token Gateway (Ethereum)

• Loss: ~$237,000 (108.2 ETH)

• Root Cause: Missing leaf_index < leafCount bounds check in MMR proof verification

• Attacker: 0xC513E4f5D7a93A1Dd5B7C4D9f6cC2F52d2F1F8E7

• Tokens Affected: DOT (1B), ARGN (999B), MANTA (211K), CERE (23B)

Background

Hyperbridge is a cross-chain interoperability layer built by Polytope Labs that connects Polkadot to EVM-compatible chains like Ethereum. It uses the Interoperable State Machine Protocol (ISMP) to relay messages between chains, with smart contracts on Ethereum responsible for verifying cross-chain state proofs and dispatching actions like token minting and transfers.

The bridge’s security model relies on Merkle Mountain Range (MMR) proofs - a data structure used in Polkadot’s consensus - to verify that incoming cross-chain messages are legitimate. The HandlerV1 contract processes these messages: it fetches a committed Merkle root, validates message inclusion against that root, and if verification passes, dispatches the requested action.

The critical assumption? That the MMR verification library would reject any message not genuinely included in the Merkle tree. That assumption was wrong.

Root Cause

The vulnerability lies in the CalculateRoot function of the MerkleMountainRange library - a shared Solidity dependency maintained by Polytope Labs for verifying MMR proofs.

The function has a special early-exit path for single-leaf trees:

// MerkleMountainRange.sol - CalculateRoot function
// https://github.com/polytope-labs/solidity-merkle-trees

function CalculateRoot(
    bytes32[] memory proof,
    MmrLeaf[] memory leaves,
    uint256 leafCount
) internal pure returns (bytes32) {
    // special handle the only 1 leaf MMR
    if (leafCount == 1 && leaves.length == 1 && leaves[0].leaf_index == 0) {
        return leaves[0].hash;  // <-- Returns the actual leaf hash
    }
    // ... general computation path follows ...
}

When leafCount = 1 and leaf_index = 0, the function returns leaves[0].hash - the actual commitment from the cross-chain message. This is the correct behavior.

Here’s where it gets interesting. When the attacker set leaf_index = 1 - an out-of-bounds index for a tree with only one leaf (leafCount = 1) - the early-exit condition fails because leaves[0].leaf_index == 0 is no longer true. The function falls through to the general computation path:

for (uint256 p; p < length; ) {
    uint256 height = subtrees[p];
    current_subtree += 2 ** height;

    LeafIterator memory subtreeLeaves = getSubtreeLeaves(
        leaves, leafIter, current_subtree
    );

    if (subtreeLeaves.length == 0) {
        // No leaves in this subtree - take next proof element
        if (proofIter.data.length == proofIter.offset) {
            break;
        } else {
            push(peakRoots, next(proofIter));  // <-- proof[0] goes directly into peakRoots!
        }
    } else if (subtreeLeaves.length == 1 && height == 0) {
        push(peakRoots, leaves[subtreeLeaves.offset].hash);
    } else {
        push(peakRoots, CalculateSubtreeRoot(leaves, subtreeLeaves, proofIter, height));
    }
    unchecked { ++p; }
}

Since leaf_index = 1 is out of range, getSubtreeLeaves finds zero leaves matching the subtree. The code enters the subtreeLeaves.length == 0 branch and pushes proof[0] directly into peakRoots. After the peak-bagging loop, peakRoots.data[0] is returned as the computed root.

The result: CalculateRoot returns proof[0]. The attacker simply sets proof[0] equal to the expected overlay root. The “computed root” matches the “expected root” - verification passes. The actual leaf hash - the attacker’s forged message commitment - is never used in the calculation at all.

Step-by-Step: The Attack

The attacker executed a series of transactions between 03:39 and 05:08 UTC, systematically exploiting the vulnerability across multiple bridged tokens:

1. Test Run - At 03:39 UTC, the attacker deployed a contract and executed a small test transaction involving DAI (~$423), probing the exploit path (tx 0xfa23fb22...)

2. ARGN Token Mint - At 04:20 UTC, the attacker minted ~1 billion ARGN tokens, routing them through Uniswap V3 and Odos Router V3, netting approximately 1.75 ETH (tx 0xb28ab952...)

3. DOT Probe - At 04:26 UTC, the attacker minted 10,000 DOT in a smaller test, extracting ~0.02 ETH. This transaction had partial execution revert issues, suggesting the attacker was calibrating parameters (tx 0xb80c7d4c...)

4. Main DOT Dump - At 04:33 UTC, the attacker minted 1,000,000 DOT (~$1,260,000 in nominal value) and swapped them through Uniswap V4 and Odos Router, extracting approximately 0.387 ETH (tx 0x743f4bdb...)

5. Continued Extraction - At 04:51 UTC, another 712,403 DOT were minted and dumped through Uniswap V4, with diminishing returns as liquidity pools dried up (tx 0x6f1efcde...)

6. Final Sweep - At 05:07 UTC, the attacker minted a final 1,000 DOT, squeezing the last drops of liquidity from the pool (tx 0xb93aab83...)

Each exploit transaction followed the same pattern: deploy a new contract, call HandlerV1.handlePostRequests with a forged ChangeAssetAdmin message using the MMR bypass (setting leaf_index = 1, leafCount = 1, and proof[0] = overlay_root), gain admin/minter privileges on the target bridged token contract, mint tokens, and dump them through DEX aggregators.

Code Analysis

The vulnerability is a textbook case of inconsistent library behavior at edge cases. Here’s the core of the issue in the HandlerV1.handlePostRequests function:

// HandlerV1.sol - handlePostRequests
// https://github.com/polytope-labs/hyperbridge/blob/05031ae/evm/src/core/HandlerV1.sol

function handlePostRequests(IHost host, PostRequestMessage calldata request) 
    external notFrozen(host) 
{
    uint256 requestsLen = request.requests.length;
    MmrLeaf[] memory leaves = new MmrLeaf[](requestsLen);

    for (uint256 i = 0; i < requestsLen; ++i) {
        PostRequestLeaf memory leaf = request.requests[i];
        bytes32 commitment = leaf.request.hash();
        // leaf.kIndex and leaf.index come directly from untrusted input
        // No validation that leaf.index < leafCount!
        leaves[i] = MmrLeaf(leaf.kIndex, leaf.index, commitment);
    }

    bytes32 root = host.stateMachineCommitment(request.proof.height).overlayRoot;
    if (root == bytes32(0)) revert StateCommitmentNotFound();

    // Passes attacker-controlled leaf_index to the MMR verifier
    bool valid = MerkleMountainRange.VerifyProof(
        root, request.proof.multiproof, leaves, request.proof.leafCount
    );
    if (!valid) revert InvalidProof();

    // If verification "passes", forged messages get dispatched
    for (uint256 i = 0; i < requestsLen; ++i) {
        PostRequestLeaf memory leaf = request.requests[i];
        host.dispatchIncoming(leaf.request, _msgSender());
    }
}

The handler accepts leaf.index and leafCount directly from the calldata - completely attacker-controlled. No sanity check verifies that leaf.index < leafCount. This untrusted input flows directly into the MMR library’s CalculateRoot, triggering the bypass.

The following proof-of-concept demonstrates the inconsistency:

function test_MerkleMountainRange_InconsistentBehavior() public {
    bytes32[] memory proof = new bytes32[](1);
    proof[0] = 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;

    MmrLeaf[] memory leaves = new MmrLeaf[](1);

    // Case A: leaf_index = 0 → early exit, returns leaf hash (correct)
    leaves[0] = MmrLeaf(0, 0, 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb);
    bytes32 rootA = MerkleMountainRange.CalculateRoot(proof, leaves, 1);
    // rootA = 0xbbbb...  ← leaf hash, proof is ignored

    // Case B: leaf_index = 1 → bypasses early exit, returns proof[0] (VULNERABLE)
    leaves[0] = MmrLeaf(0, 1, 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb);
    bytes32 rootB = MerkleMountainRange.CalculateRoot(proof, leaves, 1);
    // rootB = 0xaaaa...  ← attacker controls this! leaf hash completely ignored
}

The fix is remarkably simple - a single bounds check:

// Add this before the CalculateRoot computation:
require(leaf.index < leafCount, "leaf index out of bounds");

One line of validation. That’s the difference between a secure bridge and a $237K exploit with billions in unbacked tokens minted.

Lessons Learned

• Validate all inputs at system boundaries. The handler accepted leaf_index and leafCount from untrusted calldata and passed them directly to a security-critical library. Every parameter that feeds into proof verification must be bounds-checked before use - trusting that a library will handle edge cases correctly is a dangerous assumption.

• Fuzz test cryptographic libraries exhaustively. The MMR library’s behavior diverged at a single edge case (leaf_index >= leafCount). Random fuzzing with arbitrary leaf_index values would have caught this inconsistency immediately. Cryptographic verification code demands the highest testing standards - property-based and fuzz testing are non-negotiable.

• Library security is protocol security. The vulnerable code lived in solidity-merkle-trees, a shared dependency. Bridge protocols that delegate proof verification to external libraries must audit those libraries as rigorously as their own code. A bug in a dependency is a bug in your protocol.

• Inconsistent edge-case behavior is a vulnerability class. The CalculateRoot function had two code paths that behaved fundamentally differently based on leaf_index. Path A (index 0) used the leaf hash; Path B (index 1) used the proof element. This kind of bifurcated logic in security-critical code is a red flag that demands explicit documentation and testing.

• Defense-in-depth for cross-chain bridges. Beyond proof verification, secondary safeguards - rate limiting on minting, admin-change timelocks, anomaly detection - could have limited the blast radius even after verification was bypassed.

Subscribe now

Conclusion

The Hyperbridge exploit is a stark reminder that in cross-chain security, the most devastating vulnerabilities often hide in the most fundamental building blocks. A single missing bounds check - leaf_index < leafCount - turned a Merkle Mountain Range verifier into an open door, allowing an attacker to forge cross-chain messages, seize admin privileges, and mint billions in unbacked tokens across DOT, ARGN, MANTA, and CERE.

Despite minting over $2 billion in nominal token value, the attacker walked away with roughly $237K - a testament to the thin liquidity of bridged assets, but cold comfort for a protocol that staked its reputation on being “trust-minimized.” The ironic timing - just twelve days after an April Fools’ post joking about being hacked - underscores that security claims must be backed by rigorous engineering, not confidence.

This incident reinforces that oracle and proof verification code is the bedrock of cross-chain security. When the verification layer fails, everything built on top of it fails. In DeFi, a missing bounds check isn’t a minor oversight - it’s an existential risk.

On March 17, 2026, the DeFi protocol dTRINITY, a lending protocol on Ethereum, suffered a security incident resulting in an estimated loss of ~$257.3K.

The exploit stemmed from an empty market weakness commonly found in forks of Aave V3, where reserves with extremely low liquidity can behave unpredictably. In this scenario, repeated accumulation of flash loan premiums caused the liquidityIndex to increase to an abnormally high level, disrupting the accuracy of the reserve’s accounting. This distortion led to precision issues in deposit and withdrawal calculations, enabling the attacker to artificially inflate collateral value, borrow dUSD against it, and reclaim the deposited cbBTC for a net gain.

Technical Analysis of the Exploit

Incident Overview

• Date: March 17, 2026

• Protocol: dTRINITY

• L2Pool Contract: 0xfda3a0effe2f3917aa60e0741c6788619ae19e84

• Exploiter Address: 0x08cfdff8ded5f1326628077f38d4f90df6417fd9

• Attack Transactions:

  • 0x8d33d688def03551cb77b0463f55ae5a670f5ebf3bbb5b8aa0e284c040ae7139

  • 0xbec4c8ae19c44990984fd41dc7dd1c9a22894adccf31ca6b61b5aa084fc33260

Root Cause

The exploit stemmed from an empty market vulnerability in the lending pool of dTRITINY, an AAVE V3–style implementation, where the cbBTC reserve operated with near-zero liquidity.

At the core of the issue is the protocol’s liquidity index update mechanism, which is triggered on every flash loan repayment through _handleFlashLoanRepayment and is defined as:

Under these conditions, repeated flash loan premium accrual caused the reserve’s liquidityIndex to increase disproportionately, as the index update mechanism scales inversely with total liquidity. With minimal liquidity, even small premiums led to significant index inflation.

This created a misalignment between scaled balances and underlying assets, introducing a rounding asymmetry in which:

• Small deposits minted shares at an artificially low cost

• Withdrawals redeemed disproportionately higher value

As a result, the attacker was able to inflate collateral value, borrow against it, and extract real assets from the protocol.

Attack Flow

The exploit was executed across two sequential transactions, leveraging abnormal growth of the liquidityIndex in a near-empty cbBTC reserve.

liquidityIndex Manipulation Transaction

Transaction: 0x8d33d688def03551cb77b0463f55ae5a670f5ebf3bbb5b8aa0e284c040ae7139

The attacker executed a multi-step strategy to manipulate the internal accounting of the cbBTC reserve, ultimately inflating the liquidityIndex far beyond its true economic value.

• Borrowed cbBTC from Morpho Blue and deposited it into the dLEND-cbBTC pool, minting 100 scaled shares.

• Withdrew 99 shares, leaving only a share balance and effectively reducing the reserve to an almost-empty state.

  

• Transferred 0.8 cbBTC directly to the dLEND-cbBTC aToken contract.

• Repeatedly invoked flashLoan operations to accumulate premiums into the reserve, causing the liquidityIndex to increase disproportionately (reaching ~6.22e27)

• Performed additional deposit/withdraw cycles to extract residual liquidity from the pool

• Repaid the flash loan

  

At the end of this transaction, the reserve was left in a distorted state, where the liquidityIndex was significantly inflated relative to actual liquidity.

Collateral Inflation and Profit Extraction Transaction

Transaction: 0xbec4c8ae19c44990984fd41dc7dd1c9a22894adccf31ca6b61b5aa084fc33260

With the manipulated reserve state in place, the attacker proceeded to extract value by leveraging the inflated liquidityIndex.

• Borrowed cbBTC again from Morpho Blue and deposited ~7.72 cbBTC into the compromised reserve. Due to the inflated liquidityIndex, the deposit was overvalued, resulting in an artificially large collateral position.

• Used this inflated collateral to borrow approximately ~257.3K dUSD from the dLEND-dUSD market.

  

• Continued extracting cbBTC through repeated deposit and withdrawal cycles.

• Repaid the flash loan and transferred the borrowed dUSD to the attacker’s externally owned account (EOA)

Conclusion

This incident highlights how flaws in index-based accounting under low-liquidity conditions can be exploited to create severe economic distortions. By reducing the cbBTC reserve to a near-empty state and artificially inflating the liquidityIndex through flash loan premiums, the attacker was able to overvalue collateral and borrow assets far beyond legitimate limits. The exploit underscores the importance of enforcing liquidity constraints and ensuring that critical accounting variables remain tightly aligned with actual underlying value.

Original Attacker :

https://bscscan.com/address/0xe92fa2a5fef535479a91ab9ed90b26256ff276f1

https://etherscan.io/address/0x63150ac8e35c6c685e93ee4d7d5cb8eafb2f016b

Vulnerable Contract :

https://bscscan.com/address/0x9caf6c4e5b9e3a6f83182befd782304c7a8ee6de

https://etherscan.io/address/0xf5c80c305803280b587f8cabbccdc4d9bf522abd

Attack Tx :

https://bscscan.com/tx/0xe66e54586827d6a9e1c75bd1ea42fa60891ad341909d29ec896253ee2365d366

https://etherscan.io/tx/0x914a5af790e55b8ea140a79da931fc037cb4c4457704d184ad21f54fb808bc37

Analysis

The contract is a reward distribution system where users burn XEN tokens to earn DBXen rewards and a share of protocol fees. The system operates in discrete time intervals called cycles. During each cycle, users can burn tokens via burnBatch, and their contribution is tracked through accCycleBatchesBurned. At the end of a cycle, rewards are distributed proportionally based on the number of batches burned relative to the total batches burned in that cycle.

In addition to rewards, users can earn fees generated by the protocol. These fees are distributed based on a user’s accumulated rewards and stake. The function updateStats plays a central role by settling all pending rewards, fees, and stake transitions for a user whenever they interact with the contract (e.g., claiming rewards or fees).

The vulnerability arises from inconsistent use of msg.sender and _msgSender() across the contract. Specifically, different parts of the same logical flow attribute user actions to different addresses.

In bunBatch, the contract uses _msgSender() when updating accCycleBatchesBurned, meaning the burned amount is credited to the actual user.

However, when interacting with the XEN token contract, the burn mechanism uses msg.sender, which corresponds to the forwarder in a meta-transaction context. As a result, the burn operation is executed on behalf of the forwarder, not the user.

First, the attacker calls burnBatch via a trusted forwarder. This results in accCycleBatchesBurned being incremented for the attacker, while lastActiveCycle is updated for the forwarder. At this point, the system already holds inconsistent state.

Next, the attacker calls either claimRewards or claimFees. Both of these functions internally call updateStats, which attempts to calculate pending rewards for the user.

Inside updateStats, the contract checks whether the current cycle is greater than lastActiveCycle[account] and whether the user has non-zero burned batches. Because lastActiveCycle[attacker] was never updated, this condition remains true even after rewards have already been calculated.

As a result, the contract repeatedly assumes that the attacker’s burn contribution has not yet been processed and recalculates rewards every time updateStats is invoked.

Conclusion

The root cause of the vulnerability is inconsistent identity handling in a meta-transaction context. By mixing msg.sender and _msgSender() across different parts of the same execution flow, the contract attributes related state updates to different addresses. This leads to a breakdown in internal accounting, allowing an attacker to repeatedly claim rewards from a single action and ultimately drain funds from the protocol.

Overview

• Attacker: 0xA407fE273DB74184898CB56D2cb685615e1C0D6e

• Attacker’s contract: 0x6aA78a9B245Cc56377b21401B517EC8c03a40F03

• Attacker’s wallet: 0xb32D389901f963E7C87168724fBDCC3A9DB20dc9

• Vulnerable contract: BitcoinReserveOffering

• Attack transaction: 0x44e637c7d85190d376a52d89ca75f2d208089bb02b7c4708ad2aaae3a97a958d

Analysis

From an initial review of the transaction, the attacker executed a 22-iteration loop to mint and burn tokens, with the amount of BRO tokens doubling each time (what an interesting strategy!).

In each cycle, the attacker performed the following steps:

1. Burned BRO to receive a GOEFS NFT (a vault share NFT used to represent ownership and enable functions such as voting).

2. Burned the NFT to redeem the BRO tokens back.

A deeper inspection reveals an interesting issue in the mint() function: it mints BRO tokens twice for a single burned NFT. This effectively means that an attacker could acquire an NFT and redeem it to receive double the amount of BRO, creating an immediate profit opportunity.

After double-checking the verified source code of BitcoinReserveOffering, we can confirm that the contract contains a double-mint vulnerability. This flaw is the root cause of the exploit.

P/S: This is not a re-entrancy bug, since the control flow remains entirely within the contract and no external calls are involved. As a result, the vulnerability stems from flawed internal logic rather than re-entrant execution.

In the end, the attacker accumulated approximately 567M BRO tokens. He then exchanged only 165M BRO for 38 SolvBTC, and subsequently used Uniswap to swap the SolvBTC for 1,211 WETH, which was ultimately converted to ETH and transferred back to his EOA wallet.

Summary

In this exploit, attacker took advantage of a flaw in the contract logic to repeatedly manipulate the mint and redemption process and extract funds from the system. To reduce the risk of similar incidents, DeFi protocols should adopt strong security practices throughout development. This includes conducting comprehensive smart contract audits by reputable security firms, implementing thorough testing (especially for mint, burn, and accounting logic), and adding safeguards such as monitoring and emergency controls. Regular security reviews and audits are particularly important for complex financial contracts, as they can help detect subtle logic flaws before deployment.

Incident Overview

Date: Feb 22, 2026

Platform: Binance Smart Chain (BSC)

Attacker Address: 0x17f9132E66A78b93195b4B186702Ad18Fdcd6E3D

Attack Contract: 0x6588ACB7dd37887C707C08AC710A82c9F9A7C1E9

Laxo Token Contract: 0x62951CaD7659393BF07fbe790cF898A3B6d317CB

Attack Transaction: 0xd58f3ef6414b59f95f55dae1acb3d5d6e626acf5333917c6d43fe422d98ac7d3

Exploit Mechanics

All steps below were executed within a single transaction by the attack contract:

1. Borrowed 350k USDT from a PancakeSwap V3 pool using a flash loan.

2. Bought a large amount of LAXO tokens from the LAXO/USDT pool, temporarily stored them in PancakeRouter.

3. Added a small amount of liquidity (BNB and LAXO) and immediately removed it.

   This trick allowed the attacker to retrieve the temporarily stored tokens from PancakeRouter and avoid the swap fee from step 2.

4. Sold all LAXO tokens back into the LAXO/USDT pool.

   This action triggered the burn mechanism, which incorrectly updated the reserves in the PancakeSwap pool. The attacker was then able to withdraw 487k USDT.

5. Repaid 350,175 USDT to the PancakeSwap V3 pool to settle the flash loan.

Root Cause Analysis

The root issue occurs in step 4, where the PancakeSwap pool updates its reserves incorrectly.

A deeper look into the _transfer internal function of the LAXO token reveals a burn mechanism triggered when users sell tokens. The problem lies in the position of the sync call.

The contract executes sync after transferring tokens from the pair to the dead address (burn). The sync function updates the pair reserves based on the remaining LAXO and USDT balances in the pair contract.

The sync action occurs immediately after burning, causing the pair to record incorrect reserves. This inflates the LAXO reserve value, enabling the attacker to extract excess USDT from the pool when selling the remaining LAXO tokens.

Conclusion

The LAXO exploit highlights the risks of improper token logic interacting with AMM liquidity pools. A misordered burn operation and sync call caused the PancakeSwap pair to record incorrect reserves. This broke the pool’s reserve accounting and allowed the attacker to extract excess USDT. The incident shows that token mechanisms such as burns or fees must be carefully designed to avoid interfering with pool reserve updates. Projects should thoroughly review and test how their token contracts interact with AMM pools to ensure reserve calculations remain accurate and secure.

Overview

Vulnerable Contract: 0x00000000000044a361ae3cac094c9d1b14eece97

Exploit TX: 0xfe34c4beee447de536bbd3d613aa0e3aa7eeb63832e9453e4ef3999924ab466a

Exploit Analysis

The UniswapV4Router04 provides multiple swap functions. Most of these functions safely hardcode payer: msg.sender into the BaseData struct, ensuring only the caller’s tokens can be spent. However, one overload - swap(bytes calldata data, uint256 deadline) - accepts pre-encoded data directly from the caller and uses inline assembly for authorization. This is where the vulnerability lies.

The Vulnerable Function

The swap(bytes,uint256) function contains an inline assembly authorization check intended to verify that the payer field inside the encoded BaseData struct equals msg.sender:

The comment says it is “equivalent to require(abi.decode(data, (BaseData)).payer == msg.sender, Unauthorized())“ - but it is not.

Why calldataload(164)?

The developer assumed the standard (canonical) ABI encoding layout for swap(bytes,uint256). Under that assumption, the calldata is structured as:

| Byte Offset | Size | Content |
|---|---|---|
| `0–3` | 4 bytes | Function selector |
| `4–35` | 32 bytes | Offset to `bytes data` (assumed `0x40` = 64) |
| `36–67` | 32 bytes | `uint256 deadline` |
| `68–99` | 32 bytes | Length of `bytes data` |
| `100–131` | 32 bytes | `BaseData.amount` |
| `132–163` | 32 bytes | `BaseData.amountLimit` |
| **`164–195`** | **32 bytes** | **`BaseData.payer`** ← `calldataload(164)` reads here |

So calldataload(164) reads exactly BaseData.payer - but only when the bytes data parameter starts at the standard offset of 0x40 (64).

ABI Encoding Permits Non-Standard Offsets

According to the Solidity ABI Specification, dynamic types like bytes are not encoded in-place. Instead, the head part contains an offset pointer to where the data actually begins:

“For dynamic types, head(X(i)) is the offset of the beginning of tail(X(i)) relative to the start of enc(X).”

The Solidity ABI decoder follows this offset pointer to locate the data. Critically, the ABI specification does not require the offset to be the minimum possible value. From the Strict Encoding Mode section:

“Strict encoding mode is the mode that leads to exactly the same encoding as defined in the formal specification above. This means that offsets have to be as small as possible while still not creating overlaps in the data areas, and thus no gaps are allowed.”

“Usually, ABI decoders are written in a straightforward way by just following offset pointers, but some decoders might enforce strict mode. The Solidity ABI decoder currently does not enforce strict mode, but the encoder always creates data in strict mode.”

This means the Solidity decoder happily accepts calldata where the bytes data parameter starts at any valid offset - not just 0x40. An attacker can set the offset to a larger value, shifting where the actual BaseData struct is located in the calldata, while placing their own address at the fixed position 164.

The Disconnect

After the assembly check passes, the function calls _unlockAndDecode(data):

Inside the unlock callback, the data is decoded using Solidity’s standard abi.decode:

This abi.decode correctly follows the offset pointer and reads BaseData from wherever data actually points - which, in the attacker’s crafted calldata, is at a different location than position 164.

Attack Flow

The attacker constructs calldata for swap(bytes,uint256) with a non-standard offset for the bytes data parameter:

1. Position 164: Contains the attacker’s own address → passes the calldataload(164) == caller() assembly check.

2. Actual bytes data: Located at a different offset, contains a BaseData struct with payer set to the victim’s address.

When the swap executes, the victim’s tokens are used for the input settlement. Since the victim had previously approved the router contract for USDC spending, the router successfully transfers USDC from the victim to complete the swap, sending the output tokens to the attacker’s chosen receiver.

Conclusion

This exploit demonstrates the danger of using hardcoded calldata offsets in inline assembly for authorization checks. The EVM’s ABI encoding is more flexible than developers often assume - dynamic types like bytes can have their data placed at arbitrary offsets, and the Solidity ABI decoder does not enforce strict encoding mode. Any security check that relies on a fixed calldata position will fail when confronted with non-standard but perfectly valid ABI encoding.

Furthermore, conducting a security audit is strongly recommended for all projects, even though they are smart contracts, backends, wallets, or dapps.

SwapNet is a DEX aggregator designed to find optimal swap routes by aggregating liquidity from multiple on-chain sources, including AMMs and private market makers. The protocol allows users to specify custom routers or pools when executing swaps. Its smart contracts were closed-source and not verified on block explorers.

SwapNet Router

The SwapNet Router contract is the core contract that executes token swaps. Users approve their tokens to the router, and the router executes swaps through various DEX protocols (Uniswap V2/V3, Curve, etc.). The router supports multi-hop swap routing with user-supplied parameters.

The normal swap flow works as follows:

1. Users approve their tokens to the SwapNet Router contract

2. Users call a swap function with parameters specifying the input token, output token, and routing path

3. The router transfers the input tokens from the user, executes the swap through the specified DEXs, and sends the output tokens back to the user

Key Information

• SwapNet Router: https://basescan.org/address/0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e

• Upgrade Tx: https://basescan.org/tx/0xdf81a643b03c4364dd2740d3ac177d0184c5b4e432257aaa0c277d4eef88a011

• Attack Tx: https://basescan.org/tx/0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57

Exploit Analysis

The root cause of the exploit is an arbitrary-call vulnerability stemming from insufficient validation of user-supplied inputs in the SwapNet Router’s closed-source smart contracts.

Based on the decompiled bytecode, the vulnerable function 0x87395540() handles the core swap routing logic. For each swap step, the contract determines the DEX type and executes the appropriate swap. The contract supports dozens of DEX types identified by numeric codes in msg.data:

For certain DEX types (particularly the custom router type), the contract performs a low-level call to a user-supplied address (v75) with user-controlled calldata:

The critical issue is that no validation is performed on v75 (the call target address). The attacker exploited this by:

1. Setting the internal key variable v75 to the USDC token address instead of a legitimate DEX router, bypassing the intended routing logic.

2. Crafting the calldata to encode transferFrom(SwapNetRouter, attacker, amount).

3. Since the SwapNet Router contract held user approvals (from users who granted infinite approvals), the USDC.transferFrom() call succeeded, and the attacker drained all approved USDC.

The attack involved two main steps:

1. A key internal variable (e.g., v51) was set to USDC, bypassing intended routing logic.

2. A low-level call was executed using attacker-controlled calldata, resulting in USDC.transferFrom() being invoked, draining all approved USDC from users.

After the initial exploit on Base, the attacker swapped approximately $10.5M in USDC for ~3,655 ETH, then bridged the stolen funds to the Ethereum mainnet to obscure the transaction trail. The attacker continued to drain 17 additional users across 3 chains before SwapNet paused contracts ~45 minutes later.

Conclusion

The SwapNet exploit demonstrates the dangers of closed-source smart contracts and arbitrary-call vulnerabilities in DeFi protocols:

1. Insufficient Input Validation: The function lacked proper validation on the call target address. By replacing the expected router/pool address with a token address (e.g., USDC), the attacker tricked the contract into executing transferFrom() with attacker-controlled parameters.

2. Closed-Source Risk: Because SwapNet’s contracts were not verified on block explorers, the community could not review the code for vulnerabilities. The arbitrary-call flaw might have been caught through standard code review or audit.

3. Persistent Approval Danger: Users who granted infinite approvals directly to the SwapNet Router were exposed to maximum risk. The exploit drained the full approved balance, not just the amount from a single swap.

4. Missing Call Target Whitelist: The contract should have maintained a whitelist of valid DEX router addresses and rejected calls to any other address, especially token contract addresses.

This attack highlights the importance of open-source smart contracts, proper input validation on low-level calls, and the use of per-transaction approval patterns instead of persistent infinite approvals. The $13.4M loss could have been prevented through call target whitelisting, function selector validation, and open-source code review.

On January 20, 2026, Makina Finance fell victim to a sophisticated oracle manipulation attack, resulting in a loss of approximately $4.13 million. The attacker exploited the protocol’s reliance on spot pricing from a Curve Finance pool to manipulate the value of the MachineShareOracle. By heavily distorting the liquidity in the underlying DUSD/USDC pool via a flash loan, the attacker was able to artificially inflate the share price, deposit assets at this manipulated value, and subsequently exit with a significant profit.

• Attack Transaction: 0x569733b8016ef9418f0b6bde8c14224d9e759e79301499908ecbcd956a0651f5

• Attacker Address: 0x935bfb495E33f74d2E9735DF1DA66acE442ede48

Deep Dive

Attack Flow

The exploitation followed a classic “pump-and-dump” pattern using flash loan liquidity to skew on-chain price feeds.

1. Flash Loan: The attacker borrowed a massive amount of liquidity (approximately 280 million USDC) to secure the capital needed for manipulation.

   

2. Market Distortion: The attacker deployed roughly 170 million USDC into the DUSD/USDC Curve pool. This unbalanced the pool significantly, distorting the output of calc_withdraw_one_coin and the spot price reported by the pool.

   

3. Oracle Update: Makina’s MachineShareOracle updated its internal price based on this manipulated state. Because the protocol relied on the spot liquidity/balance of the Curve pool without sufficient Time-Weighted Average Price (TWAP) or liquidity cap checks, the sharePrice was artificially inflated.

4. Arbitrage Execution:

   • With the sharePrice inflated, the attacker interacted with the Makina Machine, depositing/swapping the remaining 110 million USDC against the protocol’s liquidity.

   • Due to the distorted valuation, the protocol credited the attacker with significantly more shares/value than the true market rate.

5. Exit & Profit: The attacker reversed the pool manipulation (or simply withdrew) and paid back the flash loan, pocketing the difference—roughly $4.13M (mostly captured by an MEV builder).

Root Cause

The core vulnerability was the protocol’s dependency on a spot price oracle derived from a manipulatable liquidity pool (Curve). In DeFi, relying on the instantaneous balance or get_dy/calc_withdraw_one_coin of an AMM pool is inherently risky if the pool’s liquidity is low relative to the potential flash loan size. The MachineShareOracle failed to filter out the extreme volatility introduced by the flash loan.

Recommendations

• Implement TWAP Oracles: Replace spot price feeds with Time-Weighted Average Price (TWAP) oracles (e.g., Chainlink, Uniswap V3 TWAP) to smooth out price spikes within a single block.

• Flash Loan Protection: Disallow critical share price updates or deposits/withdrawals in the same transaction as massive liquidity shifts (though this can be bypassed with multi-block attacks, it raises the cost).

• Liquidity & Slippage Checks: Implement strict deviation checks. If the on-chain price deviates significantly from an external benchmark (or a secondary oracle), the transaction should revert.

Conclusion

The Makina Finance incident serves as a stark reminder that oracle design is the bedrock of DeFi security. Even with complex logic, the external dependency on AMM states requires rigorous threat modeling against flash loans.

Subscribe now

However, internal testing is rarely enough. To avoid becoming another statistic in a post-mortem thread, protocols must prioritize rigorous audits from top-tier firms that specialize in complex attack vectors.

On December 29, 2025, the MSCST smart contract on Binance Smart Chain (BSC) was exploited through a flash loan attack, resulting in the theft of approximately 149 BNB (~$130,000). The attacker exploited a critical vulnerability in the releaseReward() function to manipulate the GPC/WBNB liquidity pool price on PancakeSwap and extract profit in a single transaction.

Technical Analysis of the Exploit

Incident Overview

Date: December 29, 2025

MSCST Smart Contract: 0xccd04073f4bdc4510927ea9ba350875c3c65bf81

Exploiter Address: 0xB0720D8541cD2b6fC35cCC39ec84e84383A7000b

Attack Transaction: 0x53fe7ef190c34d810c50fb66f0fc65a1ceedc10309cf4b4013d64042a0331156

Root Cause

The MSCST Smart Contract contains a releaseReward function that accepts an amount parameter. The function swaps half of this amount from MSC tokens to GPC tokens, then transfers the swapped GPC directly to the GPC/WBNB pool. However, the function lacks access control, allowing anyone to call it. The attacker exploited this vulnerability using flash loan techniques to manipulate the GPC/WBNB pool price and extract profit

.

Attack Flow

Below are the detailed steps describing how the attacker exploited the access control vulnerability and flash loan technique for profit.

1. Flash Loan Liquidity: Borrowed 46.8M GPC tokens from a BSC flash loan provider (no collateral needed due to atomic repayment).

   

2. Price Manipulation (Push Down): Swapped the entire 46.8M GPC for 205 BNB in PancakeSwap pool 0x12dA…8D64D9, crashing the GPC price. This maximized profit by artificially depressing the price before calling releaseReward in the next step.

   

3. Exploit releaseReward(): The attacker invoked the unprotected releaseReward() function, which swapped half the MSC balance for GPC and added it directly to the GPC/WBNB pool. This drove the GPC price down further, amplifying the manipulation.

   

4. Profit Extraction: After the steps above, the GPC price in the GPC/WBNB pool was artificially depressed. The attacker used the 205 WBNB obtained in step 2 to buy back GPC and repay the flash loan. Due to the suppressed GPC price, the attacker spent only ~55 BNB on the buyback and pocketed ~149 BNB (~$130K) in profit.

   

Lessons Learned

• Gate reward functions with ACL: The public releaseReward() function allowed anyone to trigger payouts during manipulated states. Basic onlyOwner, timelocks, or role-based access control would have blocked flash loan attacks entirely, preventing attackers from abusing internal accounting logic.

• Replace spot oracles with TWAP: Direct PancakeSwap reserve reads via sync() created a trivially manipulable price feed. Protocols must use time-weighted average prices (30–60 min windows) or Chainlink oracles to filter out short-term distortions from flash loan sandwiches.

• Enforce slippage protection on swaps: Accepting zero minimum output enabled extreme price impacts without reverts. Every DEX operation needs realistic bounds (0.5–5% caps based on pool depth) to reject manipulative trades before they cascade into reward exploits.

Overview

Attacker: 0x6C8EC8f14bE7C01672d31CFa5f2CEfeAB2562b50

Attacker’s contract: 0x1De399967B206e446B4E9AeEb3Cb0A0991bF11b8

Vulnerable Contracts: 0xC186e6F0163e21be057E95aA135eDD52508D14d3

Attack transaction: 0xcd4755645595094a8ab984d0db7e3b4aabde72a5c87c4f176a030629c47fb014

Analysis

When examining the transaction, we observed that getPurchasePrice() unexpectedly returned 0, allowing the attacker to acquire approximately 240 million TRU tokens at no cost.

As the implementation source code is not verified, the following is a decompiled representation of the contract:

The helper functions implement multiplication, subtraction, and division, respectively. The function 0x1446 returns:

Next, we recover the input arguments of the function above from contract’s storage:

Finally, we can trace the entire function 0x1446 in detail:

The function should return 0x257c81b45b8f232c462e, but in reality it returns 0. So the big question is — why?

At the end of the function, we have v13 = (v12 + v9) / v6. Since both v12 and v9 are “close” to the maximum value of uint256, their sum overflows, which leads to an incorrect result. This overflow is the root cause of the incident.

In the rest of the attack transaction, the attacker repeatedly executes the same steps to drain the protocol’s ETH, incurring only minimal costs relative to the profit.

Summary

This incident highlights a critical vulnerability that was exploited after the protocol had been running for over three years without major issues, which may be partly due to the implementation being closed-source. This shows that longevity alone does not imply security, and that a lack of transparency can allow serious flaws to remain hidden until they are exploited. For this reason, we strongly recommend that projects publish their source code and undergo regular independent security audits to identify and mitigate risks before they result in real losses.

Original Attacker : https://etherscan.io/address/0xb27794423b2fd4492887098166d62de142637751

Vulnerable Contract : https://etherscan.io/address/0x3EbFd0EFC49a27fb633bd56013E4220EBC2c3C6d#tokentxns

Attack Tx : https://etherscan.io/tx/0xf867d1d7164ac9178d81696c989f65e817b8cab14850345ab3a1f99bbe547210

Analysis

This contract allows users to stake JFIN into a shared liquidity pool. When users stake, their tokens are transferred into the contract, their staked balance is recorded, and the total pool size (tvl) increases. The contract tracks a “reward per staked token” value (rtr) to distribute rewards fairly among all stakers.

Rewards primarily come from swap fees. When someone uses the bridge swap, the contract collects a small fee. Part of that fee goes to the treasury, and the rest is added to the staker rewards pool. As more fees are collected over time, rtr increases, meaning each staker earns more based on their stake amount and duration.

Users can claim rewards anytime with claimReward(). The contract calculates how much the user earned since their last update, then transfers the tokens. If the contract lacks sufficient tokens at that moment, it pays what it can and records the unpaid portion as debt (debtReward—calculated in getReward) for the user to claim later.

The getReward function already returns debtReward plus new earned rewards. The problem lies in stake. Before updating the stake data, it executes: userInfo[account].debtReward += getReward(account); But getReward(account) already includes userInfo[account].debtReward. This means the old debtReward is added again into debtReward. An attacker can call stake multiple times with small amounts to inflate the debtReward amount.

In swap, the contract calls _cutFee. This step collects a fee and adds part of it to totalReward.

When someone later calls stake, the contract updates rtr with the pending reward using: new rtr = totalReward - prevReward. After this update, prevReward becomes totalReward, and rtr becomes the new baseline. Since the new rtr is always greater than or equal to the current rtr, rewards always increase with rtr (or totalReward).

The attacker first staked an amount of JFIN, then called swap to increase totalReward. After that, they called stake 20 times with amount 1 to inflate the reward. Finally, they called claimReward to drain the manipulated reward.

Conclusion

This vulnerability exploits a critical flaw in the reward accounting logic of the staking contract. The double-counting issue in the stake function allows attackers to exponentially inflate their debtReward balance by repeatedly staking minimal amounts. Each call compounds the existing debt into the new calculation, creating artificial rewards without legitimate basis. Furthermore, calculating rewards based on totalReward instead of available funds also enables exploitation.

Incident Overview

Date: Dec 11, 2025

Platform: Binance Smart Chain (BSC)

Attacker Address: 0x24A619dCe92c38d5Fef9733f9A37050742141647

Attack Contract: 0x2E857bC277Eb049Fb4f27911e4c3498cEFC1A1dd

Prism Token Contract: 0x1284c1f20A7F0322A5E17618f764F0d3CBAcCeE9

Attack Transaction: 0xcf7cacfe38dcf090bbfcc91634de364e62ef3715fdc8d6f69e855772b0862237

Exploit Mechanics

All steps below were executed within a single transaction by the attack contract:

1. Purchased 67,750 PRISM from PancakePair using 0.01 BNB.

2. Invoked BurnSniperTokenBought on the PrismToken contract four times, reducing the Prism balance inside PancakePair from 485,826,708 PRISM to 480 PRISM.

3. Sold the 67,750 PRISM obtained in step 1 back to the PancakePair, receiving 71.5 BNB, equivalent to approximately $62,000 USD at the time of the attack.

Root Cause Analysis

The core issue lies in how the Prism protocol allows a contract to burn tokens belonging to the PancakePair.

Specifically, the BurnSniperTokensBought function permits burning tokens from an address flagged as a sniper. While this function is protected by the onlySniperManager modifier—restricting access to authorized roles—the attacker was able to exploit role assignment rather than the function logic itself.

Upon reviewing Prism protocol interaction transactions, we identified transaction

0x23879edbd3366cdc774aaa72a8484b7f7ef641f68f01345764bf44d812d042a6 This transaction shows that a SniperManager role was granted to the attack contract prior to the exploit. As a result, the attacker gained permission to call BurnSniperTokensBought and burn tokens directly from the PancakePair.

Conclusion

The BurnSniperTokenBought function itself is not inherently vulnerable; it behaves as designed.

The true root cause of the attack was operational failure by the Prism protocol operator team, who mistakenly approved a malicious contract as a SniperManager.

Additionally, BurnSniperTokenBought represents a highly centralized control mechanism, which is inappropriate for a decentralized smart contract system. Granting privileged roles that can arbitrarily burn third-party balances—especially liquidity pool addresses—introduces significant systemic risk.

On December 14, 2025, a critical vulnerability was exploited in the FutureSwapX governance system, resulting in an estimated loss of approximately $500,000. The attacker exploited the snapshot mechanism of the FST token in conjunction with the governance proposal creation flow, allowing them to use flashloaned tokens for voting power.

Overview

Attacker: 0xcd7c839c6814234601fe7719da21a980c1a8184e

Vulnerable Contracts:

• FST Token: 0x0e192d382a36de7011f795acc4391cd302003606

• Governance: 0x0a7f8161605acc552fa38fdb8ee7d8177c9ac22a

Exploit TX: 0x23c6a1e3fa409fcf17b4a6c385924a17546772ce77b314d001cbf0dab9469ba3

Exploit Analysis

The FutureSwapX governance system uses an ERC20 token (FST) with a snapshot mechanism for voting. When a proposal is created, the contract takes a snapshot of token balances to determine voting power. The vulnerability lies in the order of operations during proposal creation.

Attack Flow

The attack was executed in a single atomic transaction:

Step 1: Flashloan FST Tokens

The attacker borrowed approximately 3.6 million FST tokens via flashloan. At this point, the attacker’s balance is inflated but only temporarily.

State after this step:

• _balanceOf[attacker] = 3,600,000 FST

• Global _snapshot = 52

• Attacker’s last checkpoint = None or older snapshot

Step 2: Create Proposal - Snapshot is Taken

The attacker called createProposal() on the governance contract. This function performs two critical operations in sequence. First, it calls snapshot() on the FST token:

require(bool(_votingToken.code.size));
v48, /* uint256 */ v49 = _votingToken.snapshot().gas(msg.gas);
require(bool(v48), 0, RETURNDATASIZE());
require(MEM[64] + RETURNDATASIZE() - MEM[64] >= 32);
_proposals[_proposalCount].field5 = v49;  // Save snapshot ID for this proposal

The snapshot() function in FST token increments the global snapshot counter:

function snapshot() public payable {
    _snapshot += 1;              // 52 → 53
    emit Snapshot(_snapshot);
    return _snapshot;
}

State after snapshot:

• Global _snapshot = 53 (just incremented)

• Attacker’s last checkpoint = Still at 52 or older

• _balanceOf[attacker] = 3,600,000 FST (unchanged)

Step 3: Create Proposal - Fee Collection Triggers the Trap

Immediately after the snapshot, the governance contract calls transferFrom() to collect the 100 FST proposal stake:

MEM[MEM[64] + 36] = msg.sender;
MEM[MEM[64] + 68] = address(this);
MEM[MEM[64] + 100] = 10 ** 20;  // 100 FST stake (18 decimals)
0x12d8(132 + MEM[64], 0x23b872dd00000000000000000000000000000000000000000000000000000000, _votingToken);

The FST token’s transferFrom calls the internal transfer function:

function transferFrom(address sender, address recipient, uint256 amount) public payable {
    require(msg.data.length - 4 >= 96);
    0xa94(amount, recipient, sender);  // Internal transfer
    v0 = _SafeSub('ERC20: transfer amount exceeds allowance', amount, _allowance[sender][msg.sender]);
    0x9a8(v0, msg.sender, sender);
    return True;
}

The internal transfer function 0xa94 triggers checkpointing before modifying balances:

function 0xa94(uint256 varg0, uint256 varg1, uint256 varg2) private { 
    0xe45(varg2);  // ← Checkpoint sender BEFORE balance change
    0xe45(varg1);  // ← Checkpoint recipient BEFORE balance change
    require(address(varg2), Error('ERC20: transfer from the zero address'));
    require(address(varg1), Error('ERC20: transfer to the zero address'));
    v0 = _SafeSub('ERC20: transfer amount exceeds balance', varg0, _balanceOf[address(varg2)]);
    _balanceOf[address(varg2)] = v0;
    v1 = _SafeAdd(varg0, _balanceOf[address(varg1)]);
    _balanceOf[address(varg1)] = v1;
    emit Transfer(address(varg2), address(varg1), varg0);
    return ;
}

The checkpoint function 0xe45 is where the vulnerability materializes:

function 0xe45(address varg0) private { 
    v0 = varg0;
    if (mapping_68[v0].length) {
        assert(mapping_68[v0].length - 1 < mapping_68[v0].length);
        v1 = v2 = mapping_68[v0].field0[mapping_68[v0].length - 1];  // Get last checkpoint snapshot ID
    } else {
        v1 = 0;
    }
    if (v1 < _snapshot) {  // attacker's last (52) < current (53) = TRUE!
        mapping_68[v0].length = mapping_68[v0].length + 1;
        mapping_68[v0].field0[mapping_68[v0].length] = _snapshot;      // Record snapshot 53
        mapping_68[v0].length = mapping_68[v0].length + 1;
        mapping_68[v0].field1[mapping_68[v0].length] = _balanceOf[varg0];  // Record 3.6M FST!
    }
    return ;
}

Critical Issue: The checkpoint records the attacker’s current balance (3.6M flashloaned tokens) as their historical balance for snapshot 53, before the 100 FST fee is deducted.

State after fee collection:

• Attacker’s checkpoint for snapshot 53 = 3,600,000 FST (permanently recorded!)

• _balanceOf[attacker] = 3,599,900 FST (after 100 FST fee)

Step 4: Cast Vote with Inflated Power

The attacker immediately calls vote() on the governance contract:

function vote(uint256 proposalId, bool support) public payable {
    require(msg.data.length - 4 >= 64);
    require(proposalId < _proposalCount, Error('Nonexisting proposal'));
    v0 = v1 = block.timestamp <= _proposals[proposalId].field3;
    if (block.timestamp <= _proposals[proposalId].field3) {
        v0 = v2 = !_proposals[proposalId].field9_0_0;
    }
    require(v0, Error('vote is not open'));
    require(!_proposals[proposalId].field8[msg.sender], Error('already voted'));
    _proposals[proposalId].field8[msg.sender] = 1;
    require(bool(_votingToken.code.size));
    v3, /* uint256 */ v4 = _votingToken.balanceOfAt(msg.sender, _proposals[proposalId].field5).gas(msg.gas);
    require(bool(v3), 0, RETURNDATASIZE());
    require(MEM[64] + RETURNDATASIZE() - MEM[64] >= 32);
    if (!support) {
        v5 = _SafeAdd(_proposals[proposalId].field7, v4);
        _proposals[proposalId].field7 = v5;
    } else {
        v6 = _SafeAdd(_proposals[proposalId].field6, v4);  // v4 = 3,600,000 FST!
        _proposals[proposalId].field6 = v6;
    }
    emit VoteCasted(msg.sender, proposalId, v4, support);
}

The token’s balanceOfAt returns the recorded checkpoint balance:

function balanceOfAt(address account, uint256 snapshotId) public payable {
    require(msg.data.length - 4 >= 64);
    require(snapshotId > 0, Error('ERC20Snapshot: id is 0'));
    require(snapshotId <= _snapshot, Error('ERC20Snapshot: nonexistent id'));
    if (mapping_68[account].length) {
        // ... binary search logic to find snapshot ...
        v0 = v1 = mapping_68[account].length;
        v2 = v3 = 0;
        while (v2 < v0) {
            // ... search for matching snapshot ID ...
        }
    }
    if (v2 != mapping_68[account].length) {
        v8 = v9 = 1;
        assert(v2 < mapping_68[account].length);
        v8 = v10 = mapping_68[account].field1[v2];  // Returns recorded balance: 3,600,000 FST
    } else {
        v8 = 0;
    }
    if (!v8) {
        v8 = v11 = _balanceOf[account];  // Fallback to current balance
    }
    return v8;
}

Result: The attacker’s vote is counted with 3.6 million FST voting power.

Step 5: Return Flashloan

The attacker returns the flashloaned tokens to the flashloan provider. The snapshot balance remains permanently recorded in the token contract’s history, and the proposal passes with artificially inflated votes.

Conclusion

This attack demonstrates a critical design flaw in governance systems that use same-transaction snapshots. The vulnerability arises because:

1. Snapshot and fee collection happen atomically: The attacker can hold flashloaned tokens when the snapshot is taken.

2. Checkpointing on first touch: The token contract records the current balance as historical data on the first transfer after a new snapshot, capturing the inflated flashloan balance.

Recommendations

• Use historical snapshots: Governance proposals should reference a snapshot taken in a previous block (e.g., block.number - 1), not one created in the same transaction.

• Timelock on voting: Require a delay between proposal creation and when voting can begin.

• Minimum hold time: Implement a mechanism to verify tokens were held before the snapshot, not just at the moment of the snapshot.

Furthermore, conducting a security audit is strongly recommended for all projects, including smart contracts, backends, wallets, and dApps. Governance mechanisms in particular require careful review due to the high-value decisions they control.

Background

Trust Wallet is one of the most popular cryptocurrency wallets, offering both mobile and browser extension versions. The browser extension allows users to interact with decentralized applications (dApps) directly from their browser, storing encrypted mnemonic phrases locally.

On December 26, reports began surfacing of users having their wallets drained immediately after unlocking their Trust Wallet browser extension or importing seed phrases. Investigation revealed that version 2.68 of the extension contained malicious code that was secretly inserted during the update process.

Key Information

• Affected Version: Trust Wallet Browser Extension v2.68 only

• Safe Version: v2.69 (patched)

• Mobile users: NOT affected

• Estimated Loss: ~$7M

• Attacker’s Domain: api.metrics-trustwallet[.]com

• Hacker Wallets: https://intel.arkm.com/explorer/entity/2cd56d11-7f5b-4b00-a2e7-842663509f41

Attack Analysis

A diff comparison between v2.67 and v2.68 revealed malicious code secretly inserted into the 2.68 update. The attack flow was as follows:

Step 1: Capturing Unlock Credentials

When the user unlocks their wallet by entering their password or passkeyPassword, the malicious code intercepts and captures these credentials.

Step 2: Extracting Mnemonic Phrases

The injected code iterates through all wallets stored in the extension, triggering a GET_SEED_PHRASE request for each wallet. Using the captured password, the encrypted mnemonic is decrypted.

Step 3: Exfiltrating Data via “Analytics”

The attacker cleverly disguised the data exfiltration as analytics traffic. The decrypted mnemonic phrase is wrapped inside the request body’s errorMessage field and transmitted to the malicious server at https://api.metrics-trustwallet[.]com.

The attacker leveraged PostHog JS, an open-source analytics platform, as the data exfiltration channel. This made the malicious traffic appear as legitimate analytics data, evading basic security detection.

Conclusion

This attack demonstrates a sophisticated APT-level operation with several notable characteristics:

1. Internal Code Modification: Unlike typical supply chain attacks that inject malicious npm packages, this backdoor originated from direct modification of Trust Wallet’s internal codebase (analytics logic).

2. Clever Disguise: The attacker used the legitimate PostHog analytics library as the data exfiltration channel, making the malicious traffic blend in with normal analytics data.

3. Advanced Persistent Threat: The timeline suggests the attacker likely gained control of Trust Wallet developer devices or publishing/deployment permissions prior to December 8, indicating a well-planned, long-term operation.

4. Full User Compensation: CZ confirmed that Trust Wallet will fully cover all user losses, demonstrating the importance of having a responsible incident response policy.

Mitigation Recommendations

If you have ever installed the Trust Wallet browser extension:

1. Disconnect from Network: Immediately disconnect your device from the internet before performing any investigation.

2. Export Keys: Safely export your private key/mnemonic phrase.

3. Uninstall Extension: Remove the Trust Wallet browser extension completely.

4. Transfer Funds: After backing up credentials, transfer your funds to a new, secure wallet with a fresh seed phrase.

5. Upgrade if Continuing: If you must continue using Trust Wallet, ensure you’re on version 2.69 or later from the official Chrome Web Store.

Technical analysis and investigation credits: SlowMist Team, Trust Wallet

The Port3 Network ($PORT3) has crashed from $0.03720 to ~$0.00644—an 83% drop that decimated liquidity due to a critical oversight in their signature verification logic. A hacker exploited a classic Solidity vulnerability to mint unauthorized tokens. Below are the confirmed on-chain details:

• Targeted Protocol: Port3 Network

• Vulnerable Contract: 0xb4357054c3da8d46ed642383f03139ac7f090343

• Attacker’s Wallet: 0xb13a503da5f368e48577c87b5d5aec73d08f812e

• Attacker’s profit: Minted 1 billion $PORT3 token worths $13.07 million. Swapped 156M PORT3 for roughly 144.53 BNB ($119.48K).

Technical Deep Dive

Looking at the initiated transactions by the attacker,

The attacker calls first registerChain and registerChains. After that, call bridgeIn again. The free mint of PORT3 token was completed by utilizing bridgeIn.

Let’s take a look at how the registerChains function is implemented in the contract of the PORT3 token’s contract:

The verifySignature Flaw The core vulnerability lies inside the signature verification logic. Here is the step-by-step failure:

• The Port3 team had unset/renounced owner‘s address. This means the owner() function returns default the zero address (0x0000...0000).

• The attacker calls registerChain with an invalid (fake) signature.

• Inside verifySignature, the code calls ecrecover. In Solidity, if ecrecover fails to verify a signature, it does not revert; instead, it returns address(0).

• The code then checks if (recovered == authority).

  • recovered is 0x0 (due to the invalid signature).

  • authority is 0x0 (due to renounced ownership).

  • Result: 0x0 == 0x0 evaluates to TRUE.

Because the code failed to explicitly check that recovered != address(0), the contract accepted the fake signature as valid ownership proof. Therefore, anyone can pass this verification, and the attacker can add the token address to _state.tokenImplementations via registerChains, and then bypass detection in bridgeIn to complete _mint operation.

Conclusion

This incident is a textbook example of why developer assumptions are dangerous. The developers assumed ecrecover would only return a valid address or fail. They forgot the edge case: it returns 0 on failure.

Even if you think the owner will never be 0x0, write your code to handle that possibility. Code lives longer than current operational plans.

Auditors must look for functions that return “default values” (like 0, false, or 0x0) instead of reverting, and ensure those default values cannot be exploited.

$PORT3 didn’t die because of a sophisticated cryptographic break. It died because of a missing zero-check. In Web3, a single missing line of code is the difference between security and a $13 million loss.

Subscribe now

Stay safe!

On November 30, 2025, Yearn Finance’s yETH pool on Ethereum suffered a $9 million exploit—one of DeFi’s most capital-efficient attacks. An attacker exploited a cached storage flaw in the pool’s accounting to mint 235 septillion yETH tokens by depositing just 16 wei. The desynchronization between reset supply counters and lingering virtual balances enabled infinite minting. The attacker then swapped the tokens for LSTs like wstETH and rETH.

Yearn confirmed the bug was isolated to a custom stableswap contract—V2/V3 vaults were unaffected. The attacker laundered roughly $3 million in ETH through Tornado Cash, though ~$2.4 million was later recovered. The incident highlights critical risks in gas-optimized storage and “first deposit” logic in AMM designs.

Background on Yearn Finance

Yearn Finance is a decentralized finance (DeFi) aggregator on Ethereum. Launched in 2020, it automates and optimizes yield generation. Its flagship product—Vaults (yVaults)—lets users deposit assets that the protocol automatically allocates across lending and liquidity strategies like Aave or Compound to maximize returns. In exchange, users receive yield-bearing “yTokens” representing their pool share.

Yearn is widely respected for its robust V2 and V3 vault standards, but it also develops specialized financial products for niche markets. The yETH pool—the target of this exploit—was one such custom product. Unlike standard vaults, yETH operated as a “weighted stableswap” AMM designed to trade Liquid Staking Tokens (LSTs) like wstETH and rETH efficiently. This distinction is critical: the vulnerability existed in this custom stableswap logic, not in the protocol’s core vaults, which remained completely unaffected.

Technical Analysis of the Exploit

Incident Overview

Date: November 30, 2025

yETH Weighted Stableswap Pool: 0xccd04073f4bdc4510927ea9ba350875c3c65bf81

Exploiter Address: 0xFb63aa935Cf0a003335dCE9Cca03c4F9c0fa4779

Attack Transaction: 0x53fe7ef190c34d810c50fb66f0fc65a1ceedc10309cf4b4013d64042a0331156

Understanding the Weighted StableSwap Pool

Weighted stableswap pools (WSS) combine stableswap’s low-slippage mechanics for pegged assets with configurable per-token weights. This allows uneven liquidity allocation (e.g., 60/40 instead of 50/50). Unlike equal-weight stableswap, WSS normalizes balances using weights wi (which sum to 1), targeting specific portfolio ratios for correlated assets like LSTs (wstETH/rETH) or stablecoins with imbalances.

A standard stableswap uses a symmetric formula that blends “constant sum” (for low slippage) and “constant product” (for stability), but it enforces equal token quantities. The weighted variant modifies this by baking specific weights directly into the pricing curve. By normalizing balances based on their assigned weights, the pool delivers the same tight spreads and low slippage as a stablecoin pool—even when token quantities differ dramatically.

Yearn yETH Exploit: The Core Mechanism

The attacker executed three phases that systematically exploited vulnerabilities in the yETH stableswap to achieve unlimited token minting:

Phase 1—Collapse the Invariant: Extreme imbalanced deposits forced the Newton-Raphson solver into an unintended regime. The product term (vb_prod) became so small that iteration divergence caused the supply update to round to zero, collapsing the product accumulator Π to 0. This destroyed the weighted-stableswap invariant and caused the solver to return a massively inflated supply D that the protocol accepted without validation.

Phase 2—Drain via POL: With over-minted LP tokens and a broken pool state, the attacker called remove_liquidity(0) to restore a valid Π while keeping D inflated. Then update_rates reconciled the discrepancy by burning yETH from the staking contract’s Protocol-Owned Liquidity (POL)—not from the attacker. Repeated withdrawals using the oversized LP balance drained nearly all pool assets while offloading costs onto the protocol.

Phase 3—Infinite Mint: With the pool emptied (prev_supply = 0), the attacker re-entered the bootstrap initialization path and deposited a configuration violating A⋅Σ≥D⋅Π. The solver’s unsafe arithmetic underflowed, wrapping to the maximum uint256 value and producing approximately 2.35 × 10^56 yETH tokens.

Now let’s examine the attack transaction.

Attack Flow

The attacker executed a precision attack that exploited state desynchronization to mint tokens from nothing.

1. Flash Loan Liquidity: The attacker borrowed large amounts of liquid staking tokens (LSTs)—wstETH, rETH, and cbETH—from the yETH pool via flash loan.

   

2. State Desynchronization (The Setup): Using the flash-loaned capital, the attacker executed rapid deposits and withdrawals to manipulate the contract’s accounting. The target was a gas-saving feature: the packed_vbs (packed virtual balances) variable, which cached balance data to reduce transaction costs. By repeatedly updating this cache while simultaneously withdrawing real assets, the attacker created a critical state contradiction: the pool’s actual liquidity dropped to near zero, but the cached packed_vbs variable still held “phantom” values indicating the pool was full. This poisoned cache set the trap for the next step.

   

3. Resetting Total Supply: The attacker withdrew all assets, reducing the pool’s totalSupply to zero. In a healthy state, this should reset the pool. However, the packed_vbs cache was neither cleared nor synchronized—it retained “phantom” values from the previous state.

   

4. The Infinite Mint Trigger: With the pool’s totalSupply reset to zero, the attacker deposited just 16 wei spread across the tokens. This triggered the contract’s “initial deposit” logic—a critical initialization phase that sets the pool’s pricing curve. But due to the desynchronization, the contract calculated the invariant D using stale, inflated values from the poisoned packed_vbs cache instead of the actual 16 wei deposit. This mathematical mismatch tricked the protocol into treating the tiny deposit as equivalent to the massive “phantom” liquidity, minting 235 septillion yETH shares to the attacker.

   

5. Profit Extraction: Holding virtually unlimited yETH shares, the attacker then turned to the open market to cash out. They utilized liquidity pools on Balancer and Curve to swap the newly minted yETH for real underlying assets (like wstETH and rETH), effectively draining approximately $9 million from the ecosystem before the exploit was halted.

Conclusion

The exploit resulted from a cascade of logical and numerical failures that let the attacker desynchronize the pool’s state and trigger a catastrophic underflow.

• State Desynchronization via Numerical Instability: The protocol used internal variables—specifically the product term Π and invariant D—to track the pool’s liquidity curve. Under large relative deposits, the solver’s iteration logic became numerically unstable, causing these variables to diverge. This instability drove the product term Π to zero while the invariant D remained inflated, breaking the fundamental mathematical relationship between them.

• The “Zero-Supply” Trap: The code allowed the pool’s internal supply counter D to drop to zero while actual token balances (Protocol-Owned Liquidity) still existed. This let the attacker reach the prev_supply == 0 state—a “bootstrap” branch intended only for initial deployment—on a mature, active pool.

• The Catastrophic Underflow: The fatal blow occurred in the _calc_supply function when the contract recalculated the new liquidity. The formula val = A * Σ - D * Π assumed that A * Σ would always exceed D * Π. Because the attacker had driven Π to zero (step 1), this assumption failed. The contract used unsafe_sub (unchecked subtraction) for this operation. Instead of reverting, the subtraction underflowed, wrapping from a negative result to a near-infinite integer (2^256).

Overview

Attacker: https://bscscan.com/address/0x476954c752a6ee04b68382c97f7560040eda7309

Vulnerable Contract: https://bscscan.com/address/0x4c100d30d9c511b8bb9d1c951bbc1be489a0172f

Exploit TXs: https://bscscan.com/tx/0x1397bc7f0d284f8e2e30d0a9edd0db1f3eb0dd284c75e30d226b02bf09ad068f

Exploit Analysis

• The WXC token contract includes logic to burn WXC tokens when someone sells the token into the pool. The problem is that it burns tokens from the PancakeSwapV2 pool itself, which decreases the pool’s WXC balance.

  

• The attacker first flash-loaned WBNB, swapped it to WXC at the current price, and then swapped back to WBNB. This swap back triggered WXC’s logic to burn the pool’s WXC balance in the middle of the swap, pushing WXC’s price higher. Attacker using this to take more WBNB from pool than in a normal swap, completing the exploit.

Conclusion

When adding any logic to a token contract, especially fee or burn logic on transfers, always proceed with caution, as it may directly reduce an AMM’s pool balance during swaps and create vulnerabilities that attackers can exploit.

Furthermore, conducting a security audit is strongly recommended for all projects, even though they are smart contracts, backends, wallets, or dapps.