Reentrancy vulnerabilities in disclosed bug bounty reports

Reentrancy lets an external call re-enter a contract before its own state has settled, so the same balance or position can be spent twice.

Reports indexed
72
Total paid
$1.2M
Critical
1
Largest payout
$1.2M

Reentrancy is the oldest bug class in smart contract security and it keeps paying out because the shape of it changes faster than the mitigations do. The core mechanic never moves: a contract hands control to an untrusted address before it has finished writing its own state, and the callee re-enters through a second entrypoint that still reads the stale value.

The modern variants are what make it interesting. Cross-function reentrancy re-enters a different method that shares storage. Cross-contract reentrancy routes through a sibling contract in the same system. Read-only reentrancy never writes anything at all — it simply calls a view function mid-callback and hands a corrupted price or share value to an integrating protocol, which is why the largest recent payouts in this class landed on lending markets and vault wrappers rather than on the vulnerable contract itself.

The disclosures collected here span ERC-777 and ERC-721 callback hooks, native transfer callbacks, and Cosmos and Solana equivalents where reentrancy shows up as unfinalized account state rather than a callback.

What reviewers look for

  • State written after an external call rather than before it
  • View functions that read a mid-transaction balance or share price
  • Token standards with transfer hooks (ERC-777, ERC-721, ERC-1155)
  • A reentrancy guard on some entrypoints but not on every one that touches the same storage
  • Integrating protocols that price a position by calling into the vulnerable contract

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

criticalReentrancyEVM-Solidity$1.2M

Read-only reentrancy in LP price oracle drains lending market

A lending market relied on a liquidity pool's raw virtual price function to value LP tokens deposited as collateral. During a liquidity removal operation, ETH transfers to the caller occurred before internal balance and supply states were reconciled, allowing an execution callback while state was inconsistent. An attacker used this callback to fetch an artificially inflated virtual price, enabling them to over-borrow against their collateral and drain the protocol's reserves in a single transaction.

Curve-style Lending Marketcode4renaApr 11, 2023Open
highReentrancyEVM-Solidity$0

Putty: Zero strike call options can be systemically used to steal premium from the taker

The Putty protocol was vulnerable to a permanent denial-of-service (DOS) condition when users attempted to exercise zero-strike call options involving specific non-standard ERC20 tokens. If a token reverted on zero-value transfers, the protocol's unconditional transfer attempt made it impossible for takers to exercise their options, allowing malicious makers to collect premiums without risk. This vulnerability allowed makers to systematically exploit unsuspecting takers by creating orders that appeared valid but were functionally impossible to exercise.

Puttycode4renaAug 7, 2026Open
mediumReentrancyEVM-Solidity$0

Putty: Putty position tokens may be minted to non ERC721 receivers

The Putty protocol incorrectly uses an unsafe minting function when generating ERC721 position tokens for users and makers. This omission fails to verify that the receiving contract can properly handle ERC721 tokens, leading to a risk where positions are sent to non-ERC721-compliant receivers. Consequently, if a smart contract recipient lacks the necessary logic to interact with or transfer these tokens, the assets remain permanently trapped, unable to be exercised or withdrawn.

Puttycode4renaAug 7, 2026Open
mediumReentrancyEVM-Solidity$0

PoolTogether: Unintended or malicious use of prize winners' hooks

In PoolTogether v5, the Vault contract allows prize winners to configure arbitrary hooks via the setHooks function. During the prize claiming process, the contract executes these user-defined hooks prior to and after prize distribution. Because the hook calls lack gas consumption caps and state-change restrictions, a user can configure a malicious hook that conducts unconstrained external operations, griefs claimers paying for transaction gas, or causes claiming transactions to revert. This results in potential gas exhaustion and denial of service for third-party prize claimers.

PoolTogethercode4renaAug 7, 2026Open
mediumReentrancyEVM-Solidity$0

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 Protocolcode4renaOct 24, 2024Open
mediumReentrancyEVM-Solidity$0

Phi: Contract `PhiNFT1155` can't be paused

The `PhiNFT1155` contract improperly implements its emergency pause mechanism by inheriting OpenZeppelin's generic `PausableUpgradeable` instead of `ERC1155PausableUpgradeable`. Because generic `PausableUpgradeable` does not hook into ERC-1155 transfer routines, invoking the pause function does not enforce paused restrictions on token transfers. As a result, users can continue transferring NFTs even when the owner has intentionally placed the contract into a paused state.

Phicode4renaOct 7, 2024Open

All reports in this group

Chains where this class shows up

Related vulnerability category pages