Ethereum Fusaka Upgrade — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Ethereum Fusaka Upgrade, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Ethereum Fusaka Upgrade 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 Logic error, 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
- Logic error findings disclosed against Ethereum Fusaka Upgrade
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Ethereum Fusaka Upgrade: Weak Fiat-Shamir in `c-kzg-4844.verify_cell_kzg_proof_batch `
The c-kzg-4844 library's verify_cell_kzg_proof_batch function computes its Fiat-Shamir challenge over the original non-deduplicated commitments array while using the shortened, deduplicated commitment count. When commitments repeat in a batch, the trailing commitments are omitted from the challenge, so they are not bound by it. A malicious prover can craft an unbound trailing commitment that makes the aggregate batch verification pass even though every individual cell proof fails. Since Prysm and other Ethereum consensus clients use this function to validate data-column sidecars during the Fusaka (PeerDAS) upgrade, a malicious block proposer could inject invalid columns into a gossip subnet, causing vulnerable nodes to accept and rebroadcast them and degrading their peer scores into a soft partition.
Ethereum Fusaka Upgrade: Prysm incorrectly caches the result of `verify_data_column_sidecar_inclusion_proof` check
Prysm's Fusaka/PeerDAS data-column verification memoizes the inclusion-proof check under a key built from the signed block header and the inclusion proof but omits the sidecar's KZG commitments, contrary to the consensus spec's recommended argument tuple. Because the key omits the commitments, once any sidecar for a block passes the cached check, a later sidecar for the same block can carry arbitrary KZG commitments that do not correspond to the block. As long as those commitments pass standalone KZG cell verification, Prysm accepts, stores, and rebroadcasts the sidecar, so a node can accept a block whose blobs were never actually available. A malicious peer can exploit this to poison gossip, degrade Prysm nodes' mesh scores and quarantine them from honest subnets, risking a soft network split and, at >33% Prysm share, finality loss or severe delay, plus a DoS vector where receiver side is forced into expensive work on up to 4096 commitments. The fix is to include kzg_commitments in the cache key.
Ethereum Fusaka Upgrade: Malformed blob tx causes Nethermind validators to stop producing blocks
A missing length-equality check in Nethermind's blob transaction validation, combined with unguarded array indexing in the Fusaka V5 blob-serving engine handler, lets an attacker submit a single malformed EIP-4844 blob transaction whose versioned-hash count exceeds its actual sidecar blob count. When Nethermind-based validators select this transaction during payload assembly and the consensus layer calls engine_getBlobsV2, the handler throws an IndexOutOfRangeException instead of returning a partial-availability result, so the block proposal for that slot is skipped. Because the malformed transaction stays in the mempool and is re-selected on every subsequent proposal attempt, roughly 38% of network capacity (Nethermind's validator share) repeatedly misses blocks, causing lost rewards and inactivity-leak penalties. The team acknowledged the issue but declined to fix it at this time, and the finding carries no bounty payout.