The Graph — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for The Graph, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed The Graph reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Access control, Integer overflow / underflow, Bridge exploit, 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
- Access control findings disclosed against The Graph
- Integer overflow / underflow findings disclosed against The Graph
- Bridge exploit findings disclosed against The Graph
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
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 Graph: Initialize function in `L2GraphToken.sol`, `BridgeEscrow.sol`, `L2GraphTokenGateway.sol`, `L1GraphTokenGateway.sol` can be invoked multiple times from the implementation contract
The Graph's upgradeable proxy contracts — L1GraphTokenGateway, L2GraphTokenGateway, L2GraphToken, and BridgeEscrow — expose initialize functions protected only by an onlyImpl modifier rather than OpenZeppelin's initializer guard. If the implementation is ever callable by an attacker (e.g., a compromised or rogue implementation), the functions can be re-executed to point the contracts at an attacker-controlled controller. Because the onlyGovernor modifier resolves against that controller, the attacker gains governor privileges and can call BridgeEscrow.approveAll to grant an unlimited GRT allowance and drain escrowed bridge funds. The sponsor confirmed the finding, awarded Medium severity, and fixed it in graphprotocol/contracts PR #741 by adding the initializer guard to all four contracts.
The Graph: After proposed 0.8.0 upgrade kicks in, L2 `finalizeInboundTransfer` might not work
The Graph's L2GraphTokenGateway restricts finalizeInboundTransfer to calls arriving from its L1 counterpart gateway, verified via applyL1ToL2Alias, which intentionally wraps the L1 address plus a fixed offset into the expected L2 sender. The protocol planned to upgrade from Solidity 0.7.6 to 0.8.0, whose built-in overflow checks would cause that deliberate uint160 wrap to revert whenever the sum exceeds UINT160_MAX. Because the L1 gateway's address can trigger such an overflow, the modifier would reject legitimate inbound transfers after the upgrade and break L2 deposit finalization. The sponsor confirmed the concern, the judge upheld it as a valid Medium, and the fix wrapped the aliasing arithmetic in an unchecked block in a future 0.8.0 branch.
The Graph: If L1GraphTokenGateway's `outboundTransfer` is called by a contract, the entire `msg.value` is blackholed, whether the ticket got redeemed or not
The Graph's L1GraphTokenGateway.outboundTransfer, when bridging GRT to Arbitrum, passes the caller's own address as both the submission-refund and value-refund destination for the underlying retryable ticket. This is harmless for EOA callers because Ethereum and Arbitrum addresses are congruent, but a contract caller (e.g., a multisig) typically has no L2 counterpart able to withdraw the refund, permanently stranding the excess submission fee. The judge ruled this a Medium value-leak (not direct theft), noting the L2 ticket-creation-failure path no longer applies under Arbitrum Nitro but the refund-stranding behavior for contracts remains real.