The Wildcat Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for The Wildcat Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 9
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 9 closed, publicly disclosed The Wildcat Protocol reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Reentrancy, Integer overflow / underflow, Logic error, Front-running / MEV, Access control, 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
- Reentrancy findings disclosed against The Wildcat Protocol
- Integer overflow / underflow findings disclosed against The Wildcat Protocol
- Logic error findings disclosed against The Wildcat Protocol
- Front-running / MEV findings disclosed against The Wildcat Protocol
- Access control findings disclosed against The 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.
The Wildcat Protocol: Inconsistency across multiple repaying functions causing lender to pay extra fees
In The Wildcat Protocol, market functions differ in whether they pull tokens before or after updating the market state. In standard repayment functions, assets are pulled prior to state calculation so that pending withdrawal batches and interest accrual account for the newly available funds. Conversely, functions like `closeMarket` calculate the updated market state before transferring funds, leading to higher accrued interest and fees charged to borrowers than if transfers occurred first.
The Wildcat Protocol: User could withdraw more than supposed to, forcing last user withdraw to fail
In The Wildcat Protocol, withdrawal requests are batched and executed based on proportional interest scaling. When a market is closed, withdrawal requests within an active batch can be executed before all lenders have added their requests. A early withdrawer can execute at an outdated rate, while subsequent micro-withdrawals further alter precision and lower the batch rate, leaving insufficient unclaimed balance for remaining lenders. Consequently, the final user attempting to process their withdrawal experiences a transaction revert and permanent loss/locking of funds.
The Wildcat Protocol: Users are incentivized to not withdraw immediately after the market is closed
In The Wildcat Protocol, withdrawal requests within the same withdrawal batch share a blended execution rate. When a market is closed while an unexpired withdrawal batch exists, new withdrawal requests are bundled into the old batch, causing the effective interest rate for new withdrawers to be dragged down by earlier requests. This creates an economic disincentive for users to withdraw immediately upon market closure, forcing them to either accept a diluted rate or lock their funds until the batch expires to claim their full earned APY.
The Wildcat Protocol: `FixedTermLoanHook` looks at `block.timestamp` instead of `expiry`
In The Wildcat Protocol's `FixedTermLoanHook`, the `onQueueWithdrawal` callback validates withdrawal timing by comparing `market.fixedTermEndTime` against `block.timestamp` rather than the withdrawal batch's projected `expiry` time. Because `onQueueWithdrawal` executes when a withdrawal request is initiated rather than settled, lenders are prevented from queuing batch withdrawals prior to term expiration. This forces lenders to wait until the fixed term ends before even initiating a withdrawal, effectively extending the actual lockup period by an additional `withdrawalBatchDuration`.
The Wildcat Protocol: `AccessControlHooks` `onQueueWithdrawal()` does not check if market is hooked which could lead to unexpected errors such as temporary DoS
The `AccessControlHooks` contract in Wildcat Protocol fails to restrict calls to `onQueueWithdrawal()` to authorized, hooked market addresses. Because any caller can execute `onQueueWithdrawal()` directly with arbitrary hook data, an attacker can extract and front-run single-use or time-bound lender credential proofs against external pull providers. When the victim's legitimate transaction later executes, the proof is rendered stale or consumed, causing a denial of service on withdrawal queueing.
The Wildcat Protocol: Role providers cannot be EOAs as stated in the documentation
The Wildcat Protocol documentation states that externally owned accounts (EOAs) can be configured as role providers without needing to implement contract interface functions. However, the `AccessControlHooks` contract attempts to make a static call to `isPullProvider()` whenever a new role provider is registered via `addRoleProvider`. Because EOAs lack smart contract code, this external call fails and causes the registration transaction to revert, preventing non-deployer EOAs from being added as role providers.
All reports in this group
- The Wildcat Protocol: Role providers can bypass intended restrictions and lower expiry set by other providersAccess control$0
- The Wildcat Protocol: `FixedTermLoanHooks` allow Borrower to update Annual Interest before end of the "Fixed Term Period"Logic error$0
- The Wildcat Protocol: No lender is able to exit even after the market is closedLogic error$0