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.

Incident Overview

Date: Nov 10, 2025

Platform: Ethereum (ETH)

Attacker Address: 0xC0ffeEBABE5D496B2DDE509f9fa189C25cF29671 (white hat attacker)

Vulnerable Contract: 0x6A06707ab339BEE00C6663db17DdB422301ff5e8 (DRLVaultV3)

Attack Transaction: 0xe3eab35b288c086afa9b86a97ab93c7bb61d21b1951a156d2a8f6f5d5715c475

Exploit Flow

1. The attacker first borrowed approximately 14M USDC from the Morpho Blue vault.

2. They then heavily bought WETH using this USDC, causing the WETH price in the pool to spike sharply. As a result, the pool began reporting that WETH was extremely expensive, and USDC was worth very little WETH.

3. Next, the attacker triggered the vault’s swapToWETH function, prompting the vault to buy WETH using its USDC balance—at the now manipulated price.

4. Finally, the attacker sold the previously purchased WETH back into the pool, capturing a profit from the manipulated price difference.

Root Cause

The fundamental issue lies in how the vault computes amountOutMinimum for swaps. Instead of receiving this value from the user (off-chain) or deriving it from a trusted oracle, the contract calculates it on-chain using the current pool quote within the same transaction.

This design makes the vault’s slippage protection dependent on a manipulable reference price.

function swapToWETH(uint256 _amount) public returns (uint256 _amountOut) {
    // ... setup ...

    // FATAL FLAW: Asking the chain for the current price
    uint256 expectedAmountOut = getQuoteForUSDC(fee, _amount);

    // The contract accepts the Quoter’s price minus 0.5%
    uint256 _amountOutMinimum = (expectedAmountOut * (10000 - slippageBps)) / 10000;

    IV3SwapRouter.ExactInputSingleParams memory params = IV3SwapRouter.ExactInputSingleParams({
        tokenIn: tokenIn,
        tokenOut: WETH,
        fee: fee,
        recipient: address(this),
        amountIn: _amount,
        amountOutMinimum: _amountOutMinimum, // Uses the manipulated minimum
        sqrtPriceLimitX96: 0
    });

    _amountOut = swapRouter.exactInputSingle(params);
}

The problem is not the slippage tolerance (0.5% is normal), but that the slippage baseline is mutable. When the attacker shifts the pool price by 10%, the vault’s computed minimum also shifts by 10%, effectively nullifying all protection.

This flaw leaves both swapToUsdc and swapAllToWETH vulnerable to classic sandwich and price-manipulation attacks.

Mitigation

Effective slippage protection must rely on a price reference that is independent of any in-transaction price manipulation.

The recommended approach is to compute amountOutMinimum off-chain (on the client or backend) and pass it into the contract as a parameter. This ensures the minimum output is anchored to an external, trusted price source rather than the volatile on-chain state at execution time.

Alternatively, the contract can use a trusted oracle price (e.g., Chainlink or a time-weighted average price) to derive amountOutMinimum. By basing calculations on oracle data rather than instantaneous pool prices, the contract becomes resistant to sandwich and price manipulation attacks.

Overview

• Attacker address: 0x3feE6d8aaea76D06CF1ebEaF6B186af215F14088

• Attacker’s contract: 0xe82Fc275B0e3573115eaDCa465f85c4F96A6c631

• Vulnerable contract: 0x8c7f34436C0037742AeCf047e06fD4B27Ad01117

• Attack transaction: 0xc291d70f281dbb6976820fbc4dbb3cfcf56be7bf360f2e823f339af4161f64c6

Analysis

Here is the source code of the vulnerable contract (BorrowerOperationsV6):

You can quickly see that many of the require statements had been disabled. These checks are meant to validate the arguments passed into the function, ensuring that only proper inputs are processed. But, as you can tell, every one of them had been turned off - leaving the contract wide open to be attacked.

From there, the hacker’s remaining work was surprisingly simple. He created a contract that implemented just enough functions to masquerade as a valid TokenHolder and DEX, then invoked BorrowerOperationsV6.sell() to sell a fake loans - values returned directly from his contract. With all validation checks removed, the exploit executed flawlessly, allowing him to walk away with 20 WBNB ( 19.2 BNB after fees).

Summary

This incident highlights how even a small oversight can have serious consequences. Whether due to developer negligence or accidentally deploying test code in production, the result was a real financial loss. While the 20 BNB lost here is relatively small compared to the potential impact of such mistakes, it serves as a stark reminder that no error is too minor to ignore. Careful auditing and thorough testing before deployment are essential - continuing to review your code rigorously can prevent simple mistakes from turning into costly exploits.

On November 3, 2025, the Balancer V2 protocol was exploited, resulting in a loss of approximately $128 million across multiple pools on various networks including Ethereum, Base, Avalanche, Gnosis, Berachain, Polygon, Sonic, Arbitrum, and Optimism.

The exploit targeted the Composable Stable Pool contract, which is a type of pool that allows users to trade between different assets with stable exchange rates, such as stablecoins (DAI, USDC, USDT, etc.) or correlated assets like wrapped staked ETH (wstETH), StakeWise staked ETH (osETH), and ETH (WETH).

Key Information

• Exploiter Address: https://etherscan.io/address/0x506d1f9efe24f0d47853adca907eb8d89ae03207

• Attack Transaction (example): https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

• Fund Withdrawal Transaction: https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

Understanding the Composable Stable Pool

The ComposableStablePool contract has a liquidity provider token (BPT) that represents the pool’s liquidity. This token is registered in the pool’s balances along with other underlying tokens so that users can add or remove liquidity by swapping BPT with underlying tokens just like normal tokens. These operations are called join and exit swaps.

In order to handle token transfers efficiently, instead of transferring tokens directly for each swap, the pool uses a delta calculation to track the changes in the pool’s balances. These deltas are then used to update the pool’s balances after each swap. At the end of the swap, the vault collects all deltas and performs the actual token transfers. Using this feature, the attacker can temporarily use the pool’s balances and perform a swap to make some profit and pay back to the pool without the need for explicitly doing token flashloans.

Now, let’s take a look at the attack transactions.

Exploit Analysis

Look at the transaction where the attacker withdrew a huge amount of tokens such as WETH, osETH, wstETH, etc. out of the pool. However, this transaction is not the actual attack transaction.

Take a deeper look, we can see that these tokens have been recorded as internal balances of the attacker in the vault contract. So, the real attack transaction must have been done prior to this transaction. The attack had been split into multiple transactions to avoid MEV bots front-running the attack.

And the previous transaction, that records the internal balances for the attacker in this pool is the following one:

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

Look at this transaction, we can see a list of calls to the attacker’s contract 0x679B362B9f38BE63FbD4A499413141A997eb381e with the method 0x524c9e20. After that, the attacker performed a batch of swaps between tokens inside the pool (including the BPT token).

At the end of the batchSwap call, we can see that the internal balances of the attacker have been increased by a large amount for all tokens inside the pool.

So now, we need to figure out how the attacker made profit from these swaps. To understand the attack, let’s trace through the balances of these tokens inside the pool for every swap in the batchSwap call. Before the batchSwap call, the balance of tokens inside the pool were as follows:

As mentioned above, the pool saves the BPT share token of the pool as a normal token in its balances array. So, the attacker can swap the BPT token with other tokens inside the pool just like normal tokens.

At the beginning of the batchSwap call, we can see a series of swaps from the BPT token to the WETH and osETH tokens. This means the attacker was trying to drain the balance of both underlying tokens of the pool. This is the result at the end of these swaps:

So, we can clearly see that the attacker was trying to precisely adjust the balance of the osETH tokens, setting it to 18 and then attempting to swap out 17 wei of osETH. Why was the number 17 chosen? To understand this, we need to look at the implementation of the onSwap function.

Trace through the logic of the onSwap function, we come up with the _swapGivenOut function, this function is responsible for calculating the amount of tokens to be swapped in for a given amount of tokens to be swapped out. In this case, the attacker was trying to swap out 17 wei of osETH, so the function will calculate the amount of WETH to be swapped in.

In the _swapGivenOut function, the balances of tokens in the pool are upscaled using the scaling factors of the tokens. These numbers represent the exchange rates of the tokens in the external market.

Both swap amount and balances are upscaled using these scaling factors. After the upscaleArray function call, the balances of the tokens in the pool are updated as follows:

However, the swap amount is unchanged after the _upscale call. This might be the reason why the attacker chose the number of 17 for the swap amount. We can guess that there is some rounding error here, in the _upscale implementation.

Look at the implementation of the _upscale function, we can see that the amount is rounding down after multiplying by the scaling factor.

In this case, we have the following calculation:

17 * 1,058,132,408,689,971,699 / 10**18 = 17.98825094772952 // Rounded down to 17
// the loss is approximately 0.98825094772952 / 17 ~= 5.81%

Because the amount of token in is calculated based on the amount out provided by the attacker as follows:

swapRequest.amount = _upscale(swapRequest.amount, scalingFactors[indexOut]);
uint256 amountIn = _onSwapGivenOut(swapRequest, balances, indexIn, indexOut);

So, the pool will incorrectly calculate the required amount of token in that favors the attacker for each swap based on the following formula from the documentation of Balancer:

Solving this equation using the Newton-Raphson method, we can calculate the amount of input token needed to swap out a given amount of output token, amplification parameter (A), balances of the tokens in the pool and the invariant (D) of the pool.

Using a series of these swaps, the attacker can gradually drain all of the underlying tokens of the pool and make a profit.

Conclusion

This attack is an interesting example of how small rounding errors can lead to significant losses in DeFi protocols. The _upscale function, instead of rounding up to benefit the pool, rounds down, which favors the attacker. According to the comments in the code, this issue had been acknowledged, but the development team skipped fixing it because they underestimated the impact of the rounding error.

This incident shows that even a well-established protocol like Balancer, which has been around for a while and has undergone multiple audits, can still be exploited by small rounding errors. It highlights the importance of regular security audits and thorough testing of complex logic and formulas in DeFi protocols.