Retroactive Grant Application - CVE-2026-34202: Zebra Remote Denial of Service (Critical)

Community Grants Retroactive Grants
1

In March this year I found a bug in Zebra that let anyone crash any node on the
network by sending it a single message. I reported it privately to the Zcash
Foundation, they fixed it within days, and it shipped in Zebra 4.3.0 with a note
telling operators to upgrade immediately. The advisory is CVE-2026-34202, rated
Critical.

There was no bug bounty programme when I reported it. ZCG’s launched a month
later and does not apply retroactively, so there is no route through which that
report can be paid. That is why I am asking coinholders directly.

The bug

Zebra validated some transaction fields lazily that librustzcash validates
eagerly. So a malformed V5 transaction would deserialize cleanly, and then panic
the node a moment later when it went to compute the transaction ID.

One tx message to the default P2P port. No authentication, no unusual
configuration, nothing required from the operator. It worked against every Zebra
node below 4.3.0 that was reachable on the network, and it was reachable through
sendrawtransaction as well.

How I found it

I had been fuzzing Zebra’s deserialization path for a while: 95.6 million
iterations across six targets, seeded with real mainnet data — 1,565 transactions
and 473 blocks pulled from a synced node — spread across a couple of machines.

It found nothing. Not one crash in 95.6 million tries.

What changed was giving up on “did it parse?” as the question. The harness I
built next takes the object that parsed cleanly and keeps going: property access,
hash computation, consensus checks, fee calculation. It found this within minutes
of its first run.

That contrast is the part I would point at if you are wondering whether this was
luck. The advisory describes a transaction that “passes initial deserialization
but fails during transaction ID calculation” — exactly the shape of bug that
deserialize-only fuzzing cannot reach, which is why 95.6 million iterations of it
came back empty.

What happened next

I reported it through Zebra’s coordinated disclosure process rather than opening
an issue, and then worked with the team while they reproduced and fixed it. From
the release post: “Thanks to robustfengbin for responsibly disclosing the
vulnerability and working with us to quickly reproduce and remediate it.”

The fix merged on 25 March, Zebra 4.3.0 shipped on 26 March, and the advisory was
published on 27 March. The fix was not a patch over one input — it moved
rejection of undeserializable transactions into the deserialization phase and
replaced the internal panics with graceful error handling, and the Foundation
added regression coverage to the V5 transaction generator alongside it.

It is the first Critical in Zebra’s public GitHub security-advisory record. The
next one appears three weeks later.

The grant this came out of

The fuzzing that found this bug is the work described in my ZCG grant application
#234, and the sequence matters, so here it is:

  • 16 March — I submit #234, proposing to build fuzzing infrastructure for Zebra.
  • 23 March — A reviewer pushes back, reasonably: there was no public evidence I
    had ever done fuzzing work. No fuzz targets, no crash triage, no OSS-Fuzz
    contributions.
  • 24 March — I reply that the work has already found something, that it has been
    reported, and that I cannot say what it is yet.
  • 26 March — The same reviewer confirms it independently: “serious and remotely
    exploitable… this validates your approach, methodology and triage
    capabilities.”
  • 27 March — The advisory is published.
  • 30 March — ZCG votes to approve the grant.

The bug was found, reported, fixed and disclosed before that grant was approved. #234
is a $30,000 six-month engineering grant for fuzz targets, CI integration and
OSS-Fuzz onboarding, paid against milestones, none of which depend on finding
vulnerabilities. It bought the tooling. This application is about the result.

Where the number comes from

ZCG’s published payout schedule sets a Core Node Critical at a $150,000 base,
with a discretionary bonus of up to $75,000 on top. Zebra is a Core Node
repository, and the Foundation rated this Critical. So $150,000 is not my own
valuation of the finding — it is the figure this ecosystem had already written
down for it.

This request is for the $150,000 base only. The schedule also allows a
discretionary bonus of up to $75,000, which ZCG describes as the remediation
team’s to award at their discretion.

Two scores appear against this CVE and both are correct: the advisory carries
CVSS v4.0 9.2, and NVD’s entry scores it 7.5 under CVSS v3.1. The two vectors
agree on the attack — network-reachable, low complexity, no privileges, no user
interaction, high availability impact. They differ because CVSS v4.0 adds
subsequent-system impact metrics that v3.1 does not have; this advisory’s v4
vector sets Subsequent System Availability to High.

Sources

I welcome questions during the review period.

2 Likes
Call For Proposals: Coinholder-Directed Retroactive Grants Program Q3
30 Day Review Period: Coinholder-Directed Retroactive Grants Program Q3