Access control vulnerabilities in disclosed bug bounty reports

The most-paid bug class on most programmes, because a missing modifier is worth whatever the contract holds.

Reports indexed: 159
Total paid: $850k
Critical: 3
Largest payout: $600k

Access control findings dominate disclosed bug bounty volume, and they are almost never subtle. A privileged function ships without its modifier. An initializer can be called a second time. An upgrade path leaves an implementation contract unowned. A role is granted in a constructor that a proxy never runs.

What makes this class worth studying rather than dismissing is the second tier: the cases where the modifier is present and still wrong. Role checks that verify membership in the wrong registry, signature-gated functions where the signer is recovered but never compared, cross-chain message handlers that check the sender but not the source chain, and admin paths reachable through a delegatecall that resets `msg.sender`.

This category also holds the account-level findings from wallet and infrastructure programmes — key handling, session scoping and permission prompts — where the vulnerable surface is the client rather than the chain.

What reviewers look for

Public or external state-changing functions with no modifier
Initializers callable more than once, or implementation contracts left uninitialized
Signature recovery without a comparison to an expected signer
Cross-chain handlers that validate the sender address but not the origin chain
`delegatecall` paths where the caller identity is not what the check assumes

Curated highlights

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

criticalAccess controlSolana-Rust$600k

Missing owner check on Solana instruction lets attacker drain vault

A missing program ownership check in a Solana yield vault protocol allowed unauthorized account spoofing during withdrawal processing. Because the instruction handler accepted an unchecked account and verified only a discriminator byte rather than validating account ownership, an attacker could supply a custom state account with manipulated fields. The protocol trusted the forged state data and generated a Program Derived Address (PDA) signature to execute a token transfer, enabling complete draining of the protocol's vault funds.

Solana Yield VaultimmunefiNov 3, 2022Open

highAccess controlCosmos-SDK$250k

Cosmos SDK module allows unauthorized state migration via missing ante handler check

A logic flaw in a Cosmos SDK module's state migration handler allowed unauthorized signers to execute privileged state updates. The message authority check relied on a helper function that returned true when the authority field was empty, and the message route was incorrectly exposed as a standard transaction rather than being restricted to governance. An attacker could issue state updates with an empty authority field to inject malicious counterparties into the IBC channel allowlist, enabling the execution and processing of forged cross-chain transactions.

IBC App ChainimmunefiDec 5, 2023Open

mediumAccess controlEVM-Solidity$0

Putty: [Denial-of-Service] Contract Owner Could Block Users From Withdrawing Their Strike

PuttyV2's withdraw function deducts a platform fee from a user's escrowed strike and transfers that fee to the contract owner inline, before sending the remaining strike to the user. Because the user's transfer only executes if the owner fee transfer succeeds, the owner can permanently block all strike withdrawals by making that fee transfer revert — either by transferring ownership to the zero address (rejected by common ERC20s) or by adopting a malicious token whose transfer-to-owner reverts. The judge initially rated the issue high but downgraded it to medium because the triggering conditions are unlikely (fee must be nonzero or a malicious base asset adopted); the protocol confirmed it and fixed it by relocating the platform fee transfer to order-filling time, so any remaining owner griefing only causes a DoS rather than trapping user funds.

Puttycode4renaAug 7, 2026Open

mediumAccess controlEVM-Solidity$0

Rigor Protocol: Incorrect initialization of smart contracts with Access Control issue

Rigor Protocol's upgradeable contracts ship with initialize() functions that lack any caller authorization, and its proxy deployments pass an empty data field so initialization is deferred until after deployment. In the intervening window, a mempool-watching attacker can front-run the deployment and invoke an initializer first with arbitrary arguments, planting harmful contract addresses or settings. This can lead to loss of funds, loss of control over protocol components, contract/setting replacement, or forced redeployment. The sponsor confirmed the issue while disagreeing on severity, and the Code4rena judge upheld it as valid but downgraded it to Medium because the practical impact is limited and failed deployment transactions typically halt the script anyway.

Rigor Protocolcode4renaAug 7, 2026Open

mediumAccess controlEVM-Solidity$0

The Graph: Governor can rug pull the escrow

The Graph's BridgeEscrow exposes an approveAll() function that the protocol governor can call to grant any address an unlimited allowance over the escrowed GRT. Because the escrowed tokens are never burned, a compromised or malicious governor could permanently drain the full L1 balance, and even an honest governor forces users into a perpetual trust assumption over the funds. The sponsor disputed the finding as intentional design meant to support multiple future bridges and emergency recovery after a critical Arbitrum incident, and the judge leaned toward closing it as invalid while noting Code4rena's convention of awarding such centralization risks as Medium for awareness. The disclosure thus represents a contested governance/centralization-risk concern rather than a directly exploitable vulnerability.

The Graphcode4renaAug 7, 2026Open

mediumAccess controlEVM-Solidity$0

PoolTogether: `drawManager` can be set to a malicious address

The PoolTogether PrizePool contract is vulnerable to a front-running attack due to a missing access control modifier on the setDrawManager function. A malicious actor can intercept the initial setup to designate an attacker-controlled address as the draw manager. Because the contract prevents subsequent changes to the draw manager once assigned, this compromise is permanent, granting the attacker perpetual control over critical administrative functions, including the ability to withdraw from the reserve and manipulate prize draw operations.

PoolTogethercode4renaAug 7, 2026Open

All reports in this group

Chains where this class shows up

EVM · Solidity Solana · Rust Move Cosmos SDK Other chains and infrastructure

Related vulnerability category pages

Reentrancy Oracle manipulation Flash loan attack Integer overflow / underflow Signature replay Front-running / MEV Bridge exploit Price manipulation Logic error Governance attack