Flash Loan Attack Vector Analysis: PancakeSwap AMM

Executive Summary:

PancakeSwap, the leading decentralized exchange on Binance Smart Chain (BSC), has recently expanded to Ethereum and multiple Layer 2 rollups. While its core automated market maker (AMM) contracts are well-tested, rapid cross-chain deployments create new attack surfaces, particularly for flash loan manipulation. Our analysis identifies four primary vectors that could be exploited by an adversary with a large, low-cost flash loan.

Overall risk is classified as high (7/10). The protocol's reward distribution contracts and cross-chain bridge interactions present exploitable pathways that could result in significant short-term capital losses or long-term tokenomics distortion.

Attack Vectors:

1. Flash-Loan Price Oracle Manipulation (TWAP/Spot):

- Attackers can use flash loans to manipulate PancakeSwap's on-chain price feeds.

- By performing a series of swaps within a time-weighted average price (TWAP) window, they can skew prices and then unwind the position before the window closes.

- This can lead to arbitrage against downstream protocols, forced liquidation of user positions, and reputational damage.

2. Flash-Loan Liquidity Drain via "Sandwich" on Low-Liquidity Pairs:

- For newly created or low-TVL pairs, attackers can flash loan a large amount of a token, add liquidity, manipulate the price, and then remove the liquidity before the transaction ends.

- They profit from the price impact and fee capture while temporarily distorting pool reserves.

- This attack targets pairs with TVL below $10M and can cause short-term price distortion affecting oracle-dependent contracts.

3. Reward-Harvest Manipulation (MasterChef / Staking Pools):

- PancakeSwap's MasterChef distributes CAKE rewards based on LP tokens staked.

- Attackers can flash loan LP tokens, stake them for a single block, claim the proportional rewards, and then instantly return the LP tokens.

- This allows them to harvest a disproportionate share of rewards without long-term commitment, inflating the CAKE supply and diluting legitimate stakers' yields.

4. Cross-Chain Bridge Re-Entrancy via Flash Loans:

- PancakeSwap's L2 deployments interact with bridge contracts (e.g., LayerZero, Wormhole) to move liquidity across chains.

- Attackers can trigger a re-entrancy by exploiting the bridge's finalizeDeposit callback, executing a flash loan swap before the bridge state is fully settled.

- This allows price manipulation on the destination chain, potential loss of assets locked in the bridge, and systemic risk across multiple L2s.

Recommendations:

1. Introduce a "Flash-Loan Guard" on reward-minting functions (deposit, withdraw):

- Prevents instantaneous staking/unstaking of flash-loaned LP tokens that yield per-block rewards.

- Implement a minimum-stake-duration (e.g., 1-2 blocks) before rewards can be claimed.

- Store the last reward block per user and enforce the user's lastRewardBlock before reward claim.

- Emit StakeLocked events for transparency.

2. Enforce a minimum TWAP window length and price-change caps:

- Reduces the ability to skew price within a short window.

- Require a TWAP calculation window of at least 30 minutes for any external contract reads.

- Add a price-change limiter to ignore price changes exceeding 5% within a single block for TWAP calculations.

3. Add a "Liquidity-Addition Cool-down" for low-TVL pairs:

- Implement a cooldown period before allowing liquidity addition on newly created or low-TVL pairs.

- This prevents rapid flipping of prices and reduces the feasibility of sandwich attacks.

4. Implement re-entrancy safeguards:

- Although currently using the nonReentrant modifier from OpenZeppelin, re-evaluate the bridge callback mechanism to ensure it cannot be exploited.

- Consider additional checks or alternative re-entrancy protection mechanisms for bridge interactions.

By addressing these identified attack vectors and implementing the recommended mitigations, PancakeSwap can significantly enhance its resilience against flash loan-based attacks, ultimately safeguarding user assets and maintaining the integrity of its AMM protocol.