Teller Lender Groups Update Audit — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Teller Lender Groups Update Audit, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 5
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 5 closed, publicly disclosed Teller Lender Groups Update Audit 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 Reentrancy, Logic error, 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
- Reentrancy findings disclosed against Teller Lender Groups Update Audit
- Logic error findings disclosed against Teller Lender Groups Update Audit
- Integer overflow / underflow findings disclosed against Teller Lender Groups Update Audit
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Teller Lender Groups Update Audit: ERC20.approve Used Instead of Safe Approvals, Causing Pool Failures with Some ERC20s
In Teller's LenderCommitmentGroup_Smart contract, the acceptFundsForAcceptBid function approves the TELLER_V2 contract to spend the principal token using a bare ERC20.approve call that assumes the token returns a boolean. On deployments holding tokens such as USDT and USDC, which do not return a value on approve, the call reverts and the borrow-acceptance flow fails, effectively breaking the lending pool for the protocol's stated supported tokens. The team fixed it by switching to OpenZeppelin's safeApprove, which correctly handles non-standard ERC20 return behavior.
Teller Lender Groups Update Audit: Lender group members can be prevented from burning their shares forever
Teller's lender-commitment-group shares contract implements a two-step withdrawal flow (`prepareSharesForBurn` then `burnSharesToWithdrawEarnings`) with a cooldown to block sandwich attacks. The cooldown is reset in the `_afterTokenTransfer` hook on every share transfer, intended to stop members from pre-staging shares. Because OpenZeppelin ERC20 v4.8's `transferFrom` does not reject zero-amount transfers, an adversary can repeatedly send 0-value transfers to a victim to trigger the hook and perpetually reset the victim's withdrawal countdown, indefinitely locking their funds in the contract unless a bribe is paid.
Teller Lender Groups Update Audit: Not updating state before making custom external call can cause borrower's to loose assets due to re-entrancy
In Teller's repayment flow, `_repayLoan` updates the loan's repayment bookkeeping (totalRepaid principal/interest and lastRepaidTimestamp) only after making the external `repayLoanCallback` call to the configured `loanRepaymentListener`. The callback runs under a 80000-gas cap inside a try/catch, so it normally cannot halt repayments, but a malicious lender implementing the listener interface is still able to reenter `TellerV2` during that window. If the loan has passed its default timestamp, the lender reenters and calls `lenderCloseLoan`, seizing the borrower's collateral even though the borrower has just made a valid repayment. Net effect: the borrower loses both the repayment amount and their collateral. The protocol team fixed the issue by updating state before the listener callback, per PR #81.
Teller Lender Groups Update Audit: Users can lower the interest rate by dividing a loan into multiple smaller loans
Teller's LenderCommitmentGroup_Smart pool prices borrowing APR off the utilization ratio computed to include the newly borrowed principal (getPoolUtilizationRatio adds activeLoansAmountDelta onto the current outstanding principal before dividing by pool value). Because the rate is set from this end-state utilization rather than a marginal or midpoint value, a borrower can split a large desired loan into many small sequential loans, paying a lower APR on each increment, which yields a blended rate far below the single-tranche rate for the same total principal. The report demonstrates that a $10,000 single loan at ~6% APR can instead be split into ten $1,000 loans averaging ~4.2%, an unfair economic advantage shifting yield away from lenders. The fix is to evaluate utilization at the midpoint of the proposed delta rather than the post-borrow end value.
Teller Lender Groups Update Audit: Repayer can brick lending functionality of `LenderCommitmentGroup_Smart` by repaying excess
A Sherlock-contest Medium finding in Teller's LenderCommitmentGroup_Smart showed that the accounting function getTotalPrincipalTokensOutstandingInActiveLoans returns totalPrincipalTokensLended minus totalPrincipalTokensRepaid with no underflow guard. Because borrowers can repay more than the minimum through TellerV2's repayLoan, an attacker can repay slightly more than the outstanding principal, driving totalPrincipalTokensRepaid above totalPrincipalTokensLended. Since this outstanding-principal view is invoked before every lending operation, the underflow reverts and bricks the group's lending functionality. The protocol team fixed the issue by returning zero when repaid principal exceeds lended principal.