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
- 8
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 8 closed, publicly disclosed Teller Finance 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, 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
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: The cycle payment due may span over approx. 2 cycles and block the borrower from paying
This Sherlock medium-severity finding describes a logic error in Teller Finance's EMI loan repayment accounting. When a borrower makes a cycle payment early (before the next cycle boundary), the `calculateAmountOwed` function prorates the owed amount linearly across the elapsed time since `lastRepaidTimestamp`, causing the minimum payment for the current cycle to be computed as nearly two full cycles rather than one. As a result, a borrower attempting to make their regular monthly payment on day 58 (having already paid for month one on day 1) gets the `PaymentNotMinimum` revert and is blocked from paying, risking liquidation and loss of collateral. The protocol team acknowledged the issue as a design oddity, shipped a fix in TellerV2, and the Lead Senior Watson signed off on the resolution.
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: If `repayLoanCallback` address doesn't implement `repayLoanCallback` try/catch won't go into the catch and will revert the tx
An attacker (acting as a lender) sets an untrusted `loanRepaymentListener` contract that does not implement the `repayLoanCallback` function. Because Solidity's `try/catch` only captures reverts that occur inside the target contract's execution, a call to a non-existent function selector reverts at the call site itself, so the `catch` block never fires and the whole repayment transaction reverts. This lets a malicious lender permanently block borrowers from repaying, driving their loans into default and seizing collateral. The protocol team fixed it by routing the callback through a trusted wrapper contract.
Teller Finance: Interest rate in `LenderCommitmentGroup_Smart` may be easily manipulated by depositing, taking a loan and withdrawing
Teller's LenderCommitmentGroup_Smart derives borrower interest directly from pool utilization, computed from the most-recent deposit, borrow and withdrawal values with no intra-period constraints. Because there is no delay between depositing, borrowing, and withdrawing, an attacker can inflate total committed principal to depress the utilization ratio, take out a loan at an artificially low rate, and then redeem the shares corresponding to the borrowed principal. This yields below-market borrowing with zero effective risk, reducing LP yield. The issue was verified, fixed via a withdrawal/share-burn delay, and acknowledged as a duplicate of issues #44 and #48 with the same root cause and remedy.
Teller Finance: Users can bypass auction mechanism for `LenderCommitmentGroup_Smart` liquidation mechanism for loans that are close to end of loan
LenderCommitmentGroup_Smart uses a Dutch-style auction where liquidators of defaulted loans must transfer between 0x and 8x of the owed amount, administered via liquidateDefaultedLoanWithIncentive with a minimum tokenAmountDifference. For loans whose end-of-loan date has effectively been reached, calculateNextDueDate caps the computed due date at endOfLoan, so repaying the loan does not advance the default timestamp and the loan remains classified as defaulted. An attacker can exploit this by first repaying the full collateral via repayLoanFullWithoutCollateralWithdraw (zeroing amountOwed) and then liquidating with a zero tokenAmountDifference, paying only 1x the owed amount rather than the up-to-8x auction premium. Because anyone can repay a loan, this becomes a race around high-value collateral, letting arbitrary users capture liquidation collateral below the intended auction price.
Teller Finance: `LenderCommitmentGroup_Smart.sol` cannot deploy pools with non-string symbol() ERC20s.
Teller Finance's `LenderCommitmentGroup_Smart.sol` fetches the metdata `symbol()` of both the principal and collateral ERC20 tokens during pool initialization, but assumes the function returns `string`. Per the ERC20 standard, `symbol()` is optional and some well-known tokens (e.g., MKR) return `bytes32` instead, so pool creation would revert for those tokens. The contest scope explicitly required support for any standard token compatible with Uniswap V3, which includes MKR. The issue was classified as medium severity by Sherlock, fixed via a try-catch approach in a pull request, and signed off by the Lead Senior Watson.
All reports in this group
- Teller Finance: Drained lender due to `LenderCommitmentGroup_Smart::acceptFundsForAcceptBid()` `_collateralAmount` by `STANDARD_EXPANSION_FACTOR` multiplicationLogic error$0
- Teller Finance: Incorrect selector in `FlashRolloverLoan_G5::_acceptCommitment()` does not match `SmartCommitmentForwarder::acceptCommitmentWithRecipient()`Logic error$0