Retroactive Grant Application - Zebra 6.2.0 High Severity Remote DoS (CVE-2026-104423)

Community Grants Retroactive Grants
1

Zcash has come a long way in ten years, and a lot of that progress is owed to the people committed to making the network stronger.

Special thanks to Taylor Hornby. (@earthrise)

————-
Hello Zcash Community!

I have submitted a Q4 retroactive grant application for my responsible disclosure of CVE-2026-104423, a Zebra node vulnerability that could have instantly cut off the wallets, exchanges and miners relying on it from the rest of the network.

At almost no cost, an attacker could stop every reachable Zebra node from syncing with the Zcash blockchain.

The Zcash Foundation published the advisory crediting me as the sole reporter.

The vulnerability I reported

In July I discovered and responsibly disclosed a High severity remote DoS in Zebra version 6.2.0 (“Uncapped shielded verification cost lets peer-pushed V6 transactions stall block verification”); GHSA-2p4c-3q4q-p463

Before Zebra accepts a transaction from another node, it needs to verify it.

Unfortunately, on versions before 6.2.1 it did the expensive verification checks first and left the cheap ones for later (like whether the transaction paid a fee), and because Zebra checks new blocks in the same line as these transactions, real blocks ended up waiting behind them.

What the attack looked like

  1. An attacker connects to a Zebra node as an ordinary peer, which the advisory notes requires “no authentication or special privileges.”
  2. They send transactions carrying fake proofs, which can be produced very easily on an ordinary computer without paying any fee.
  3. The Zebra node does the expensive work of checking every single one of them before it can reject them, and new blocks wait in the same line behind that work.
  4. The node stops syncing for as long as the attacker keeps sending these fake transactions, and the attacker can do the same to every reachable Zebra node at once.

Since the network now runs on Zebra, the wallets, exchanges and miners relying on those nodes would have stopped seeing new blocks until the attack ended.

Disclosure and fix

I submitted the advisory on July 20 and messaged Pili and Conrado from the Zcash Foundation on the Z3 Signal group, and less than two days later, on July 22, the fix was merged and shipped in Zebra 6.2.1, which now checks fees before proofs and disconnects peers that send invalid ones. The Foundation rated it High and published the advisory on August 17 crediting me as the sole reporter, and CVE-2026-104423 was assigned on October 2. Zakura’s 1.0.3 release notes credit the report as well.

I hope that coinholders rewarding this report encourages more people to look closely at the software Zcash runs on and bring what they find to the teams who can fix it.

How I got to bug-hunting on Zcash

While building on Zcash, I spent a lot of time studying the Zebra node, especially how it takes a transaction from the mempool into a confirmed block, since I wanted to understand what checks Zebra runs on a transaction, and in what order.

While working through it with an LLM, I learned that new blocks and incoming transactions were verified in the same queue, so new blocks could end up waiting behind them.

Suspecting a weakness in this design, I used an LLM-assisted auditing harness to find attack paths around this seam, and it turned out a peer could fill that queue with transactions carrying fake proofs, which is how I discovered the vulnerability

From there I built a complete proof of concept against a live Regtest network to confirm the attack, after which I submitted the advisory to the Zcash Foundation on July 20 with the PoC and vulnerability details

Published proof of responsible disclosure

Requested Grant Amount (USD)

75,000

5 Likes
Q4 2026 Coinholder-Directed Retroactive Grant Program - Call for Proposals