Zebra Vulnerability Bounty: Reporter Share of High-Severity Advisory GHSA-j4cw-58mj-7w6v

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)

@asafmod

Organization or Individual Name

asafmod (independent security researcher)

Additional Team Members

None. I am applying as an individual, for my own share of one advisory.

The advisory's other credited researchers are @x15-eth and @janneh2000 (independent
rediscoverers). I claim only my equal share, and nothing on their behalf.
Remediation was done by the Zcash Foundation's Zebra team (structured credits
include @conradoplg, @upbqdn, @oxarbitrage and @mpguerra).

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

The Q4 2026 call for proposals on the Zcash Community Forum, and seeing other Zebra security researchers file their applications this round.

Requested Grant Amount (USD)

25000

Category

Research & Development

Project Summary

I am the original reporter of GHSA-j4cw-58mj-7w6v, a High-severity (CVSS 3.1 7.5) Zebra vulnerability fixed in Zebra 7.0.0: one permissionless 2 MB transaction could stall block verification for minutes, because the transparent signature-hash cost of a transaction grows with the square of its input count. I reported it privately to the Zcash Foundation on 17 September 2026 with a working, reproducible proof of concept, and I am asking for $25,000 — my equal share of ZCG's published High-severity base payout, split among the three researchers ZF credits on the advisory.

Project Description

How this claim is scoped

• One advisory, one share. I'm claiming my reporter share of GHSA-j4cw-58mj-7w6v only — the advisory ZF credits me as reporter on. Nothing else.
• Three credited researchers, one base payout. ZF credits me, @x15-eth and @janneh2000 on this advisory. I'm asking for one third of ZCG's published High base rate: $75,000 ÷ 3 = $25,000. If the other two claimed identically, all three shares together would sum to exactly one payout — no more.
• Coordinate with, not competing against, the other claims. @x15-eth has filed his own application this round for his share of this same advisory (issue #79). Both claims use the same split; together they total half the advisory's base payout, leaving the third researcher's share unclaimed.
• Unpaid to date, no bonus. I've received nothing from any source for this advisory, and I'm not requesting anything above the base rate.

The completed work

The bug. Zebra's ZIP-244 (v5 transaction) signature hasher cached only the txid_parts digest, not the per-transaction hash_amounts and hash_scriptpubkeys digests. Every input's signature hash therefore re-hashed data covering all of the transaction's inputs. The per-input cost grows with the input count, so the per-transaction cost grows with its square. One permissionless, at-most-2 MB transaction could make Zebra perform minutes of hashing work on the same thread pool that verifies blocks — and the work kept running after the transaction was rejected, with no misbehavior score attached.

My report. I found the issue by reading zcash_primitives' ZIP-244 implementation and confirming that the transparent sighash digests were recomputed per input rather than computed once per transaction. I reported it privately through ZF's GitHub security advisory process on 17 September 2026, and included a working, reproducible proof of concept: a transaction densely packed with signature-checking (stub-P2PK) inputs that, submitted to a live Zebra node, pinned the node's CPU for the duration of the quadratic hash work. ZF acknowledged on 19 September, reproduced the finding, and built the fix on top of it.

The fix. zcash_primitives 0.31.0 adds PrecomputedSighashData, which computes the ZIP-244 amounts and scripts digests once per transaction and reuses them for every input — reducing the cost from quadratic to linear. It also precomputes the ZIP-243 (v4 path) prevouts, sequence and outputs digests once per transaction. The fix shipped in Zebra v7.0.0 (released 22 October 2026), the release every node needs for NU7. The advisory was published the same day.

ZF's published description of the effect (from the advisory, verified verbatim): "The reporter measured roughly 1,700 CPU-seconds for one such transaction, which is about 7 minutes of stalled verification on a 4-core node and 14 minutes on a 2-core node," and "A mining node cannot verify new blocks during that time and its templates go stale." The advisory's credit line reads: "Reporter @asafmod; @x15-eth and @janneh2000 (independent rediscoveries)." The "reporter measured" figure in ZF's advisory is my measurement, from my proof of concept.

What this bug is not. It is an availability bug. As ZF's advisory says, it does not crash a node, corrupt state, split consensus or touch funds, and the effect stops when the attack stops. The case for paying it rests on reach and persistence: any peer, or any caller of sendrawtransaction, on every default node, for as long as the attacker likes — and a 2 MB transaction is cheap and reusable.

Why I'm bringing this here

• The work is finished, public, and checkable. ZF published the advisory on 22 October 2026, crediting me as reporter and quoting my measurement ("roughly 1,700 CPU-seconds… about 7 minutes of stalled verification on a 4-core node"). The fix shipped in Zebra v7.0.0 the same day.
• There's no other route to be paid for it. Zebra's SECURITY.md states ZF does "not currently operate a bug bounty program and do not pay for reports," and ZCG's disclosure program closed in May 2026.
• I did the patient version of disclosure. I reported privately on 17 September and kept the details confidential for five weeks until the fix shipped and operators had been told to upgrade. Retroactive recognition is what makes that patience a rational choice over publishing immediately or after an embargo period.

Basis for the $25,000 request

• One High advisory, three credited researchers: $75,000 ÷ 3 = $25,000.
• I'm not asking coinholders to set a price — ZCG's closed program already priced this class ("Non-distributed denial of service against an individual node or wallet") at $75,000 per Core Node High; I'm asking for my third of it.
• Splitting a payout across credited researchers has precedent: in Q3, coinholders funded a researcher's share of GHSA-8m29 alongside the original reporter's own claim ("Five Critical Zebra Consensus Divergence Vulnerabilities", 96% approval).

Technical Approach (how you did it)

I ran this review with Kimi 3 (Moonshot AI's model) as the research engine, and directed it. Rather than relying on unverified model output, I used it to trace the real code paths, to search for the strongest possible amplifiers of the cost, to build and run the demonstrations that confirmed or killed each lead, and to draft the report for the finding that survived.

My part:

1. I chose the target and the threat model — post-zcashd-EOL, Zebra is the main full node the Zcash network runs on, so unauthenticated per-peer cost amplification is the highest-value class of bug to hunt.
2. I traced the actual signing path through zcash_primitives' ZIP-244 implementation and identified that the transparent amounts_digest (BLAKE2b, personal ZTxTrAmountsHash) and scripts_digest (ZTxTrScriptsHash) were recomputed on every per-input sighash() call instead of once per transaction.
3. I searched for amplifiers that make the stall as long as possible. The cost per transaction grows with the square of the input count, so the attack hinges on maximizing inputs within the 2 MB transaction-size limit — i.e. minimizing bytes per input. I evaluated input constructions for the best cost-per-byte ratio: the winner was small stub-P2PK inputs (compact signatures spending short P2PK-style outputs), which pack roughly 39,000 inputs into a single at-most-2 MB transaction. That amplifier choice is what took the quadratic from a theoretical scaling flaw to a measurable, minutes-long stall — and ZF's advisory quotes the resulting measurement.
4. I confirmed it with a live demonstration, not a model's word. I built that 2 MB, ~39,000-input transaction and submitted it to a real Zebra node pinned to one core: the node's CPU stayed pinned for the length of the quadratic work. The demonstration was reproducible and used Zebra's real code paths, with honest transactions as the negative control (no cost amplification).
5. I reported privately and reproducibly through Zebra's private advisory process on 17 September 2026, with the full transaction construction so ZF could reproduce it — and kept the details private until the fix shipped on 22 October.
6. I verified the fix in zcash_primitives 0.31.0: PrecomputedSighashData computes the digests once per transaction and reuses them per input, restoring linear cost — on both the ZIP-244 (v5) and ZIP-243 (v4) paths.

Time Period of Work Completion

September–October 2026: reported privately 17 September 2026 (first private disclosure; acknowledged by ZF 19 September), independently rediscovered by two other researchers in early October, fixed in Zebra v7.0.0 and published as GHSA-j4cw-58mj-7w6v on 22 October 2026.

Total Budget (USD)

0

Budget Breakdown

• Compensation:
  • $(USD): 0
  • Justification: This is a bounty for a completed, accepted security outcome, valued as my equal share of ZCG's published Core Node schedule. It is not a reimbursement of hours.
• Technology/Software:
  • $(USD): 0
  • Justification: AI-assistant and compute costs are not claimed.
• Infrastructure/Hosting:
  • $(USD): 0
  • Justification: None claimed.
• Services/Contractors:
  • $(USD): 0
  • Justification: None.
• Other:
  • $(USD): 0
  • Justification: None.
• Total $(USD): 0 in costs. The $25,000 requested is my share of the outcome, per the basis above.

Previous Funding

No

Previous Funding Details

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

Other Funding Sources

No

Other Funding Sources Details

I have not received any payment, from any source, for GHSA-j4cw-58mj-7w6v. ZF does not operate a bug bounty program and did not pay for this report. If any payment for this advisory ever arises from another source, it will be disclosed and deducted dollar-for-dollar before disbursement.

Success Metrics

• Severity assigned by the remediation team: High, CVSS 3.1 7.5 (GHSA-j4cw-58mj-7w6v).
• Exposure: every zebrad release before 7.0.0, every default configuration; reachable by any connected peer or any caller of sendrawtransaction.
• Measured effect: a single at-most-2 MB transaction stalled block verification for about 7 minutes on a 4-core node (ZF's published figure); the work continued after rejection and no misbehavior score was assigned to the sender.
• Fix: O(N²) → O(N) per transaction via PrecomputedSighashData in zcash_primitives 0.31.0; shipped in Zebra v7.0.0, the NU7 release.
• The report was the first private disclosure of the issue, with a reproducible proof of concept ZF could run, five weeks before coordinated publication.
• The fix protects every Zebra operator on the network, and restores linear signing cost for both ZIP-244 (v5) and ZIP-243 (v4) transactions.

Proof of completion

• Publication (the security advisory itself, with credits and measured impact): GHSA-j4cw-58mj-7w6v — credit line: "Reporter @asafmod; @x15-eth and @janneh2000 (independent rediscoveries)". Severity High, CVSS 3.1 7.5, CWE-400 (Uncontrolled Resource Consumption). Affected: all zebrad < 7.0.0.
• Release/Deployment (the fix, shipped): Zebra v7.0.0 — released 22 October 2026, the NU7 release; fixes the vulnerability via zcash_primitives 0.31.0 (PrecomputedSighashData: digest computation O(N²) → O(N) per transaction).
• Other Evidence (timeline, all dates in ZF's advisory and private triage): reported privately 17 September 2026 via ZF's private security-advisary channel; acknowledged 19 September; independently rediscovered by two other researchers in early October; coordinated publication 22 October 2026.

Conflict of Interest Disclosure

None. I am an independent security researcher applying as an individual; I have no organizational affiliation, no funding relationship with FPF, ZF, ZCG, or any keyholder organization, and no role in the program's administration. For transparency: @x15-eth, also credited on this advisory, has filed his own application for his share this round (issue #79). I'm claiming only my reporter share; the two claims together total half the advisory's base payout.

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.