Retroactive Grant Application - Zebra High and Medium Severity Sync Vulnerabilities (GHSA-jq45-ghw5-v37x, GHSA-3c94-hf7p-g5mf)

Community Grants Retroactive Grants
1

Hello Zcash community,

I have submitted a Q4 retroactive grant application on GitHub (#78), requesting $75,000 USD for two Zebra vulnerabilities that I found and privately reported: GHSA-jq45 (High) and GHSA-3c94 (Medium). Both let a single connected peer attack nodes with forged block bodies served under genuine block hashes. Both are fixed in released Zebra.

Read ZF’s advisories here: GHSA-jq45-ghw5-v37x (High) and GHSA-3c94-hf7p-g5mf (Medium)

What I found

After NU5, a block’s hash and Merkle root commit only to transaction IDs, and a v5 transaction’s ID doesn’t cover its authorizing data (ZIP 244). A peer can take a real block, flip one authorizing byte, and serve a different body under the same hash. Zebra accepted that body as the answer to its own download request.

  • GHSA-jq45 (High): one peer could hold a syncing node behind the chain tip. Zebra scored transparent script failures at 0 on the mempool, block-sync and block-gossip paths. With a one-byte scriptSig flip, a peer could stall a node’s sync again and again, “never scored, never banned. No funds, keys, proofs or mining are needed.” It affected every Zebra release from 2.3.0 until 7.0.0, and no configuration removed it.

  • GHSA-3c94 (Medium): free proof verification and a stalled sync. Zebra ran every proof in the forged body, including the Ironwood Halo2 batch, before catching the mismatch, and never penalized the peer. On block sync, each forged body that won its download race also idled the node for 67 seconds.

Both hit hardest at nodes catching up above the checkpoint, such as new nodes and exchanges or explorers coming back from downtime. ZF’s GHSA-3c94 advisory calls that “the most damaging scenario”.

How I found them: I followed a downloaded block from the network layer to the state commit, built the same-hash body by hand, and confirmed both findings with tests before reporting them privately. I used LLM-assisted code review to map the code paths and generate leads.

What the Zcash Foundation did

ZF fixed GHSA-3c94 in Zebra 6.4.0: the syncer now continues the round and re-requests the body from another peer. It fixed GHSA-jq45 in Zebra 7.0.0: peers that send script-invalid transactions or blocks are now banned on all three paths. Both advisories credit my work:

  • GHSA-3c94 (sole reporter): “ouicate, for the finding, the control-flow analysis, and the same-hash construction.”

  • GHSA-jq45 (independent reporter, with @0x15): “Independently reported by @ouicate, who showed the block-sync and block-gossip consequences and the same-hash scriptSig construction.”

Why $75,000

ZF rated these findings High and Medium in its published advisories. I request exactly the Core Node base for each rating from ZCG’s 2026 schedule, with no bonus:

Advisory ZF severity My credit Requested
GHSA-jq45-ghw5-v37x High (CVSS 7.5) Independent reporter, shared with @0x15 $37,500 (half of $75,000)
GHSA-3c94-hf7p-g5mf Medium (CVSS 5.3) Sole reporter $37,500
Total $75,000

  • The shared advisory is split equally. @0x15 (x15-eth on GitHub) is requesting the other half of GHSA-jq45 in his own application. Coinholders approved the same split for shared advisories in Q3 (#58).

  • Nothing has been paid, and there was no bounty route. ZCG closed its bounty program on 26 May, before both reports.

Thank you to the Zebra team for the fixes and the thorough advisories, and to you for reading. I’m happy to answer questions in this thread.

I’m also applying separately for two Critical Zebra consensus vulnerabilities: forum thread.

5 Likes
2

Also great work here!

Confirming the split. @ouicate and I share credit on GHSA-jq45, and we’re each requesting half, $37,500, so together it comes to one High base payout. ouicate’s independent report showed the block-sync and block-gossip side of the bug, which ZF’s advisory credits. Supporting this.

2 Likes