Debita Finance V3 — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Debita Finance V3, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 22
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 22 closed, publicly disclosed Debita Finance V3 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 Logic error, Integer overflow / underflow, Access control, Flash loan 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 Debita Finance V3
- Integer overflow / underflow findings disclosed against Debita Finance V3
- Access control findings disclosed against Debita Finance V3
- Flash loan attack findings disclosed against Debita Finance V3
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Debita Finance V3: A borrower may pay more interest that he has specified, if orders are matched by a malicious actor
Debita V3's DebitaV3Aggregator lets any caller match borrow and lend orders via matchOffersV3(), supplying up to 29 lend orders and a per-order principal amount. Because there is no minimum on lendAmountPerOrder and Solidity truncates integer division, a malicious matcher can split a high-APR lend order into many tiny slices so that each slice's weighted APR term rounds to zero while the total still counts against the borrower. By layering two matchOffersV3() calls, an attacker can force a borrower who agreed to a 5% APR to pay ~10% on roughly 2.7% of the principal, pocketing the inflated interest himself. The finding was fixed by the protocol team and confirmed in commit deaf6819f98d9d8f5ead178cd21ed80921d5f340.
Debita Finance V3: Precision loss leads to locked incentives in `DebitaIncentives::claimIncentives()`
DebitaIncentives.claimIncentives() computes each lender or borrower's incentive share for a token pair as a percentage rounded to two decimal places. Because the percentage is truncated in integer arithmetic, the remainder of the incentive pool is permanently unclaimable and the contract provides no path for the incentivizer to recover it. In a six-lender scenario against a 1000e18 pool, 4e17 (~0.04%) is locked forever, and this residue compounds as more users and more epochs participate. Sherlock accepted the issue as medium severity and the protocol team shipped a fix in the listed commit.
Debita Finance V3: Borrower can obtain principle tokens without paying collateral tokens
Debita Finance V3's order-matching aggregator computes the collateral a borrower must post using integer division that rounds down. When the principal token has more decimals than the collateral token (e.g. 18 vs 6), a borrower can set each lendOrder's lendAmountPerOrder below the rounding threshold, causing the collateral required to round to zero. Because matchOffersV3 is permissionless and can process up to 100 lend orders per transaction, and the protocol targets cheap L2 chains, an attacker can repeatedly extract principal tokens with no collateral backing, producing guaranteed losses for lenders. The protocol team confirmed and fixed the issue.
Debita Finance V3: Lend offer can be deleted multiple times
Debita Finance V3's DebitaLendOffer-Implementation.changePerpetual() permits an owner to remove an order from the factory's active registry repeatedly. When an offer in perpetual mode reaches availableAmount zero and the owner switches perpetual to false, the deletion branch removes the order and decrements activeOrdersCount — but never sets isActive to false. This lets the owner call changePerpetual again on the already-deleted order, driving activeOrdersCount below the true number of live offers and corrupting the index math in deleteOrder. The result is that other legitimate lend offers can no longer be deleted or cancelled, and whole-order principals may not be accepted, a denial of service on the lending order book. The protocol fixed it with a one-line isActive=false assignment before the deletion calls.
Debita Finance V3: Previous owner can steal unclaimed bribes from new owner of veNFTVault
Debita Finance V3's veNFT receipt system keeps a separate manager role on each vault, defaulting to the vault owner. When a user transfers the receipt (the ownership token) to a buyer, the managerAddress is not rotated, so the seller retains the powers to vote, claim bribes, reset, extend, and poke. A seller can therefore dispose of a position carrying large unclaimed bribe rewards and immediately call claimBribesMultiple(), receiving those rewards even though they no longer hold the receipt. The protocol acknowledged the issue, and the recommended fix is to override transferFrom so managerAddress follows the new owner.
Debita Finance V3: MixOracle is broken due to hardcoded position
Debita Finance V3's MixOracle values tokens that lack a direct price feed by anchoring them to a second token that carries a Pyth feed, using a DEX pool cumulative price as a TWAP basis. The defect is that setAttachedTarotPriceOracle hardcodes token1 as the mapping key for the pair, the oracle proxy, and the priced-token link, so only pools where the unsupported token happens to sort into position token1 (positions are fixed by token address ordering in UniswapV2-style pools) can be attached. Any high-liquidity pool in which the target token sorts to token0 cannot be attached, permanently preventing MixOracle from supporting that token and breaking its valuation across the lending protocol. Sherlock adjudicated this as medium severity and the team shipped a fix letting the deployer specify which token is being priced.
All reports in this group
- Debita Finance V3: Borrowers can not extend loans which has maximum duration less than 24 hoursInteger overflow/underflow$0
- Debita Finance V3: After the buyOrder is completed, the order creator does not receive the NFTLogic error$0
- Debita Finance V3: Nobody can buy the `TaxTokenReceipt` NFT from auctionLogic error$0
- Debita Finance V3: DebitaIncentives::updateFunds will exit prematurely and not update whitelisted pairs causing loss of funds to lenders and borrowersLogic error$0
- Debita Finance V3: An attacker can steal the entire borrow and lending incentive of an epoch with FLASHLOAN in a single transactionFlash loan attack$0
- Debita Finance V3: No one can sell `TaxTokensReceipts` NFT receipt to the buy orderLogic error$0
- Debita Finance V3: Lenders and borrowers can not claim liquidation token after NFT collateral auction soldLogic error$0
- Debita Finance V3: Incentive Creator's Tokens Permanently Locked in Zero-Activity EpochsLogic error$0
- Debita Finance V3: Mixed Token Price Will Be Inflated or DeflatedLogic error$0
- Debita Finance V3: Attacker will prevent lenders from canceling lend orders and block non-perpetual lend orders matching.Logic error$0
- Debita Finance V3: Loan Extension Fails Due to Unused Time CalculationLogic error$0
- Debita Finance V3: Incorrect calculation of extended loan days leads to unfair borrower feesLogic error$0
- Debita Finance V3: Interest paid for non perpetual loan during loan extension is lost when the borrower repays debtLogic error$0
- Debita Finance V3: The precision loss in the fee percentage for connecting offers results in the borrower paying less than the expected fee.Integer overflow/underflow$0
- Debita Finance V3: Auctioned `taxTokensReceipt` NFT Blocks Last Claimant Due to Insufficient FundsLogic error$0
- Debita Finance V3: Lender may loose part of the interest he has accrued if he makes his lend offer perpetual after a loan has been extended by the borrowerLogic error$0