Three Zebra Security Vulnerability Disclosures (One High, Two Medium)

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)

@SphereDonout

Organization or Individual Name

Xifeng Jin

Additional Team Members

N/A

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

Zcash Community Forum

Requested Grant Amount (USD)

75000

Category

Research & Development

Project Summary

I am requesting $75,000 for my shares of three completed, publicly acknowledged Zebra security disclosures: one rated High and two rated Medium by the Zcash Foundation. The findings were fixed in Zebra 7.0.0; this request uses shared-reporter portions of the former Core Node payout amounts as reference points, with no bonus.

Project Description

At a glance

The completed findings

GHSA-2w9f: checkpoint sync stalls until restart. A peer could serve a forged checkpoint block body and a second invalid block so that a sync restart cancelled the verifier's rewind to the state tip. Zebra then treated honest missing blocks as already verified and stopped making checkpoint sync progress until an operator restarted it. The advisory credits my end-to-end P2P proof of concept and negative control, and credits @x15-eth's independent analysis. Zebra 7.0.0 moved recovery into the commit task. My $37,500 request is the other half of the High reference amount; @x15-eth separately requests $37,500.

GHSA-6v36: process abort on peer disconnection. If Zebra disconnected a peer while an outbound socket send was blocked, an unresolved response handle could trigger an assertion. Under release settings, the panic terminated zebrad. The confirmed trigger required a timing overlap while the node was syncing; the advisory reports no consensus, funds, privacy, or persistent-state impact. It credits my report and @professorsolderin's independent report. Zebra 7.0.0 fixed the response-handle lifecycle. I request half of the Medium reference amount.

GHSA-5h3r: honest peers banned over lock time. A Zebra node one block behind a peer could treat that peer's valid, newly relayed transaction as a ban-worthy lock-time violation. On 6.4.x the resulting peer-group ban lasted 24 hours; on earlier affected releases it lasted until restart. The node itself kept running. The advisory credits my private two-node reproduction and @sangsoo-osec's independent public report. Zebra 7.0.0 stopped assigning peer misbehavior scores to mempool lock-time rejections. I request half of the Medium reference amount.

Basis for the amount

The former ZCG Security & Vulnerability Disclosure Initiative classified Zebra as a Core Node and published reference amounts of $75,000 for High and $37,500 for Medium findings. I use those historical amounts to propose shares for this separate coinholder-directed retroactive grant application; they do not guarantee an award. Each finding has an independent public record, a named credit, and a released fix. I request no bonus and make no claim on behalf of the other credited reporters.

Technical Approach (how you did it)

I used LLM-based vulnerability discovery tool to scan the core logic components to find these issues, followed by carefully manual review to triage these findings.

My manual review followed each candidate from an untrusted network input or peer interaction through the relevant parsing, verification, synchronization, or error-handling code to its observable effect. I checked the conditions needed to trigger each issue and distinguished the affected releases from versions where the path was already blocked or fixed:

• GHSA-2w9f: I traced checkpoint-verifier progress, state commits, sync-round cancellation, and the rewind after a failed commit. I submitted an end-to-end P2P proof of concept with a negative control showing how a forged checkpoint block body and a second invalid block could leave the verifier ahead of the state and stop checkpoint sync until restart.
• GHSA-6v36: I examined the lifetime of an outbound request's response handle while a socket send was blocked and a peer connection was removed. The analysis identified the cancellation window in which the handle was dropped unresolved, causing an assertion and a process abort in release builds.
• GHSA-5h3r: I compared mempool lock-time validation and peer scoring at two nodes whose chain tips differed by one block. A two-node reproduction showed that a transaction valid for the ahead peer could cause the lagging node to ban that honest peer at the lock-time boundary.

The published advisories for GHSA-2w9f-9wx8-f5c8, GHSA-6v36-c42v-v98p, and GHSA-5h3r-fpmj-483w document the vulnerability analyses, reproduction conditions, and reporter credit for these findings.

Time Period of Work Completion

September–October 2026. These three advisories and their Zebra 7.0.0 fixes were published on October 22.

Total Budget (USD)

0

Budget Breakdown

This is an outcome-based retroactive award request. No salary, software, hosting, contractor, or other expenses are submitted for reimbursement, so the total expense budget is $0.

Previous Funding

No

Previous Funding Details

None. I have not received funding from the Coinholder Grants Program.

Other Funding Sources

No

Other Funding Sources Details

None. I have not received funding from other sources for these three findings.

Success Metrics

• Three published Zcash Foundation advisories credit @SphereDonout: GHSA-2w9f-9wx8-f5c8 is rated High; GHSA-6v36-c42v-v98p and GHSA-5h3r-fpmj-483w are rated Medium.
• Three fixes shipped in Zebra 7.0.0: the checkpoint-sync stall, the peer-disconnection abort, and the incorrect bans of honest peers. The Zcash Foundation announcement acknowledges my reports by name.
• The checkpoint-sync advisory acknowledges my end-to-end P2P proof of concept and negative control. The lock-time advisory acknowledges my two-node reproduction.
• The fixes address distinct availability and peer-connectivity harms: initial sync halted until restart, a timing-dependent process abort, and bans of honest peers. The advisories describe the impact and limits of each finding; none of these three is claimed as a consensus or funds vulnerability.
• The $75,000 request covers only my proposed shares. Other credited finders are named above, and @x15-eth's separate application requests the other share of GHSA-2w9f.

Proof of completion

• Zebra 7.0.0 release.
• GHSA-5h3r fix PR #11627. The other advisories link their affected code, fixes, and regression evidence.

Publication

• GHSA-2w9f-9wx8-f5c8
• GHSA-6v36-c42v-v98p
• GHSA-5h3r-fpmj-483w

Deployment/Release

• Zcash Foundation's Zebra 7.0.0 announcement

Other Evidence

• @x15-eth's application #79, which requests the other share of GHSA-2w9f.

Conflict of Interest Disclosure

I have no employment, contracting or governance relationship with the Zcash Foundation, FPF, ZCG, ZODL, Shielded Labs or any keyholder organization.

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.