Critical Zebra Block Discovery DoS (CVE-2026-44499)

Terms and Conditions

• I agree to the Grant Agreement terms if funded
• I agree to Provide KYC information if funded above $50,000 USD
• I agree to disclose conflicts of interest
• I understand that this grant program is only eligible for completed work, as it is a retroactive grant program. Applications for planned or partially completed work will not be considered. All completed work will be verified and accepted by its intended users or their representatives, who will confirm that the outputs meet the required quality, functionality, and usability before the work is listed as an option for Coinholder voting.
• I agree that for any new open-source software, I will create a CONTRIBUTING.md file that reflects the high standards of Zcash development, using the librustzcash style guides as a primary reference.
• I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any merge, branch, pull request, and commit guidelines as exemplified in the librustzcash repository.
• I understand all grants are valued in USD but will be disbursed in Shielded ZEC. I acknowledge and accept that disbursement amounts may fluctuate based on the ZEC/USD exchange rate at the time of payment.

Application Owners (@octocat, @octocat1)

@shieldedonly

Applicant & Organization

Organization or Individual Name

shieldedonly (security researcher)

Additional Team Members

None. I am the sole researcher and applicant for this finding. The Zebra maintainers' implementation and review work are credited separately in the remediation record.

How did you learn about the Lockbox: Coinholder Retroactive Grants Program?

Through the Q4 2026 call for proposals on the Zcash Community Forum.

Project Overview

Requested Grant Amount (USD)

$150,000 USD

Category

Research & Development

Project Summary

I'm applying for a $150,000 retroactive grant for discovering and responsibly disclosing CVE-2026-44499, a Critical Zebra vulnerability that allowed a single unauthenticated peer connection to permanently halt a targeted node's block discovery. I privately reported it on April 14, 2026; the maintainers fixed it in Zebra 4.4.0 and published the advisory on May 5.

Project Description

Completed contribution

Zebra is a Rust implementation of a Zcash full node. This application covers my discovery, validation, and private disclosure of a vulnerability in its peer-to-peer block discovery pipeline. The completed research produced a working proof of concept (PoC) and a report, and I submitted the finding on April 14, 2026. The Zebra maintainers implemented and released the remediation.

The requested grant recognizes this completed security finding and disclosure. The supporting research method is described under Technical Approach.

Researcher background

I publish as @shieldedonly on the Zcash Community Forum. The Foundation publicly acknowledges my contributions to two other Zebra findings:

• GHSA-29x4-r6jv-ff4w: credits me for discovering and reporting an RPC denial-of-service issue.
• GHSA-xvj8-ph7x-65gf / CVE-2026-40880: acknowledges my additional advisory, submitted while the team was working on an earlier report, which showed that the issue affected transaction validation beyond the initially reported lock-time case.

These contributions establish research background. This application requests recognition only for CVE-2026-44499.

Publicly documented vulnerability

The Zebra security advisory classifies the issue as Critical, citing an attack that requires no authentication, no special privileges, and only one peer connection. Its assessment states:

The halt is permanent: the node will never recover without operator intervention.

This persistent loss of a core node function is the security impact underlying the request.

How the discovery failure developed

Zebra learns about new blocks through peer announcements and periodic synchronization requests. A peer's inv announcement identifies a block to download and verify. The syncer separately asks peers for missing block hashes or headers using FindBlocks and FindHeaders. These complementary mechanisms allow the node to discover the advancing chain.

The vulnerability combined pressure on the announcement-driven download queue with unhelpful responses on the synchronization path. One malicious connection could consume shared gossip-download capacity while keeping the fallback from making useful progress. Honest peers' new-block announcements could then be dropped at the full queue. Technical Approach explains the mechanisms and corresponding source changes.

Why the result matters

A node must keep discovering blocks to maintain a current view of the chain. A sustained discovery halt disrupts that function and can affect services relying on the node for current chain data. The research identified a combined failure across cooperating subsystems and gave maintainers a reproducible finding to address through a security release.

Disclosure and publication timeline

Why apply for a retroactive grant

My April 14 report preceded the April 28 initiative announcement by fourteen days. In its May 8 clarification, ZCG stated that its initiative covered reports submitted after the announcement and did not apply retroactively.

I am asking coinholders to recognize this completed contribution through the Q4 Coinholder-Directed Retroactive Grants Program. The Q4 call provides a route for completed, publicly verifiable work such as this finding and its documented remediation.

Technical Approach (how you did it)

How I found it

I built and used a custom AI-assisted vulnerability research tool, organizing the investigation into focused lanes such as consensus and denial of service. The workflow conducted research and validation and generated a working PoC and report. I ran it against a Zebra version that predated the fix.

The finding connected weaknesses in gossip announcements, syncer responses, and block downloads into one persistent availability failure. That interaction matters because the syncer is expected to discover blocks missed through gossip; the reported behavior degraded that recovery path as well as normal announcements.

Validation and research outputs

The published security advisory, upstream fix, and Zebra 4.4.0 release document the vulnerability and its remediation. The Zcash Foundation/Zebra team can verify my original private submission and my role as its submitter, using the report reference under Proof of completion.

Technical analysis of the vulnerability

The public advisory identifies a composite failure involving the gossip, syncer, and download subsystems. The source references below are pinned to the immediate parent of the fix, 85303ea98ee3fce4f9190b6f05ce3f162f8b5ffd. These references let reviewers inspect the queue limit, caller behavior, and response handling in the implementation immediately before remediation.

1. A shared gossip queue could be monopolized

Incoming block announcements are translated into AdvertiseBlock requests and handed to Downloads::download_and_verify. That function manages a shared set of pending block downloads and verification tasks. Before the fix, it deduplicated already-queued hashes and enforced a total concurrency limit, but did not allocate capacity by advertising peer or IP. The advisory also identifies the absence of a per-connection rate limit on incoming inv messages.

The pre-patch implementation capped the configured concurrency at 30, with the effective limit depending on configuration. That global bound did not reserve capacity for other peers. Sequential announcements of distinct fabricated hashes could occupy the same slots needed for legitimate new blocks. The advisory reports that the queue could be filled in under a millisecond; that timing comes from the advisory rather than a separate benchmark claimed here. Pre-patch download manager.

2. Queue exhaustion did not trigger recovery at the caller

When the queue reached its limit, download_and_verify returned DownloadAction::FullQueue. The AdvertiseBlock branch in the inbound service called the function without handling that return value, then returned a normal Nil response. The download manager's own documentation expected the sync service to discover a skipped block later.

An honest block announcement could therefore be discarded at the capacity boundary, while recovery depended on the syncer. The download manager logged the drop at debug level and incremented a metric, but the inbound caller took no recovery action in response to FullQueue. Pre-patch inbound handler.

3. The alternative discovery path could also be made unproductive

The syncer periodically queried peers for missing blocks. The reported malicious peer answered FindBlocks with empty inv responses and block-download requests with NotFound. These replies supplied neither useful discovery information nor the requested block bodies, while remaining valid protocol responses that did not incur a misbehavior penalty.

The connection state machine's FindBlocks response handler accepted a block-inventory list and converted it to Response::BlockHashes; an empty list could satisfy that handler and complete the request without contributing any hashes. This helps explain why a successful protocol exchange did not necessarily mean synchronization progress. Pre-patch connection handling.

As documented in the advisory, NotFound denied the requested block without causing the malicious connection to be removed. The peer could continue applying announcement pressure and supplying unproductive discovery responses as individual download attempts completed or failed.

4. The interaction defeated recovery

The combined result was suppression of both discovery paths through one TCP peer connection using multiple announcements and responses. As the external chain advanced, the target's block deficit could keep increasing. The advisory characterizes the halt as permanent without operator intervention.

Responsible disclosure

I privately submitted the finding on April 14, 2026, fourteen days before the ZCG initiative was announced. The private report was accepted on April 15, 2026. The advisory became public on May 5. My original private report is identified under Proof of completion; the Zcash Foundation/Zebra team can verify my submission, its acceptance date, and its connection to the published advisory.

Remediation outcome

The corresponding implementation is visible in commit 602c8b7, committed May 1, 2026. It addresses both discovery paths:

These protections address capacity allocation and discovery progress separately. The advertising-IP limit prevents one source from taking all gossip-download slots. Stall tracking removes persistently unhelpful discovery peers and frees their connections without requiring a misbehavior ban.

The comparison with v4.4.0 confirms that the fix commit is included in the release, whose notes describe the stalled-peer remedy. The linked unit tests cover tracker behavior; the public advisory documents the overall attack and impact.

Time Period of Work Completion

Q2 2026 - completed by April 14, 2026 (research, PoC, report, and private disclosure).

Budget & Funding

Total Budget (USD)

$0 in costs claimed for reimbursement.

Budget Breakdown

Costs claimed in this application

No expenses are claimed for reimbursement. The $150,000 grant request recognizes the completed security outcome separately from the costs of producing it.

Requested award and valuation

Requested grant: $150,000 USD, recognizing the completed finding, validation, PoC, report, and responsible disclosure.

The amount uses a published ecosystem reference: the former ZCG initiative's payout table listed a $150,000 base for a Core Node / Critical finding, and its announcement included Zebra in Core Node. The request uses that base as a valuation reference and includes no discretionary bonus.

Basis for the Critical valuation

The Zebra team's published assessment explicitly classifies this vulnerability as Critical. Its stated rationale combines remote unauthenticated access, no special privileges, a single peer connection, and a permanent block-discovery halt requiring operator intervention. The attack suppressed both normal block announcements and the syncer fallback, preventing the targeted node from recovering through its alternative discovery path. This persistent loss of a core full-node function is the documented impact underlying my request.

The GitHub Advisory Database separately lists a CVSS v4.0 score of 8.7 (High), while retaining the description's Critical assessment. My request follows the Zebra team's explicit Critical classification in its repository advisory.

The historical ZCG framework assigns severity assessment to remediation teams and technical reviewers and describes its examples as non-exhaustive. On that basis, I ask coinholders to recognize this completed contribution at the $150,000 Core Node / Critical base, consistent with the remediation team's published assessment and the funded Q3 Zebra availability precedent below. This is the valuation I am requesting for the completed finding and responsible disclosure.

Funded Q3 security-research precedents

The official Q3 2026 results list the following five security-related grant proposals as Funded. Administrator comments dated October 16, 2026 also record disbursement of the amounts below:

The Orchard bounty (#51) and bonus (#53) are separate awards for the same discovery, totaling $1,500,000 to Taylor Hornby.

These five selected awards total $2,475,000 and demonstrate that coinholders have already used the retroactive program to recognize completed security findings. The closest reference for this request is #54: a Critical Zebra availability finding reported before the bounty initiative, funded at $150,000.

My request follows that same basis: a completed Critical Zebra finding, privately reported before the initiative opened, subsequently documented and fixed. The Q3 decisions provide a concrete precedent for recognizing this contribution at the requested $150,000 level.

Previous Funding

No

Previous Funding Details

I have not received previous funding from the Coinholder Retroactive Grants Program.

Other Funding Sources

No

Other Funding Sources Details

I have received no funding, bounty, grant, or other payment for this finding. No prior payment needs to be deducted from the $150,000 request. This application covers GHSA-h9hm-m2xj-4rq9 / CVE-2026-44499 only.

Impact & Evidence

Success Metrics

These are completed outputs: research artifacts, a private report, a public advisory, and a released mitigation. The source and release links below document the maintainers' work; the original private submission provides the record through which the team can verify my attribution.

Proof of completion

Repository / release

• Zebra source repository: affected upstream project.
• Fix commit 602c8b7: implements the per-advertising-IP download limit and stalled-discovery-peer handling described above.
• Stall-tracker unit tests at the fix commit: test definitions covering the threshold, reset, and per-peer tracking behavior.
• Zebra 4.4.0: release containing the documented remediation.
• Foundation release announcement: public explanation of the discovery-path failure and remedy.

Publication

• Current GitHub advisory: authoritative technical description, severity, affected versions, and fixed version.
• CVE-2026-44499: vulnerability identifier; machine-readable record includes publication metadata.

Applicant attribution and completion evidence

• Original private report: GHSA-28xj-328h-72vm, submitted by me on April 14, 2026 and accepted on April 15, 2026.
• Public reference to the original ID: The Foundation's May 2 release announcement identifies the block-discovery vulnerability under GHSA-28xj-328h-72vm.
• Submitter verification: I am not publicly named in the published advisory's credits. The Zcash Foundation/Zebra team can verify from the original private report that I was its submitter and that it is the report underlying GHSA-h9hm-m2xj-4rq9 / CVE-2026-44499.
• Contemporaneous public discussion: On May 7, I asked whether earlier submissions qualified for the new initiative; in my May 8 follow-up, I noted that a Critical issue had been published after the initiative launched. These posts provide public context, rather than a substitute for the original report.

The original report ID identifies the private submission for maintainer verification. The public advisory and fixed release document the issue and remediation.

Conflict of Interest Disclosure

I have no known actual, potential, or perceived conflicts of interest relevant to this application. Funding and compensation for this finding are disclosed above.

Zcash Community Forums Post Requirement

Community Forum Posting

• I understand it is my responsibility to post a link to this issue on the Zcash Community Forums after this application has been submitted so the community can give input. I understand this is required in order for the community to discuss and vote on this grant application. Note: If you are unable to post on the forum (for example, due to new user restrictions), please leave a comment below, and we will adjust your posting permissions.

I welcome questions about the research, evidence, attribution, and valuation in the forum discussion.