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
105
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
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

Rigor Protocol: New subcontractor can be set for a SCConfirmed task without current subcontractor consent

Rigor Protocol's subcontractor management lets a builder or contractor reassign a task's subcontractor through inviteSC() without any signature check, whereas changing terms mid-task normally requires consent from all parties via checkSignatureTask(). Although the direct path (replacing a subcontractor on an already-confirmed, active task) is blocked by inviteSubcontractor()'s onlyInactive modifier, the warden showed the check is bypassed in changeOrder() budget-increase flows: when added funds are not yet lent, the task is unapproved and reset to inactive, after which a dishonest contractor can invite their own subcontractor who then collects the full task budget on completion, divesting the subcontractor who actually performed the work of their payment.

Rigor Protocolcode4renaAug 7, 2026Open
mediumReentrancyEVM-Solidity$0

Putty: The contract serves as a flashloan pool without fee

PuttyV2's fillOrder and exercise functions lacked reentrancy protections, allowing a malicious user acting as both maker and taker to re-enter the contract from a malicious base-asset transfer callback. That re-entry exercises a short call to pull real ERC20/ERC721 balances out of PuttyV2, deploy them for profit on other venues, and repay before fillOrder completes. Because the protocol's 3% option fee is assessed in the base asset—an attacker-controlled custom token—the attack amounts to free, unrestricted use of all assets held by the contract. Sponsor and judge acknowledged the validity, agreeing flashloans are a feature but fee evasion is a bug, with no easy mitigation beyond nonReentrant guards at a gas cost.

Puttycode4renaAug 7, 2026Open
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

All reports in this group

Chains where this class shows up

Related vulnerability category pages