Centrifuge — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Centrifuge, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 8
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 8 closed, publicly disclosed Centrifuge reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Bridge exploit, Integer overflow / underflow, Access control, Governance attack, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Centrifuge
- Bridge exploit findings disclosed against Centrifuge
- Integer overflow / underflow findings disclosed against Centrifuge
- Access control findings disclosed against Centrifuge
- Governance attack findings disclosed against Centrifuge
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Centrifuge: `LiquidityPool::requestRedeemWithPermit` transaction can be front run with the different liquidity pool
In Centrifuge's liquidity pool system, `requestRedeemWithPermit` accepts an EIP-2612 permit signature intended to approve tranche token transfers to the `InvestmentManager`. Because the permit signature target parameters are scoped only to the tranche token and `InvestmentManager` rather than bound to a specific liquidity pool instance, an attacker can extract the user's valid permit signature from the mempool. The attacker can then front-run the victim's transaction by executing `requestRedeemWithPermit` against an alternate liquidity pool that utilizes the same tranche token. This results in the user's intended redemption reverting and forces them into an unwanted redemption tranche currency unless canceled before epoch settlement.
Centrifuge: Cached `DOMAIN_SEPARATOR` is incorrect for tranche tokens potentially breaking permit integrations
Centrifuge tranche tokens cached their EIP-712 domain separator inside the contract constructor before the token's name string was populated by the factory. Because the initial calculation incorporated an empty token name, any EIP-2612 permit calls constructed with the actual token metadata failed EECD signature validation on the same chain. This permanently broke signature-based approvals for tranche tokens unless deployed across alternate chain IDs where dynamic recalculation occurred.
Centrifuge: `onlyCentrifugeChainOrigin()` can't require `msg.sender` equal `axelarGateway`
Centrifuge's `AxelarRouter` implementation contained a flawed modifier `onlyCentrifugeChainOrigin` that strictly required `msg.sender` to be the `AxelarGateway` contract. However, Axelar's cross-chain message architecture does not invoke destination contract `execute()` functions directly from the Gateway contract; execution is typically triggered by external relayers after payload approval. Because of this incorrect access check, legitimate incoming cross-chain messages from Centrifuge Chain could never be executed on the destination EVM chain, resulting in a complete denial of service for cross-chain communications.
Centrifuge: ```trancheTokenAmount``` should be rounded UP when proceeding to a withdrawal or previewing a withdrawal
In Centrifuge's InvestmentManager contract, `_calculateTrancheTokenAmount` defaults to rounding down when converting currency amounts into tranche tokens during `processWithdraw` and `previewWithdraw`. Under EIP-4626 specifications, calculating required shares/tokens to burn for a given asset amount must round up in favor of the vault. Rounding down allows users to burn slightly fewer tranche tokens than mathematically required for their requested withdrawal, leading to minor share leakage and potential accounting discrepancies in redemption limits.
Centrifuge: Investors claiming their `maxDeposit` by using the `LiquidityPool.deposit()` will cause other users to be unable to claim their `maxDeposit`/`maxMint`
In Centrifuge's ERC4626 liquidity pools, user deposit requests across different epochs calculate an average share price upon withdrawal in `InvestmentManager.processDeposit()`. Due to precision and rounding differences when converting currency amounts back to tranche tokens using the averaged price, a user claiming their maximum allowed deposit can receive slightly more shares than originally minted into escrow for them. This rounding imbalance drains extra tokens from the shared Escrow contract, leaving it with insufficient balance and causing subsequent deposit or mint redemptions for other investors to revert.
Centrifuge: You can deposit really small amount for other users to DoS them
A permissioning flaw in Centrifuge's LiquidityPool contract allowed unauthenticated callers to execute secondary deposit and mint processing functions on behalf of arbitrary receiver accounts. Because processing functions consume already-committed pending request amounts without transferring new tokens, an attacker could front-run a victim's attempt to finalize their deposit by executing a partial deposit of just 1 wei. When the victim subsequently attempted to process their full transaction, the remaining asset balance was insufficient, triggering a revert and causing a denial-of-service for legitimate liquidity providers.