zcashd Medium Severity V4 Sapling Parsing Mismatch (GHSA-3jg6-49c6-q99v)

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)

@sangsoo-osec

Organization or Individual Name

sangsoo-osec

Additional Team Members

None. I am applying as an individual for my own security research contribution.

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

Through the Zcash Community Forum. I previously received a coinholder-approved retroactive grant in the Q3 2026 round.

Requested Grant Amount (USD)

37500

Category

Research & Development

Project Summary

I am requesting $37,500 for GHSA-3jg6-49c6-q99v, a completed Medium severity disclosure concerning a V4 Sapling transaction parsing mismatch between zcashd and Zebra. This application follows the discussion in my High severity application #74 and presents a separate Medium finding as a concrete case for considering how severity ratings and practical impact should inform retroactive security rewards.

Project Description

Shared background with application #74

Thank you again to the coinholders who approved my Q3 proposal and everyone in the community who reviewed, discussed, and supported that work.

My Q4 High severity application #74 sets out the shared background: the Q3 approvals for critical vulnerability research, recent published security findings, and the opportunity to discuss how researchers' contributions to Zcash's security should be rewarded. I refer readers to that application for the supporting Q3 references and release data.

This application brings the same discussion to a Medium severity finding, displayed as Moderate on GitHub. It requests recognition for a separate completed disclosure, with its own technical record, exploitation conditions, and proposed amount.

The completed contribution

The finding concerns GHSA-3jg6-49c6-q99v, published by the zcashd maintainers on May 8, 2026, with sangsoo-osec credited as the reporter. See the official advisory.

For a V4 Sapling transaction with no Sapling spends or outputs, the serialized valueBalanceSapling must be zero. The malformed case has:

In the affected zcashd code, the V4 read path used the presence of Sapling actions to decide whether to assemble a bundle. With both action vectors empty, it discarded the non-zero balance and exposed an empty-bundle balance of zero. The later validation check therefore examined an already-normalized object. Zebra's V4 parser instead rejected the same encoding with BadTransactionBalance.

Practical impact and trigger conditions

The advisory documents how this parser disagreement can reach block validation:

1. A miner or custom raw block producer embeds the malformed transaction bytes directly into a block.
2. The block's Merkle root uses the normalized transaction ID that zcashd derives after parsing.
3. zcashd can accept the raw block after normalization, while Zebra rejects those same bytes during deserialization.

The ordinary zcashd transaction relay, mempool, and mining path normalizes the encoding before block production. Submitting the malformed transaction to a stock node's mempool alone therefore does not preserve the divergent trigger. Subsequent zcashd block relay can also reserialize the block in canonical form. These conditions limit the issue's practical reach, as explained in the advisory's impact analysis.

Remediation and completed outcome

The zcashd v6.12.2 security release, published May 6, 2026, describes this issue and its fix: malformed empty-Sapling encodings with a non-zero balance are now rejected during deserialization, matching Zebra's behavior. The advisory lists versions below v6.12.2 as affected and v6.12.2 as patched.

The completed contribution is the accepted disclosure of this mismatch, with publicly documented reproduction steps, practical constraints, reporter attribution, and remediation.

The question for coinholders

As discussed in application #74, I see this round as a useful opportunity to consider what criteria should guide rewards for researchers' contributions to Zcash's security.

This Medium finding gives that discussion another concrete case. It concerns agreement between node implementations, while its practical trigger is constrained by normalization in the ordinary relay and mining path. Both aspects matter when assessing its value.

• Severity ratings: How much weight should the affected project's published severity carry in deciding whether to reward a finding and setting the amount? Should it serve as the main basis for a reward schedule?
• Practical impact: How should coinholders weigh realistic exploitation conditions, required attacker capabilities, the scope of exposure, and the potential harm alongside that rating?

I would welcome coinholders' views on how to balance these considerations, whether through severity-based reference amounts, case-by-case assessments, or a combination of the two. This application puts one Medium finding and a specific requested amount before coinholders to help make that discussion concrete.

Basis for the requested amount

The former ZCG Security & Vulnerability Disclosure Initiative included zcashd in the Core Node category and published a $37,500 base payout for Core Node / Medium findings.

Technical Approach (how you did it)

I used LLM-assisted differential code review to map equivalent V4 Sapling transaction parsing and validation paths in zcashd and Zebra. I then traced how each implementation handled a non-zero serialized Sapling balance when both Sapling action vectors were empty, including how normalization affected later validation, transaction IDs, and reserialization.

I validated the parsing mismatch and examined the relay, mempool, and mining paths to determine the conditions needed to preserve the malformed bytes through block validation. The published advisory records the code revisions and reproduction steps used in that analysis.

Time Period of Work Completion

Completed by May 2026. The remediation release, zcashd v6.12.2, was published on May 6, 2026; the advisory was published on May 8, 2026.

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

Yes

Previous Funding Details

I received $425,000 through the Q3 2026 Coinholder Retroactive Grants Program for Five Critical Zebra Consensus Divergence Vulnerabilities, application #58. That application covered five other advisories and did not include GHSA-3jg6-49c6-q99v.

I have also submitted a separate High severity application, #74, requesting $75,000 for GHSA-xvj8-ph7x-65gf. The present request covers only GHSA-3jg6-49c6-q99v. The two applications raise the same questions about reward criteria and concern separate findings.

Other Funding Sources

No

Other Funding Sources Details

No response

Success Metrics

• One completed disclosure with sangsoo-osec credited as the reporter and a published Medium severity classification.
• A documented difference in how zcashd and Zebra handled the same malformed encoding, with the practical trigger conditions explained.
• A released fix aligning zcashd's deserialization behavior with Zebra, documented in the v6.12.2 release notes.

Proof of completion

• GHSA-3jg6-49c6-q99v — published classification, reporter credit, technical analysis, reproduction steps, affected versions, and patched version.
• zcashd v6.12.2 release — public release notes describing the malformed V4 Sapling encoding and its rejection during deserialization.

Conflict of Interest Disclosure

No response

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.