Closing the ZCG Vulnerability Bounty Program

Community Grants
67

Thank you for following up.

GHSA-pvmv-cwg8-v6c8 was reported independently by two researchers: @sangsoo on May 2 and @fivelittleducks on May 3. Both reports were correct, high-quality, and actionable, and both reporters were credited on the advisory and in the v4.4.1 release notes in recognition of their independent discovery.

Under the program terms, where multiple researchers report the same underlying issue, the reward goes to the disclosure that actually enables the team to begin remediation. @sangsoo’s report was received first and remediation was already underway when @fivelittleducks’ submission arrived the following day. Since @sangsoo’s disclosure was the one the team acted on to begin the fix, their report is the one eligible for the bounty payout. @fivelittleducks’ submission (GHSA-vwgm-g748-q95m) was classified as a duplicate accordingly.

We understand this is frustrating, particularly when the reports were only one day apart and both were high-quality independent discoveries of a genuine Critical vulnerability. We did incorrectly miss out GHSA-pvmv-cwg8-v6c8 from our report sent to ZCG and we’re following up with them to recommend payout.

2 Likes
69

Thank you for the detailed and transparent response, and for crediting the independent discovery in the advisory and the v4.4.1 release notes — both are appreciated.

I’d like to raise one point for your consideration. My submission was an independent, reproducible, and correct identification of a Critical issue, acknowledged as such in the advisory and release notes. You also noted that GHSA-pvmv-cwg8-v6c8 had been inadvertently omitted from the report sent to ZCG, and that you’re following up to recommend payout. In that same spirit, would ZF/ZCG be open to a partial or discretionary payout in recognition of an independent, high-quality Critical duplicate, rather than treating the classification as zero-value?

For context, the publicly visible timeline is:

  • 2026-05-01 15:11 UTC: PR #10510 was merged and shipped in v4.4.0. The PR described validation of the caller-provided input index and previous-output alignment, but it did not add the v5 SIGHASH_SINGLE corresponding-output guard. As of the public v4.4.0 release, the issue I reported was still present in shipped code.
  • 2026-05-03 10:22 UTC: I submitted GHSA-vwgm-g748-q95m, identifying that v4.4.0 still lacked the SIGHASH_SINGLE corresponding-output guard.
  • 2026-05-04 19:01 UTC: PR #10542 was opened, then merged at 20:09 UTC and released as v4.4.1 at 20:14 UTC. This was the public PR/release path that added the missing guard.
2 Likes
70

I had no insight or input into the ZCG Bounty program before its launch.

I did not evaluate your finding on Zaino.

Given that @AloeareV marked it “Moderate” severity and from the description, I believe that it was a valuable (though out-dated) finding.

That said, a bug that requires a malicious validator to cause a DOS in Zaino, doesn’t even meet the criteria of “vulnerability” if that criterion is intended to refer to a functional Zcash stack.

If you’re interested in contributing to the zaino project, it’s open source, and we accept thoughtful improvements to the codebase.

If you can produce a working demonstration of your bug that does NOT involve a malicious validator, I think that is more likely to qualify for a bounty. As I said, I had no input into the bounty program, so my opinion isn’t authoritative.

Thanks for your work on the Zcash ecosystem. I hope we can find ways to collaborate more efficiently going forward!

2 Likes
Zaino Release Stabilization
71

Thanks, both @hanh and @zancas.

I’ll keep this brief. This issue has already been triaged and accepted, so my main goal is to clarify where I think we’re talking past each other and leave the deeper discussion to the repository.

On the technical side, I think it’s reasonable to defer to the assessment of the Zaino maintainers who reviewed the report. @idky137 accepted the finding, rated it Medium severity (High in the context of a remote/untrusted validator connection), and explicitly confirmed that handle_reorg “recurses without a depth bound or visited set.” @AloeareV has also already prepared a fix for the recursion issue. The finding itself has been accepted, and the team’s current assessment is Medium severity.

On the two objections:
*“Malicious validator = out of warranty” scopes out the malicious case, but the advisory and the maintainer both say “malicious or buggy.” A buggy-but-honest Zebra isn’t the operator pouring diesel in the tank — it’s the upstream fault a downstream indexer is meant to absorb, which is why bounding the reorg walk is being fixed rather than waived. (The program’s High tier even names preserving “a defense-in-depth control that caps the blast radius of another class of defect.”)
*“Needs a malicious validator, so not a real vulnerability” is the same reasoning the team used to land it at Medium rather than Critical — a discount, not a disqualification.

On a fully validator-free trigger — fair ask, and I’d rather be precise than over-claim. The recursion DoS does need a malicious/buggy/MITM’d validator; I’ve never said otherwise. The expect("empty snapshot impossible") is validator-independent in principle, but in today’s code the entry guard in sync()(non_finalised_state.rs:368-386) plus the single-taskfs.sync_to_height→nfs.syncordering gate it in normal single-instance operation, so I won’tclaim a clean no-validator PoC. What’s accurate is what @AloeareV already said — the trimpath “isn’t deterministically unreachable,” and swapping thatexpectfora structured error is worthwhile hardening.

Net: one accepted Medium DoS with a fix, plus one latent expect being hardened.

72

@ZCG @artkor — following up on a Zcash-repository / zcashd report, separate from my earlier Zebra note above.

I am the reporter credited in the v6.12.3 release notes for GHSA-fqr9-fxpx-rfpf, which was remediated in zcashd v6.12.3. The advisory was published on 2026-05-08, and the report was submitted and disclosed during the ZCG Security Vulnerability Disclosure Initiative, before the program’s closure.

I understand from the earlier note that reports in the Zcash repository would be handled separately from the Zebra round once remediation is complete and public advisories can be properly coordinated.

To date, I have not received any contact, verification request, or status update regarding this report through email, GitHub, or the forum. I would just like to confirm:

1. Is GHSA-fqr9-fxpx-rfpf included in the separate Zcash-repository review process?

2. What is the appropriate administrative channel for this report, and what information do you need from me to proceed?

I am happy to provide whatever is required. Thanks for coordinating this.

1 Like
73

we’d appreciate it if ZCG could share any updates :eyes:

1 Like
75

Hi @ZCG,

I’m following up regarding my Zaino security reports, which have now all been published:

I’m credited as the reporting researcher on each GitHub advisory, and I also authored the corresponding fixes that have since been merged.

Since Zaino was in scope for the bug bounty program as supporting infrastructure, I’d appreciate confirmation of the next steps for the bounty process. Could you let me know whether @FPF or @ZCG will be handling the review and reward assignment for these reports, or if there’s anything further you need from me?

Thanks!

76

Hello @artkor

Is there an update on lightwalletd issues?

I have an accepted high severity and a medium one

1 Like
77

Also, my security report for Zebra has been published: Peer-Advertised Mempool Transactions Can Stall Tokio Workers via Synchronous Transparent Script FFI Before Policy Rejection · Advisory · ZcashFoundation/zebra · GitHub. I reported this issue while the bug bounty program was active and it is fixed in zebra-6-0-0-release @ZCG @artkor

78

Can someone clarify when I should expect a decision on my bounty payout?

Who is responsible for reviewing submissions and approving bounty payments?

My advisories have already been published, and the reported issues were submitted while the bounty program was still active, so they should fall within the program’s scope. I’ve also reached out to @ZCG and @artkor multiple times. I can see that my messages have been viewed, but I haven’t received any response.

At this point, the lack of communication is becoming difficult to understand. The purpose of a bounty program is to incentivize security researchers to responsibly disclose vulnerabilities. The issues were reported, acknowledged, and addressed, yet there still doesn’t appear to be any transparency around the review process or payout timeline.

I’d appreciate a clear timeline for the payout and a definitive answer, rather than continued silence and unanswered messages.

79

Well, I’ve decided not to reply to your private messages anymore, since you’re using them to make things public without my consent.

As for substantive responses, I’ve already shared my perspective on the vulnerabilities in Zaino, and besides, ZCG hasn’t received any additional updates from the teams working on the infrastructure, so I don’t really have anything else to add.

Speaking for myself, I can say that this sort of exchange doesn’t encourage me to reply: whenever I do reply, I’m immediately bombarded with the same questions, just rephrased. I don’t see any point in this sort of interaction. And even if you write about this more often, the situation is unlikely to change.

80

I want to consolidate everything into one clear, factual message so we can close this out with a definitive answer rather than another round of back-and-forth @artkor.

**First, on Zaino being “not yet ready for use.”** With respect, that is not a criterion in the program. The terms explicitly list Zaino:

Supporting Infrastructure — Zallet, Zaino, and lightwalletd. Findings are capped at High, since defects in these repositories cannot by themselves directly break a core tenet at scale.

Zaino is named as in scope, and the **High cap is precisely how the program already accounts for its role** in the stack. There is no clause anywhere excluding a repository because it is pre-production or because no team has adopted it yet. Introducing that condition now — after the reports were submitted, accepted, remediated, and publicly disclosed — is adding a requirement that was never part of the terms I reported under.

**Second, on severity.** I am not asking anyone to take my word on severity. The program states that *“severity is assigned by the remediation team and/or technical reviewers.”* The Zaino maintainers reviewed these reports, **accepted** them, and assigned the ratings themselves; the corresponding fixes have been merged. These were not my self-assessments. So the findings cannot be waved away as unqualified — they were validated and rated by the people the program designates for exactly that.

**Third, these are exactly the conditions you previously said were required.** You said additional reports would be *“handled separately … once remediation is complete and public advisories can be properly coordinated,”* and that you would bring a contribution to ZCG once the lead developers acknowledged it in updates. That has now happened: the advisories are public, I am credited on each, and the fixes are merged. “ZCG hasn’t received updates from the infra teams” is no longer accurate — **the public advisories are the update.**

For reference, my in-scope, now-public advisories include:

**Zaino:**
- [GHSA-55pv-cqqp-mwj3](Validator Fork Acceptance — Height Equality Used as Sync Truth (No Hash/Work Check) · Advisory · zingolabs/zaino · GitHub)

- [GHSA-h268-r3v6-jqj6](`get_treestate` Proxies Arbitrary Hashes to Validator Without Validation · Advisory · zingolabs/zaino · GitHub)

- [GHSA-j3f2-h3wv-wfr9](`send_raw_transaction` Forwards Unvalidated Hex to Validator · Advisory · zingolabs/zaino · GitHub)

- [GHSA-3whf-vgf2-9w6g](Non-Finalized State Reorg — No Cycle Detection or Depth Limit · Advisory · zingolabs/zaino · GitHub)

**Zebra:**

- [GHSA-84j3-rw4c-gqmj](Peer-Advertised Mempool Transactions Can Stall Tokio Workers via Synchronous Transparent Script FFI Before Policy Rejection · Advisory · ZcashFoundation/zebra · GitHub) (fixed in zebra-6.0.0) @ZcashFoundation

Each was submitted while the program was active, and the closure announcement is explicit that *“reports already submitted before this announcement will be handled under the terms that applied at the time of submission.”*

**Fourth, the “making things public without my consent” point.** The only private message I have ever received from you is your 2 June note:

Hello @ouicate! Please give it a little time. Someone authorized to handle the ZCG reward process will contact you directly with the next steps. Thanks for your patience.

That message contains no confidential information — no technical details, no personal data, nothing sensitive — only a procedural reassurance that someone would contact me. If quoting that single line is what you mean by “making things public without my consent,” please say so directly. If you mean something else, please identify specifically what I disclosed that was not appropriate to share. I don’t think it’s fair to frame a request for a status update as a breach of trust — especially when, more than six weeks later, that 2 June note is still the only substantive thing I have been told.

I’ve engaged in good faith throughout: reported responsibly, worked through remediation, and in the Zaino cases authored the merged fixes myself. I’m simply asking the program to be applied as written. A clear timeline would let us close this cleanly.

81

  1. @ZCG @artkor — following up on my June 25 post above regarding my zcashd (Zcash repository) report, which has not received a response yet. This is separate from my earlier Zebra notes. I am raising it again today because zcashd reaches end of support on July 18, and I want to make sure this report does not fall through the cracks during the transition. I am the reporter credited in the zcashd v6.12.3 release notes for GHSA-fqr9-fxpx-rfpf: “The vulnerability was reported under the ZCG Security Vulnerability Disclosure Initiative by fivelittleducks.” The report was submitted through the program before its closure, and the advisory was published on 2026-05-08. My understanding from earlier in this thread is that Zcash-repository reports would be handled separately from the Zebra round once remediation was complete and public advisories could be properly coordinated. With v6.12.3 released and the advisory public for over two months, both conditions appear to be met. I would like to confirm:

    1. Is GHSA-fqr9-fxpx-rfpf included in the separate Zcash-repository review process, and is there a rough timeline reporters should expect?

    2. What is the appropriate administrative channel, and what information do you need from me to proceed?

    @nuttycom — apologies for the direct ping; one narrow question for the maintainers’ side, since the wind-down is imminent: could you confirm whether the zcashd team’s summary of qualifying reports — including GHSA-fqr9-fxpx-rfpf — has been handed over to ZCG for that separate review, or if not, whether the handoff can be completed before the team stands down? I understand payout decisions rest entirely with ZCG; this is only about the handoff.

  2. For identity verification, whatever is convenient works: the email address used for the original submission, the GitHub account credited in the advisory, or a DM to the X account listed on my GitHub profile. Even a simple acknowledgment that the report is in the queue would be appreciated. Thanks for coordinating this.

82

The report will not fall through the cracks. But speaking for myself, I have no bandwidth at all to deal with this until after NU6.3 activation on the 28th.

3 Likes
83

Are you saying researchers who found accepted vulnerabilities in the supporting infrastructure codebases wouldn’t get paid?

84

Hi @ZCG @artkor @FPF — a quick, friendly update: the last of my reported issues are now published, so the full set is public, credited, and remediated. Flagging that these are all still pending on the bounty side.

Newly published:

Zaino:

Zebra:

All of these were submitted while the program was active, so under the closure note they fall under “the terms that applied at the time of submission” — and each is now at exactly the stage you described as the trigger: publicly disclosed, credited, and fixed. At this point they’re simply waiting on review and payout.

Could you confirm the next step and a rough timeline? I’m glad to send whatever you need so this is quick and easy to close out. Thanks for pulling all of this together — I really appreciate the work involved.

1 Like