Teller Finance — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Teller Finance, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 27
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 27 closed, publicly disclosed Teller Finance 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, Front-running / MEV, Flash loan attack, Integer overflow / underflow, 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 Teller Finance
- Front-running / MEV findings disclosed against Teller Finance
- Flash loan attack findings disclosed against Teller Finance
- Integer overflow / underflow findings disclosed against Teller Finance
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Teller Finance: `_repayLoan` now allows for overpaying of loan and could cause DoS within `LenderCommitmentGroup_Smart`
In Teller Finance's loan repayment path, when a borrower sends more than the amount owed on a bid, `_repayLoan` clamps its local `paymentAmount` variable to `_owedAmount` and marks the bid PAID, but it forwards the original, over-funded `_payment` memory struct unchanged to `_sendOrEscrowFunds`. As a result the surplus principal is still transferred or escrowed, letting a borrower overpay the loan. In `LenderCommitmentGroup_Smart`, overpayment inflates `totalPrincipalTokensRepaid` beyond `totalPrincipalTokensLended`, so `getTotalPrincipalTokensOutstandingInActiveLoans` underflows and reverts; because that view is consulted on every borrow attempt, the commitment group is permanently denied new borrows. The issue was acknowledged by the protocol and upheld as a valid medium by the judge, though no end-to-end PoC was provided and the only identified trigger path is at TellerV2.sol lines 680-708.
Teller Finance: `_sendOrEscrowFunds` will brick LCG funds causing insolvency
In Teller Finance's loan repayment and liquidation flow, `_sendOrEscrowFunds` wraps `transferFrom` in a try/catch: if the token transfer reverts, the catch branch deposits the payment into the EscrowVault so the repay call still succeeds. For LenderCommitmentGroup (LCG) pools this fallback is broken because LCG has no withdraw function, so the tokens are permanently stranded inside EscrowVault while the repayment callback still inflates the share price. The result is a pool that appears to have received capital it never actually got, leaving it economically insolvent so the last LPs cannot redeem their shares. The protocol team fixed the bug by adding a withdraw function to LCG, which the Lead Senior Watson signed off on.
Teller Finance: `burnSharesToWithdrawEarnings` burns before math, causing the share value to increase
In Teller Finance's LenderCommitmentGroup_Smart contract, the burnSharesToWithdrawEarnings function destroys a user's pool shares before computing the current principal-per-share exchange rate. Burning first reduces the share supply while pool principal stays constant, so the post-burn rate is inflated and the withdrawn share amount maps to more principal than the saver is entitled to. A worked example shows a user holding 20% of shares cashing out 25% of the pool's principal, letting users drain more than a fair share and driving the pool toward insolvency. The protocol fixed the ordering by computing the principal amount before burning the shares.
Teller Finance: Lender may not be able to close loan or get back lending token.
Teller V2's loan NFT claiming mechanism overwrites the bid's stored lender address with the sentinel constant USING_LENDER_MANAGER, routing lender checks through the NFT's ownership. This breaks lender functions that still compare the caller against bid.lender directly, so a lender who claims the loan NFT can no longer close a defaulted loan because that equality check fails. Independently, for paid or liquidated bids, `_sendOrEscrowFunds` resolves the lender by NFT ownership via `getLoanLender`, meaning that if the NFT is transferred, gifted or stolen, its new owner receives the loan principal and interest instead of the original lender — a direct loss of user funds.
Teller Finance: Utilization math should include `liquidityThresholdPercent`
Teller Finance's LenderCommitmentGroup_Smart contract derives pool utilization from outstanding principal divided by total pool estimated value, without accounting for the liquidityThresholdPercent cap that bounds how much of the pool's assets can actually be borrowed. Because borrowers cannot push utilization above the threshold, the computed ratio and the interest rate derived from it in getMinInterestRate() always read lower than the true proportion of deployable capital, suppressing APR precisely in riskier markets where the threshold is set low. This underpricing of utilization reduces the interest revenue LPs earn. The finding was confirmed by the protocol team, fixed by scaling the utilization denominator by the threshold, and signed off by the Lead Senior Watson.
Teller Finance: `FlashRolloverLoan_G5` will fail for `LenderCommitmentGroup_Smart` due to `CollateralManager` pulling collateral from `FlashRolloverLoan_G5`
Teller Finance's flash rollover extension, FlashRolloverLoan_G5, fails whenever it processes a LenderCommitmentGroup_Smart loan because it hands the wrong borrower identity to the SmartCommitmentForwarder. The rollover contract invokes acceptCommitmentWithRecipient() expecting the forwarder to read the borrower from the trailing 20 bytes of the recipient argument, but the forwarder instead binds msg.sender (the rollover contract itself) as the borrower. As a result TellerV2::submitBid() registers FlashRolloverLoan_G5 as the borrower, and CollateralManager tries to pull collateral from that contract, which neither approves the transfer nor holds the assets, so every such rollover reverts. The outcome is a deterministic denial of service that permanently freezes users' ability to roll over LenderCommitmentGroup_Smart positions rather than a loss of funds. The protocol patched it by pulling collateral from the actual borrower and approving the CollateralManager in _acceptCommitment(), with the Lead Senior Watson signing off on the fix.
All reports in this group
- Teller Finance: liquidateDefaultedLoanWithIncentive sends the collateral to the wrong accountLogic error$0
- Teller Finance: `LenderCommitmentGroup_Smart_test::addPrincipalToCommitmentGroup/burnSharesToWithdrawEarnings()` are vulnerable to slippage attacksFront-running / MEV$0
- Teller Finance: Malicious borrower can pay each payment and make its own loan default 1 month laterLogic error$0
- Teller Finance: Interest rate in `LenderCommitmentGroup_Smart` may be easily manipulated by depositing, taking a loan and withdrawingLogic error$0
- Teller Finance: Borrowers can brick the commitment group poolLogic error$0
- Teller Finance: `FlashRolloverLoan_G5` will not work for certain tokens due to not setting the approval to `0` after repaying a loanFlash loan attack$0
- Teller Finance: Not transferring collateral when submitting bids allows malicious users to create honeypot-style attacksLogic error$0
- Teller Finance: Drained lender due to `LenderCommitmentGroup_Smart::acceptFundsForAcceptBid()` `_collateralAmount` by `STANDARD_EXPANSION_FACTOR` multiplicationLogic error$0
- Teller Finance: Users can bypass auction mechanism for `LenderCommitmentGroup_Smart` liquidation mechanism for loans that are close to end of loanLogic error$0
- Teller Finance: The cycle payment due may span over approx. 2 cycles and block the borrower from payingLogic error$0
- Teller Finance: Incorrect selector in `FlashRolloverLoan_G5::_acceptCommitment()` does not match `SmartCommitmentForwarder::acceptCommitmentWithRecipient()`Logic error$0
- Teller Finance: `LenderCommitmentGroup` pools will have incorrect exchange rate when fee-on-transfer tokens are usedLogic error$0
- Teller Finance: `LenderCommitmentGroup_Smart.sol` cannot deploy pools with non-string symbol() ERC20s.Logic error$0
- Teller Finance: `LenderCommitmentGroup_Smart` picks the wrong Uniswap price, allowing borrowing at a discount by swapping before withdrawingLogic error$0
- Teller Finance: Borrowers can surpass `liquidityThresholdPercent` and borrow to near 100% of the principalLogic error$0
- Teller Finance: `LenderCommitmentGroup_Smart` does not use `mulDiv` when converting between token and share amounts, possibly leading to DoS or loss of fundsInteger overflow/underflow$0
- Teller Finance: Anyone can steal pool shares from lender group if no-revert-on-failure tokens are usedLogic error$0
- Teller Finance: If `repayLoanCallback` address doesn't implement `repayLoanCallback` try/catch won't go into the catch and will revert the txLogic error$0
- Teller Finance: Performing a direct multiplication in `_getPriceFromSqrtX96` will overflow for some uniswap poolsLogic error$0
- Teller Finance: APRs are lower than they shouldLogic error$0
- Teller Finance: liquidateDefaultedLoanWithIncentive can be gamed to avoid paying loans interestLogic error$0