Wildcat Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Wildcat Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 16
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 16 closed, publicly disclosed Wildcat Protocol 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, Reentrancy, Front-running / MEV, Access control, Oracle manipulation, across EVM-Solidity, Move. 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 Wildcat Protocol
- Reentrancy findings disclosed against Wildcat Protocol
- Front-running / MEV findings disclosed against Wildcat Protocol
- Access control findings disclosed against Wildcat Protocol
- Oracle manipulation findings disclosed against Wildcat Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Wildcat Protocol: `collectFees()` updates delinquency wrongly as `_writeState()` is called before assets are transferred
In Wildcat Protocol's market contracts, calling fee collection improperly updates market delinquency status due to an incorrect execution order. The collectFees function records state changes before transferring accrued protocol fees to the fee recipient. During state writing, market asset balances are queried via balanceOf to determine if the market is delinquent. Because fee assets have not yet been transferred out, totalAssets reports a higher balance than will remain in the contract, causing delinquent markets to be incorrectly marked as healthy and suppressing required delinquency fees.
Wildcat Protocol: Removing markets from `WildcatArchController` gives lenders immunity from sanctions
In the Wildcat Protocol, the WildcatSanctionsSentinel contract restricts calls to createEscrow by verifying if the caller is registered in WildcatArchController. When a market contract is unlinked via removeMarket, it loses its registered market status while remaining functional. If a lender in an unlinked market gets flagged by sanctions, operations like nukeFromOrbit and executeWithdrawal fail because createEscrow reverts on the authorization check. This prevents the market from isolating funds into sanction escrow accounts, leaving sanctioned addresses able to interact with unlinked markets.
Wildcat Protocol: Lenders can escape the blacklisting of their accounts because they can move their MarketTokens to different accounts and gain the `WithdrawOnly` Role on any account they want
Wildcat Protocol suffered from an access control vulnerability that allowed sanctioned lenders to circumvent market freezes and withdraw their capital. Before an account's sanction status was finalized in a market, the lender could transfer their market tokens to clean, secondary addresses. The lender could then call a permissionless authorization update function in the controller contract, which incorrectly assigned a withdrawal-only role to any address not explicitly listed as an authorized lender. By granting withdrawal capabilities to their secondary addresses without borrower approval, sanctioned users could successfully process withdrawal requests and extract their funds.
Wildcat Protocol: Borrower can drain all funds of a sanctioned lender
A parameter ordering flaw in Wildcat Protocol's sanction handling logic allows borrowers to steal funds from sanctioned lenders. When blocking a sanctioned account via `nukeFromOrbit()`, `_blockAccount()` passes arguments to `WildcatSanctionsSentinel.createEscrow()` in a different sequence than expected by the escrow factory. This parameter reversal causes the escrow contract to check the borrower's address against sanctions lists instead of the sanctioned lender. As a result, the borrower can trigger `releaseEscrow()`, receive the lender's escrowed market tokens, and withdraw the underlying collateral.
Wildcat Protocol: `create2WithStoredInitCode()` does not revert if contract deployment failed
In Wildcat Protocol, market creation relies on inline assembly using CREATE2 via LibStoredInitCode.create2WithStoredInitCode(). When deployment of a WildcatMarket contract reverts during initialization—for instance, due to invalid protocol fee parameters or non-standard token assets—the CREATE2 opcode returns the zero address instead of reverting the surrounding transaction. Because the library fails to check for address(0), execution continues normally in WildcatMarketController. As a result, users attempting market deployment incur lost origination fees for non-existent contracts, empty addresses are permanently registered in the protocol architecture controller, and future deployment attempts with identical market configuration parameters are permanently locked out.
Wildcat Protocol: `codehash` check in factory contracts does not account for non-empty addresses
Wildcat Protocol's factory and sentinel contracts verify contract deployment status by checking if an target address's `.codehash` is non-zero. However, per EIP-1052, accounts without deployed code that hold an ETH balance return `keccak256("")` rather than `bytes32(0)`. An attacker can exploit this by sending 1 wei to predicted CREATE2 addresses for market controllers, markets, or sanction escrows before deployment. This permanently prevents borrowers from deploying market controllers or causes protocol funds intended for sanctioned users to be sent to undeployed addresses, resulting in unrecoverable funds.
All reports in this group
- Wildcat Protocol: When a batch of withdrawals expires, that batch is often underpaid their owed interestLogic error$0
- Wildcat Protocol: `setAnnualInterestBips()` can be abused to keep a market's reserve ratio at 90%Logic error$0
- Wildcat Protocol: When `withdrawalBatchDuration` is set to zero lenders can withdraw more then allocated to a batchReentrancy$0
- Wildcat Protocol: Borrower has no way to update `maxTotalSupply` of `market` or close market.Access control$0
- Wildcat Protocol: Function `WildcatMarketController.setAnnualInterestBips` allows for values outside the factory rangeLogic error$0
- Wildcat Protocol: Blocked accounts keep earning interest contrary to the WhitePaperOracle manipulation$0
- Wildcat Protocol: Calculation for lender withdrawals in `_applyWithdrawalBatchPayment()` should not round upInteger overflow/underflow$0
- Wildcat Protocol: Pending withdrawal batch debt cannot be paid by the borrower until the cycle endsLogic error$0
- Wildcat Protocol: Return values of `transfer()`/`transferFrom()` not checked and unsafe usageLogic error$0
- Wildcat Protocol: Protocol markets are incompatible with rebasing tokensLogic error$0