Summary

A soundness vulnerability in the variable-base scalar multiplication gadget of halo2_gadgets allowed a malicious prover to produce a valid proof for an Orchard Action with an under-constrained base point. Because this gadget enforces the diversified-address-integrity condition of the Orchard Action statement, the flaw let a prover satisfy that condition for an arbitrary (pkd, gd, ivk) triple, effectively bypassing the check that binds an Action to the correct incoming viewing key — and therefore to the correct nullifier (nf) and spend validating key (ak) — of the note being spent.

The main practical consequence is that an adversary could have performed a double-spend within the Orchard pool, resulting in a balance violation: the same note could be spent multiple times, each time revealing a distinct, valid-looking nullifier. The total ZEC supply was protected by Zcash's turnstile mechanism, which bounds value flowing out of any pool, so unbounded inflation of the overall supply was not possible; the exposure was inflation of value within the Orchard pool up to the turnstile-enforced limit.

Exploiting the vulnerability via a double-spend is undetectable on-chain. Exploitation only requires setting private circuit inputs to chosen values, and nullifiers produced by a double-spend are indistinguishable from honest nullifiers, so the zero-knowledge property hides any signature of the attack.

Alternatively, an adversary could (before the fix) have stolen funds by forging a spend authorization for an existing note. To do so they would have to know the note plaintext, which in practice they might obtain by knowing the corresponding incoming viewing key. For example, this could be used to bypass the protection provided by holding spending keys on a hardware wallet, if the linked software wallet were compromised. This form of exploitation cannot be detected via the turnstile (which might be a motivation to exploit the vulnerability in this way rather than via balance violation). It can be detected by the legitimate holder of stolen funds being unable to spend them, or by seeing the note's nullifier on-chain — but this cannot necessarily be distinguished from compromise of the spending key by other means.

The vulnerability has existed since the Orchard pool was introduced in the NU5 network upgrade (activated May 31, 2022). There is no evidence it was exploited prior to remediation.

Note that use of the vulnerability, either for balance violation or for theft of funds, would need to have occurred before it was remediated. Theft would be in principle detectable from that point (since the real nullifier would appear on-chain). Balance violation would not be detectable at the point of exploitation.

Root cause

The defect is in the double-and-add implementation of variable-base scalar multiplication in halo2_gadgets/src/ecc/chip/mul/incomplete.rs. For performance, the algorithm uses incomplete point-addition formulas in its intermediate stage. (Incomplete addition is safe here in principle: the first and last stages use complete addition, and reaching a degenerate case would require breaking discrete log.)

The base point is fed into the incomplete-addition stage via assign_advice(), which assigns a witness value (a private circuit input) without introducing a constraint that ties that value to the actual base the algorithm is supposed to operate on:

region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?;
region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?;

(halo2_gadgets/src/ecc/chip/mul/incomplete.rs, around L309–L310 at commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea.)

The existing q_mul_2 constraint forces the base values used across the incomplete-addition loop to be equal to one another, but nothing forces them to equal the actual base. A malicious prover therefore has complete freedom to choose the base used by the loop. Given target pkd, gd, and ivk, the prover can solve for the base value that makes the computed [ivk] gd equal the desired pkd, satisfying the diversified-address-integrity equation pkdold = [ivk] gdold for inputs that an honest prover could never satisfy.

Why this enables a double-spend

The Orchard Action statement constrains the nullifier of the spent note to be derived from the correct nullifier key nk, which in turn is bound to the correct incoming viewing key ivk, via ivk = Commitivkrivk(Extractℙ(akℙ), nk). The diversified-address-integrity check pkd = [ivk] gd is what normally guarantees the prover used the correct ivk —and hence the correct nk— for the note. With that check bypassable:

1. The prover picks a fresh, incorrect nk for the note being spent. Since nk feeds the nullifier computation, a wrong nk yields a different nullifier for the same note.
2. Other circuit constraints still force the prover to derive ivk honestly from that wrong nk, producing a wrong ivk for the note — which would normally be caught by the integrity check.
3. The prover uses the under-constrained base to satisfy pkd = [ivk] gd anyway, defeating the check.
4. Each distinct wrong nk produces a distinct valid nullifier, allowing the note to be spent repeatedly.

Why this enables theft

The spend validating key, akℙ (essentially equivalent to ak), is also constrained via ivk = Commitivkrivk(Extractℙ(akℙ), nk). As above, the diversified-address-integrity check is what normally guarantees the prover used the correct ivk —and hence the correct ak— for the note. With that check bypassable:

1. The prover picks an ak for which they know the private key, ask.
2. They construct a transaction that spends the victim's notes, and sign it using that ask.

Impact

• Integrity: High. A malicious prover could spend Orchard notes multiple times, inflating value within the Orchard pool. This is bounded only by the turnstile limit on the pool. Alternatively, the prover could authorize spending other users' notes without having the spending key.
• Confidentiality: None. The zero-knowledge property is intact; no private data is disclosed. This is also why the attack leaves no observable on-chain signature.
• Availability: Not directly affected by the bug. (The coordinated response temporarily disabled Orchard actions as a mitigation; that was an operational choice, not an effect of the vulnerability.) On the other hand, either theft of funds, or inability to spend funds due to a future turnstile violation could be considered an availability consequence.

Affected versions

• halo2_gadgets < 0.5.0
• orchard < 0.14.0
• zcash_primitives < 0.28.0
• zcashd < 6.20.0
• zebrad < 5.0.0

Patches

The circuit-level fix replaces the first-iteration assign_advice() calls for the base point with copy_advice(), introducing a copy constraint that requires the first base value to equal the correct base. Combined with the existing q_mul_2 equality constraint across the loop, this transitively constrains every base value in the incomplete-addition stage to the correct base, closing the freedom the attacker relied on.

Because remediating a zero-knowledge circuit changes the pinned verifying key, the network-level fix required a hard fork (NU6.2). NU6.2 re-enables Orchard with the corrected circuit and routes Orchard proofs to a per-circuit verifying key (InsecurePreNu6_2 / FixedPostNu6_2).

• halo2_gadgets 0.5.0
• orchard 0.14.0
• zcash_primitives 0.28.0
• zebrad 5.0.0 (NU6.2); 4.5.3 ships the interim soft-fork mitigation
• zcashd 6.20.0 (NU6.2)

Workarounds / mitigations

There is no client-side workaround for the underlying soundness flaw short of the circuit fix. The deployed interim mitigation (Zebra 4.5.3 / equivalent) was a soft fork that rejected all Orchard-containing transactions and blocks, fully neutralizing exploitation until NU6.2 activated.

Downstream projects that depend on the affected crates should:

• Upgrade halo2_gadgets, orchard, and zcash_primitives to the patched versions above.
• Audit any other use of assign_advice() (and similar non-constraining assignment APIs) where the intended invariant is that a witnessed value equals a known/fixed value; such sites should use copy_advice() (or otherwise enforce an explicit constraint).

Indicators / detection

Exploitation produces no distinguishing on-chain signature. The turnstile mechanism, which tracks total ZEC across all value pools, provides a ground-truth supply check and confirmed the total supply remained intact. Heuristic analysis of Orchard transaction arity (e.g. patterns of duplicate-then-consolidate behavior) is possible but inconclusive against normal shielded-activity variance.

Timeline (MDT)

| Date / Time | Event | |---|---| | 2022-05-31 11:50 | Vulnerable NU5 upgrade activates (bug introduced) | | 2026-05-29 (evening) | Vulnerability discovered during a protocol audit | | 2026-05-29 23:53 | Responsibly disclosed to ZODL core engineers | | 2026-05-30 06:30 | Disclosure acknowledged by ZODL | | 2026-06-01 (~21:30) | Emergency soft-fork mitigation activated (block 3,363,426) | | 2026-06-03 00:05 EDT | NU6.2 hard fork activates, Orchard re-enabled with fix (block 3,364,600) |

Credits

Discovered and responsibly disclosed by Taylor Hornby, independent security researcher, during a protocol audit conducted on behalf of Shielded Labs. Analysis and remediation was led by ZODL engineers Jack Grigg, Daira-Emma Hopwood, and Kris Nuttycombe, with Zebra patch work by Arya Solhi (Zcash Foundation).

Resources

• Zcash Foundation: Zebra 4.5.3 and 5.0.0: Emergency Soft Fork and NU6.2 Activation — https://zfnd.org/zebra-4-5-3-and-5-0-0-emergency-soft-fork-and-nu6-2-activation/
• Affected source (pre-fix): halo2_gadgets/src/ecc/chip/mul/incomplete.rs @ commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea, L309–L310

Summary

A soundness vulnerability in the variable-base scalar multiplication gadget of halo2_gadgets allowed a malicious prover to produce a valid proof for an Orchard Action with an under-constrained base point. Because this gadget enforces the diversified-address-integrity condition of the Orchard Action statement, the flaw let a prover satisfy that condition for an arbitrary (pkd, gd, ivk) triple, effectively bypassing the check that binds an Action to the correct incoming viewing key — and therefore to the correct nullifier (nf) and spend validating key (ak) — of the note being spent.

The main practical consequence is that an adversary could have performed a double-spend within the Orchard pool, resulting in a balance violation: the same note could be spent multiple times, each time revealing a distinct, valid-looking nullifier. The total ZEC supply was protected by Zcash's turnstile mechanism, which bounds value flowing out of any pool, so unbounded inflation of the overall supply was not possible; the exposure was inflation of value within the Orchard pool up to the turnstile-enforced limit.

Exploiting the vulnerability via a double-spend is undetectable on-chain. Exploitation only requires setting private circuit inputs to chosen values, and nullifiers produced by a double-spend are indistinguishable from honest nullifiers, so the zero-knowledge property hides any signature of the attack.

Alternatively, an adversary could (before the fix) have stolen funds by forging a spend authorization for an existing note. To do so they would have to know the note plaintext, which in practice they might obtain by knowing the corresponding incoming viewing key. For example, this could be used to bypass the protection provided by holding spending keys on a hardware wallet, if the linked software wallet were compromised. This form of exploitation cannot be detected via the turnstile (which might be a motivation to exploit the vulnerability in this way rather than via balance violation). It can be detected by the legitimate holder of stolen funds being unable to spend them, or by seeing the note's nullifier on-chain — but this cannot necessarily be distinguished from compromise of the spending key by other means.

The vulnerability has existed since the Orchard pool was introduced in the NU5 network upgrade (activated May 31, 2022). There is no evidence it was exploited prior to remediation.

Note that use of the vulnerability, either for balance violation or for theft of funds, would need to have occurred before it was remediated. Theft would be in principle detectable from that point (since the real nullifier would appear on-chain). Balance violation would not be detectable at the point of exploitation.

Root cause

The defect is in the double-and-add implementation of variable-base scalar multiplication in halo2_gadgets/src/ecc/chip/mul/incomplete.rs. For performance, the algorithm uses incomplete point-addition formulas in its intermediate stage. (Incomplete addition is safe here in principle: the first and last stages use complete addition, and reaching a degenerate case would require breaking discrete log.)

The base point is fed into the incomplete-addition stage via assign_advice(), which assigns a witness value (a private circuit input) without introducing a constraint that ties that value to the actual base the algorithm is supposed to operate on:

region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?;
region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?;

(halo2_gadgets/src/ecc/chip/mul/incomplete.rs, around L309–L310 at commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea.)

The existing q_mul_2 constraint forces the base values used across the incomplete-addition loop to be equal to one another, but nothing forces them to equal the actual base. A malicious prover therefore has complete freedom to choose the base used by the loop. Given target pkd, gd, and ivk, the prover can solve for the base value that makes the computed [ivk] gd equal the desired pkd, satisfying the diversified-address-integrity equation pkdold = [ivk] gdold for inputs that an honest prover could never satisfy.

Why this enables a double-spend

The Orchard Action statement constrains the nullifier of the spent note to be derived from the correct nullifier key nk, which in turn is bound to the correct incoming viewing key ivk, via ivk = Commitivkrivk(Extractℙ(akℙ), nk). The diversified-address-integrity check pkd = [ivk] gd is what normally guarantees the prover used the correct ivk —and hence the correct nk— for the note. With that check bypassable:

1. The prover picks a fresh, incorrect nk for the note being spent. Since nk feeds the nullifier computation, a wrong nk yields a different nullifier for the same note.
2. Other circuit constraints still force the prover to derive ivk honestly from that wrong nk, producing a wrong ivk for the note — which would normally be caught by the integrity check.
3. The prover uses the under-constrained base to satisfy pkd = [ivk] gd anyway, defeating the check.
4. Each distinct wrong nk produces a distinct valid nullifier, allowing the note to be spent repeatedly.

Why this enables theft

The spend validating key, akℙ (essentially equivalent to ak), is also constrained via ivk = Commitivkrivk(Extractℙ(akℙ), nk). As above, the diversified-address-integrity check is what normally guarantees the prover used the correct ivk —and hence the correct ak— for the note. With that check bypassable:

1. The prover picks an ak for which they know the private key, ask.
2. They construct a transaction that spends the victim's notes, and sign it using that ask.

Impact

• Integrity: High. A malicious prover could spend Orchard notes multiple times, inflating value within the Orchard pool. This is bounded only by the turnstile limit on the pool. Alternatively, the prover could authorize spending other users' notes without having the spending key.
• Confidentiality: None. The zero-knowledge property is intact; no private data is disclosed. This is also why the attack leaves no observable on-chain signature.
• Availability: Not directly affected by the bug. (The coordinated response temporarily disabled Orchard actions as a mitigation; that was an operational choice, not an effect of the vulnerability.) On the other hand, either theft of funds, or inability to spend funds due to a future turnstile violation could be considered an availability consequence.

Affected versions

• halo2_gadgets < 0.5.0
• orchard < 0.14.0
• zcash_primitives < 0.28.0
• zcashd < 6.20.0
• zebrad < 5.0.0

Patches

The circuit-level fix replaces the first-iteration assign_advice() calls for the base point with copy_advice(), introducing a copy constraint that requires the first base value to equal the correct base. Combined with the existing q_mul_2 equality constraint across the loop, this transitively constrains every base value in the incomplete-addition stage to the correct base, closing the freedom the attacker relied on.

Because remediating a zero-knowledge circuit changes the pinned verifying key, the network-level fix required a hard fork (NU6.2). NU6.2 re-enables Orchard with the corrected circuit and routes Orchard proofs to a per-circuit verifying key (InsecurePreNu6_2 / FixedPostNu6_2).

• halo2_gadgets 0.5.0
• orchard 0.14.0
• zcash_primitives 0.28.0
• zebrad 5.0.0 (NU6.2); 4.5.3 ships the interim soft-fork mitigation
• zcashd 6.20.0 (NU6.2)

Workarounds / mitigations

There is no client-side workaround for the underlying soundness flaw short of the circuit fix. The deployed interim mitigation (Zebra 4.5.3 / equivalent) was a soft fork that rejected all Orchard-containing transactions and blocks, fully neutralizing exploitation until NU6.2 activated.

Downstream projects that depend on the affected crates should:

• Upgrade halo2_gadgets, orchard, and zcash_primitives to the patched versions above.
• Audit any other use of assign_advice() (and similar non-constraining assignment APIs) where the intended invariant is that a witnessed value equals a known/fixed value; such sites should use copy_advice() (or otherwise enforce an explicit constraint).

Indicators / detection

Exploitation produces no distinguishing on-chain signature. The turnstile mechanism, which tracks total ZEC across all value pools, provides a ground-truth supply check and confirmed the total supply remained intact. Heuristic analysis of Orchard transaction arity (e.g. patterns of duplicate-then-consolidate behavior) is possible but inconclusive against normal shielded-activity variance.

Timeline (MDT)

| Date / Time | Event | |---|---| | 2022-05-31 11:50 | Vulnerable NU5 upgrade activates (bug introduced) | | 2026-05-29 (evening) | Vulnerability discovered during a protocol audit | | 2026-05-29 23:53 | Responsibly disclosed to ZODL core engineers | | 2026-05-30 06:30 | Disclosure acknowledged by ZODL | | 2026-06-01 (~21:30) | Emergency soft-fork mitigation activated (block 3,363,426) | | 2026-06-03 00:05 EDT | NU6.2 hard fork activates, Orchard re-enabled with fix (block 3,364,600) |

Credits

Discovered and responsibly disclosed by Taylor Hornby, independent security researcher, during a protocol audit conducted on behalf of Shielded Labs. Analysis and remediation was led by ZODL engineers Jack Grigg, Daira-Emma Hopwood, and Kris Nuttycombe, with Zebra patch work by Arya Solhi (Zcash Foundation).

Resources

• Zcash Foundation: Zebra 4.5.3 and 5.0.0: Emergency Soft Fork and NU6.2 Activation — https://zfnd.org/zebra-4-5-3-and-5-0-0-emergency-soft-fork-and-nu6-2-activation/
• Affected source (pre-fix): halo2_gadgets/src/ecc/chip/mul/incomplete.rs @ commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea, L309–L310

Summary

A soundness vulnerability in the variable-base scalar multiplication gadget of halo2_gadgets allowed a malicious prover to produce a valid proof for an Orchard Action with an under-constrained base point. Because this gadget enforces the diversified-address-integrity condition of the Orchard Action statement, the flaw let a prover satisfy that condition for an arbitrary (pkd, gd, ivk) triple, effectively bypassing the check that binds an Action to the correct incoming viewing key — and therefore to the correct nullifier (nf) and spend validating key (ak) — of the note being spent.

The main practical consequence is that an adversary could have performed a double-spend within the Orchard pool, resulting in a balance violation: the same note could be spent multiple times, each time revealing a distinct, valid-looking nullifier. The total ZEC supply was protected by Zcash's turnstile mechanism, which bounds value flowing out of any pool, so unbounded inflation of the overall supply was not possible; the exposure was inflation of value within the Orchard pool up to the turnstile-enforced limit.

Exploiting the vulnerability via a double-spend is undetectable on-chain. Exploitation only requires setting private circuit inputs to chosen values, and nullifiers produced by a double-spend are indistinguishable from honest nullifiers, so the zero-knowledge property hides any signature of the attack.

Alternatively, an adversary could (before the fix) have stolen funds by forging a spend authorization for an existing note. To do so they would have to know the note plaintext, which in practice they might obtain by knowing the corresponding incoming viewing key. For example, this could be used to bypass the protection provided by holding spending keys on a hardware wallet, if the linked software wallet were compromised. This form of exploitation cannot be detected via the turnstile (which might be a motivation to exploit the vulnerability in this way rather than via balance violation). It can be detected by the legitimate holder of stolen funds being unable to spend them, or by seeing the note's nullifier on-chain — but this cannot necessarily be distinguished from compromise of the spending key by other means.

The vulnerability has existed since the Orchard pool was introduced in the NU5 network upgrade (activated May 31, 2022). There is no evidence it was exploited prior to remediation.

Note that use of the vulnerability, either for balance violation or for theft of funds, would need to have occurred before it was remediated. Theft would be in principle detectable from that point (since the real nullifier would appear on-chain). Balance violation would not be detectable at the point of exploitation.

Root cause

The defect is in the double-and-add implementation of variable-base scalar multiplication in halo2_gadgets/src/ecc/chip/mul/incomplete.rs. For performance, the algorithm uses incomplete point-addition formulas in its intermediate stage. (Incomplete addition is safe here in principle: the first and last stages use complete addition, and reaching a degenerate case would require breaking discrete log.)

The base point is fed into the incomplete-addition stage via assign_advice(), which assigns a witness value (a private circuit input) without introducing a constraint that ties that value to the actual base the algorithm is supposed to operate on:

region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?;
region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?;

(halo2_gadgets/src/ecc/chip/mul/incomplete.rs, around L309–L310 at commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea.)

The existing q_mul_2 constraint forces the base values used across the incomplete-addition loop to be equal to one another, but nothing forces them to equal the actual base. A malicious prover therefore has complete freedom to choose the base used by the loop. Given target pkd, gd, and ivk, the prover can solve for the base value that makes the computed [ivk] gd equal the desired pkd, satisfying the diversified-address-integrity equation pkdold = [ivk] gdold for inputs that an honest prover could never satisfy.

Why this enables a double-spend

The Orchard Action statement constrains the nullifier of the spent note to be derived from the correct nullifier key nk, which in turn is bound to the correct incoming viewing key ivk, via ivk = Commitivkrivk(Extractℙ(akℙ), nk). The diversified-address-integrity check pkd = [ivk] gd is what normally guarantees the prover used the correct ivk —and hence the correct nk— for the note. With that check bypassable:

1. The prover picks a fresh, incorrect nk for the note being spent. Since nk feeds the nullifier computation, a wrong nk yields a different nullifier for the same note.
2. Other circuit constraints still force the prover to derive ivk honestly from that wrong nk, producing a wrong ivk for the note — which would normally be caught by the integrity check.
3. The prover uses the under-constrained base to satisfy pkd = [ivk] gd anyway, defeating the check.
4. Each distinct wrong nk produces a distinct valid nullifier, allowing the note to be spent repeatedly.

Why this enables theft

The spend validating key, akℙ (essentially equivalent to ak), is also constrained via ivk = Commitivkrivk(Extractℙ(akℙ), nk). As above, the diversified-address-integrity check is what normally guarantees the prover used the correct ivk —and hence the correct ak— for the note. With that check bypassable:

1. The prover picks an ak for which they know the private key, ask.
2. They construct a transaction that spends the victim's notes, and sign it using that ask.

Impact

• Integrity: High. A malicious prover could spend Orchard notes multiple times, inflating value within the Orchard pool. This is bounded only by the turnstile limit on the pool. Alternatively, the prover could authorize spending other users' notes without having the spending key.
• Confidentiality: None. The zero-knowledge property is intact; no private data is disclosed. This is also why the attack leaves no observable on-chain signature.
• Availability: Not directly affected by the bug. (The coordinated response temporarily disabled Orchard actions as a mitigation; that was an operational choice, not an effect of the vulnerability.) On the other hand, either theft of funds, or inability to spend funds due to a future turnstile violation could be considered an availability consequence.

Affected versions

• halo2_gadgets < 0.5.0
• orchard < 0.14.0
• zcash_primitives < 0.28.0
• zcashd < 6.20.0
• zebrad < 5.0.0

Patches

The circuit-level fix replaces the first-iteration assign_advice() calls for the base point with copy_advice(), introducing a copy constraint that requires the first base value to equal the correct base. Combined with the existing q_mul_2 equality constraint across the loop, this transitively constrains every base value in the incomplete-addition stage to the correct base, closing the freedom the attacker relied on.

Because remediating a zero-knowledge circuit changes the pinned verifying key, the network-level fix required a hard fork (NU6.2). NU6.2 re-enables Orchard with the corrected circuit and routes Orchard proofs to a per-circuit verifying key (InsecurePreNu6_2 / FixedPostNu6_2).

• halo2_gadgets 0.5.0
• orchard 0.14.0
• zcash_primitives 0.28.0
• zebrad 5.0.0 (NU6.2); 4.5.3 ships the interim soft-fork mitigation
• zcashd 6.20.0 (NU6.2)

Workarounds / mitigations

There is no client-side workaround for the underlying soundness flaw short of the circuit fix. The deployed interim mitigation (Zebra 4.5.3 / equivalent) was a soft fork that rejected all Orchard-containing transactions and blocks, fully neutralizing exploitation until NU6.2 activated.

Downstream projects that depend on the affected crates should:

• Upgrade halo2_gadgets, orchard, and zcash_primitives to the patched versions above.
• Audit any other use of assign_advice() (and similar non-constraining assignment APIs) where the intended invariant is that a witnessed value equals a known/fixed value; such sites should use copy_advice() (or otherwise enforce an explicit constraint).

Indicators / detection

Exploitation produces no distinguishing on-chain signature. The turnstile mechanism, which tracks total ZEC across all value pools, provides a ground-truth supply check and confirmed the total supply remained intact. Heuristic analysis of Orchard transaction arity (e.g. patterns of duplicate-then-consolidate behavior) is possible but inconclusive against normal shielded-activity variance.

Timeline (MDT)

| Date / Time | Event | |---|---| | 2022-05-31 11:50 | Vulnerable NU5 upgrade activates (bug introduced) | | 2026-05-29 (evening) | Vulnerability discovered during a protocol audit | | 2026-05-29 23:53 | Responsibly disclosed to ZODL core engineers | | 2026-05-30 06:30 | Disclosure acknowledged by ZODL | | 2026-06-01 (~21:30) | Emergency soft-fork mitigation activated (block 3,363,426) | | 2026-06-03 00:05 EDT | NU6.2 hard fork activates, Orchard re-enabled with fix (block 3,364,600) |

Credits

Discovered and responsibly disclosed by Taylor Hornby, independent security researcher, during a protocol audit conducted on behalf of Shielded Labs. Analysis and remediation was led by ZODL engineers Jack Grigg, Daira-Emma Hopwood, and Kris Nuttycombe, with Zebra patch work by Arya Solhi (Zcash Foundation).

Resources

• Zcash Foundation: Zebra 4.5.3 and 5.0.0: Emergency Soft Fork and NU6.2 Activation — https://zfnd.org/zebra-4-5-3-and-5-0-0-emergency-soft-fork-and-nu6-2-activation/
• Affected source (pre-fix): halo2_gadgets/src/ecc/chip/mul/incomplete.rs @ commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea, L309–L310

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node listens on the default [::] address on a Linux host (the standard deployment configuration — net.ipv6.bindv6only=0 is the default on all common Linux distributions).
3. Your node is synced near the chain tip (the expected production state for any node participating in the network).

Summary

An address normalization mismatch between the handshake path and the mempool misbehavior path causes a deterministic assertion panic when a peer connects via IPv4 to a dual-stack IPv6 listener and then triggers a mempool misbehavior penalty.

The handshake path canonicalizes IPv4-mapped IPv6 addresses to plain IPv4 when storing the peer in the address book via MetaAddr::new_connected. The mempool misbehavior path forwards the raw transient socket address (IPv4-mapped IPv6 form) when sending MetaAddrChange::UpdateMisbehavior to the address book. The address book looks up the canonical IPv4 entry but then asserts that the previous entry's address matches the change's address. The mismatch between the canonical IPv4 address and the raw IPv4-mapped IPv6 address triggers the assertion, and panic = "abort" terminates the process.

Details

On Linux with net.ipv6.bindv6only=0, an IPv4 connection accepted by a [::] listener is represented internally as an IPv4-mapped IPv6 socket address (e.g., ::ffff:127.0.0.1:8233). Zebra's canonical_peer_addr helper converts these to plain IPv4 (e.g., 127.0.0.1:8233).

The handshake path uses MetaAddr::new_connected, which canonicalizes the address before storing in the address book. However, inbound inventory registration uses connected_addr.get_transient_addr(), preserving the raw IPv4-mapped form. When the mempool later downloads an invalid transaction from this peer and generates a misbehavior penalty, the raw transient address is forwarded through the misbehavior channel to MetaAddrChange::UpdateMisbehavior, which does not canonicalize.

After the 30-second misbehavior batch flush, AddressBook::update retrieves the canonical IPv4 entry but MetaAddrChange::apply_to_meta_addr asserts that previous.addr == self.addr(), which fails because one is IPv4 and the other is IPv4-mapped IPv6.

The attacker needs only to complete a P2P handshake over IPv4 to a dual-stack listener and advertise an invalid mempool transaction (such as a coinbase transaction). The assertion fires after the 30-second misbehavior batch flush.

Patches

Patched in Zebra 4.5.0. The fix canonicalizes the address in the misbehavior update path via a new MetaAddr::new_misbehavior constructor that applies canonical_peer_addr before creating the UpdateMisbehavior change.

Workarounds

Configuring listen_addr to an IPv4-only address (e.g., 0.0.0.0:8233) avoids the IPv4-mapped IPv6 representation and prevents this specific assertion. Alternatively, setting net.ipv6.bindv6only=1 on Linux prevents dual-stack acceptance.

Impact

A remote unauthenticated peer can deterministically crash any synced Zebra node running the default Linux dual-stack configuration with a single invalid mempool transaction advertisement, followed by a 30-second wait. The attack requires no mining capability, no RPC access, no funds, and no special privileges. The crash can be repeated after each restart, causing persistent downtime. Linux dual-stack sockets and mempool activation are the default production state, not special preconditions.

Credit

Reported by @Haxatron.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

Summary

The mempool download pipeline's cancel_handles map retains entries for transactions whose verification times out at the outer RATE_LIMIT_DELAY (73-second) boundary. The tokio::time::error::Elapsed error carries no payload, so the transaction ID is unrecoverable and the corresponding cancel_handles entry (including the full Gossip::Tx(UnminedTx), up to ~2 MB) is never removed. Entries accumulate monotonically with no upper bound or garbage collection, leading to eventual out-of-memory process termination.

Details

Downloads::poll_next() at zebrad/src/components/mempool/downloads.rs:215-228 handles three terminal states for a verification task:

• Ok(Ok(...)): success. Calls cancel_handles.remove(&tx.transaction.id). Correct.
• Ok(Err(...)): verification error. Calls cancel_handles.remove(&hash). Correct.
• Err(elapsed): outer timeout. Returns Err(elapsed) without removing anything. Bug.

tokio::time::error::Elapsed has no payload, so the timed-out transaction's UnminedTxId is unrecoverable from the error. The consumer at zebrad/src/components/mempool.rs:663-672 explicitly acknowledges this gap with a TODO comment.

The only cleanup paths for cancel_handles are cancel(mined_ids) (removes entries matching mined transaction IDs; attacker transactions are never mined) and cancel_all() (clears everything on shutdown or chain reset). No periodic GC, no time-based eviction, and no count cap exists.

For direct tx pushes (Gossip::Tx), the retained entry holds the full deserialized transaction, which can be up to ~9 MB in memory for a transaction near the transparent-output extreme. Per-connection leak rate at worst case: ~685 KB/s (~2.4 GB/hour).

Patches

The fix preserves the UnminedTxId through the timeout error path: wrap the timeout future so the spawned task's outer error carries the txid (e.g., Err((txid, elapsed))). In Downloads::poll_next(), on the timeout arm, call cancel_handles.remove(&txid).

Workarounds

There is no configuration-level workaround. Restarting the node clears the accumulated entries. Operators running in memory-constrained environments (containers with cgroup limits) may see the process killed by the OOM killer before natural recovery.

Impact

Gradual, unbounded memory exhaustion of a Zebra node from unauthenticated P2P traffic. The leak is monotonic (entries are never freed under normal operation) but slow (~685 KB/s per connection worst case). An attacker must sustain traffic for hours to exhaust typical server memory. The node continues operating normally until memory pressure becomes critical, at which point the OS OOM killer terminates the process or the node degrades due to swap pressure. No consensus impact, no fund loss, no on-disk corruption.

Credit

Reported by @AnticsDecoded via a private GitHub Security Advisory submission. Working E2E reproduction on a live regtest node with staged parent/child transaction dependencies.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node participates in a network where chain forks occur (mainnet, testnet, or any network with multiple miners).

All default configurations are affected. The corruption persists across restarts because it is written to RocksDB.

Summary

When pop_tip removes the tip block during a chain fork, stale Sapling and Orchard note commitment subtree root data is retained in the in-memory non-finalized state. When the chain subsequently finalizes, this stale data is written to the persistent RocksDB state. The corrupted subtree root history affects z_getsubtreesbyindex (used by lightwalletd for wallet synchronization) and could affect future chain verification that depends on correct subtree roots.

Details

The non-finalized state provides two methods for removing blocks: pop_root (removes the oldest block during finalization) and pop_tip (removes the newest block during a fork revert). pop_root correctly cleans up note commitment subtree contributions. pop_tip does not: it removes the block but retains the block's subtree root contributions in the in-memory state.

When a chain fork occurs and pop_tip reverts the old tip, the winning fork's chain is extended. When that chain is later finalized, the stale subtree data from the reverted blocks is included in the RocksDB write batch and persisted to disk.

The pop_root/pop_tip asymmetry is specific to subtree root handling. Other state managed by pop_tip (nullifiers, UTXOs, anchors, block hashes) uses different cleanup patterns that are not affected.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

The fix adds subtree root cleanup to pop_tip matching the pattern already used by pop_root.

Workarounds

There is no configuration-level workaround. Chain forks are natural events on any Proof-of-Work network. Operators can mitigate the downstream impact by periodically verifying subtree root consistency using z_getsubtreesbyindex against a known-good reference.

Impact

Persistent corruption of Sapling and Orchard subtree root history in the RocksDB state database. The corruption survives node restarts. Downstream consumers that rely on z_getsubtreesbyindex for wallet synchronization (primarily lightwalletd and light wallets) receive incorrect subtree roots. This does not directly affect consensus validation of new blocks but can cause wallet synchronization failures or incorrect wallet state. Recovery requires rebuilding the state database from scratch.

Credit

Reported by @dingledropper via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node processes blocks past the checkpoint height (non-finalized state is active).
3. The network has NU5 or later activated.

All default configurations are affected.

Summary

Chain::push in the non-finalized state updates the transaction-location index (tx_loc_by_hash) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the assert_eq!(prior_pair, None, "transactions must be unique within a single chain") fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's panic = "abort" release profile, this terminates the entire node process.

The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within Chain::push causes the process to abort.

Details

In zebra-state/src/service/non_finalized_state/chain.rs:1608-1628, the block push sequence is:

1. Insert transaction hash into tx_loc_by_hash with assert_eq! on uniqueness
2. Update transparent outputs and inputs
3. Update shielded data (JoinSplit, Sapling, Orchard) — including nullifier uniqueness checks

The shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the assert_eq! at step 1 fires first because the transaction hash is already in tx_loc_by_hash from the parent block on the same chain.

The block transaction verifier does not run the best-chain nullifier query for block transactions — that check is gated on mempool transactions only (zebra-consensus/src/transaction.rs:521-526). Initial contextual validation checks nullifiers in finalized state only (zebra-state/src/service/check.rs:407-415), but the parent transaction is still in non-finalized state.

There are two attack models:

Model A (two attacker blocks): The attacker mines two consecutive valid-work blocks: parent B1 containing a shielded transaction T, and child B2 repeating T. This requires controlling both blocks consecutively.

Model B (one attacker block after an honest block): The attacker broadcasts a shielded transaction T into the mempool. When any honest miner includes T in their block B1, the attacker only needs to mine the next child block B2 containing the same T. This requires controlling only one block immediately after an honest block that included the attacker's transaction. The attacker can broadcast a suitable shielded transaction every block until one is included by an honest miner, then attempt to mine the follow-up.

Both models require the child block to repeat the shielded-only V5 transaction while the parent is still in non-finalized state.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

Replace the assert_eq! with an Entry-based check that returns ValidateContextError::DuplicateTransaction instead of panicking:

match self.tx_loc_by_hash.entry(transaction_hash) {
    Entry::Vacant(entry) => {
        entry.insert(transaction_location);
    }
    Entry::Occupied(_) => {
        return Err(ValidateContextError::DuplicateTransaction { transaction_hash });
    }
}

Workarounds

There is no configuration-level workaround. The assert is in the non-finalized state push path, which is exercised by all block processing past the checkpoint height.

Impact

A malicious block producer can crash targeted Zebra nodes. There are two attack models:

In the first model, the attacker mines two consecutive valid-work blocks where the child repeats a shielded transaction from the parent. At 10% hashrate, the attacker has approximately 11.5 opportunities per day; at 5%, approximately 2.9 per day; at 1%, approximately one every 8.7 days.

In the second model, the attacker broadcasts a shielded transaction into the mempool and waits for any honest miner to include it. The attacker then only needs to mine the next block containing the same transaction. This is cheaper because the attacker does not need to mine the parent block. At 10% hashrate, the attacker has approximately 14.4 single-block opportunities per day; at 5%, approximately 7.2 per day; at 1%, approximately 1.4 per day.

The crash is a process abort (not recoverable within the process). The node must be restarted. Repeated attacks can keep a node down for extended periods. This is a liveness issue, not a consensus divergence: zcashd cleanly rejects the invalid child block while Zebra aborts.

Credit

Reported by @haxatron via email disclosure.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node processes blocks on any Zcash network.

Summary

The finalized transparent address balance writer processes all newly-created outputs (credits) before processing spent outputs (debits) within the same block. A consensus-valid block containing a long chain of same-address transparent self-spends can cause the intermediate per-address balance during the credit pass to exceed MAX_MONEY, triggering a panic in the finalized state writer.

Because the triggering block is consensus-valid (zcashd accepts it), the panic recurs on restart when the node re-encounters the same block. This creates a persistent chain halt that can only be resolved by a software patch.

Details

The finalized state writer at zebra-state/src/service/finalized_state/zebra_db/transparent.rs iterates all transaction outputs in a block and credits them to per-address balances before iterating inputs and debiting spent outputs. When a block contains many transparent self-spends to the same address, the intermediate credit-only balance can exceed the MAX_MONEY supply cap even though the final net balance (credits minus debits) is valid.

The code panics on the intermediate overflow via .expect() on the balance addition. Under Zebra's panic = "abort" release profile, this terminates the process. On restart, the node re-downloads and re-processes the same consensus-valid block, triggering the same panic.

An attacker with approximately 1,100–2,100 ZEC and mining capability can construct a block that permanently halts all Zebra nodes. The attacker recovers their capital (the self-spends return funds to the same address), so the net cost is the mining effort only.

Patches

Patched in Zebra 4.4.2. The fix processes credits and debits together per transaction rather than all credits then all debits, matching zcashd's approach.

Workarounds

No workaround is available. Upgrade to Zebra 4.4.2.

Impact

A single consensus-valid mined block can permanently halt all Zebra nodes on the network. The halt persists across restarts. Recovery requires deploying a patched version. Downstream consumers (light wallets, exchanges, mining infrastructure) lose service for the duration of the halt.

Credit

Reported by @sangsoo-osec.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections and is syncing or catching up to the chain tip.

Summary

A malicious peer can answer Zebra's outbound getblocks/FindBlocks request with a small two-hash inventory, then serve a syntactically valid block whose coinbase height is far above the victim's local tip. The AboveLookaheadHeightLimit error in the sync download pipeline triggers a global sync restart rather than being scoped to the offending peer. The peer is never scored or disconnected because the error type does not carry the advertiser address.

On mainnet, each successful cycle imposes a 67-second sync restart delay. All in-flight downloads from honest peers are cancelled on each restart.

Details

The bug is the interaction of three layers:

1. The syncer promotes unvalidated FindBlocks peer responses into concrete download schedules without checking that the advertised hashes are plausible chain extensions.

2. When a downloaded block's coinbase height exceeds tip + VERIFICATION_PIPELINE_DROP_LIMIT, the sync downloader returns BlockDownloadVerifyError::AboveLookaheadHeightLimit. This error variant carries only the block height and hash, not the advertiser peer address.

3. The sync error handler in handle_block_response only sends misbehaviour scores for BlockDownloadVerifyError::Invalid errors that carry an advertiser_addr and have a nonzero misbehavior_score(). AboveLookaheadHeightLimit falls through to the default restart-worthy path, cancelling all in-flight downloads and waiting 67 seconds before restarting sync.

The attacker needs only an unauthenticated P2P connection (post-handshake), a tiny payload (one two-hash inv message plus one small block per cycle), and no mining capability, funds, or valid chain data. The peer is never penalised, so the attack is repeatable indefinitely.

Additionally, several other pre-consensus sync-layer errors had zero misbehaviour scores even when peer-attributed. Contextual validation failures (InvalidDifficultyThreshold, TimeTooEarly, TimeTooLate, NonSequentialBlock) and locktime failures from block-serving peers all scored zero, allowing repeated abuse without penalty.

Patches

Patched in Zebra 4.4.2. The fix:

• Carries advertiser_addr through AboveLookaheadHeightLimit and InvalidHeight error variants.
• Makes above-lookahead and invalid-height failures peer-local (the block is dropped and the peer is banned with score 100) rather than triggering a global sync restart.
• Expands misbehavior_score() across BlockError, VerifyBlockError, and CommitBlockError to cover contextual validation failures that previously scored zero.

Workarounds

No configuration-level workaround is available. The attack is mitigated by having a diverse honest peer set, but cannot be prevented while the vulnerable code is running.

Impact

A single unauthenticated peer can repeatedly stall a syncing Zebra node by forcing 67-second global sync restart cycles. All unrelated in-flight downloads are cancelled on each restart. The node does not crash and no state is corrupted, but sync progress is significantly degraded for the duration of the attack.

Credit

Reported by @ipwning.

Am I affected

You are affected if:

1. You run any version of zebrad up to and including v4.4.1.
2. Your node validates blocks on mainnet, testnet, or any network where both Zebra and zcashd nodes participate.

All default configurations are affected. No feature flags, non-default settings, or special build options are required.

Summary

Zebra's P2SH sigop counter uses a pure-Rust code path that short-circuits on disabled opcodes (such as OP_CODESEPARATOR), returning a partial count of zero for any sigops following the disabled opcode. The reference implementation (zcashd) correctly counts through disabled opcodes in its static sigop analysis. This produces a consensus divergence: Zebra accepts blocks that zcashd rejects when the block-wide MAX_BLOCK_SIGOPS = 20,000 threshold is crossed on one side but not the other.

An attacker can exploit this without mining capability. Broadcasting transactions that spend P2SH outputs with malicious redeem scripts is sufficient; any Zebra miner who includes those transactions in a block triggers a chain split between Zebra and zcashd validators.

Details

The P2SH sigop counter at zebra-script/src/lib.rs:399 calls script::Code(redeemed_bytes).sig_op_count(true), which is a pure-Rust path through zcash_script-0.4.4. The legacy (non-P2SH) sigop counter at lib.rs:282-289 correctly uses the C++ FFI via interpreter.legacy_sigop_count_script(). Only the P2SH path bypasses the FFI.

The Rust parser in zcash_script-0.4.4/src/opcode/mod.rs:1247-1260 treats 16 disabled opcodes (0x7e through 0xab, including OP_CAT, OP_SUBSTR, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT, OP_RSHIFT, and OP_CODESEPARATOR) as Err(Error::Disabled(...)). The sig_op_count function at iter.rs:104-115 uses try_fold, which terminates on the first Err and returns the partial sum accumulated so far.

zcashd's GetOp2 (script.h:514-562) returns true for all non-push opcodes including the disabled range. Its GetSigOpCount(true) (script.cpp:152-174) continues counting through disabled opcodes. zcashd rejects disabled opcodes at execution time in the interpreter, not during static sigop analysis.

A redeem script of [0xab, OP_CHECKMULTISIG x 50] produces: Zebra = 0 sigops, zcashd = 1,000 sigops. Across 21 inputs in a block, Zebra computes 0 while zcashd computes 21,000, crossing the MAX_BLOCK_SIGOPS = 20,000 threshold on one side only.

Patches

Patched in Zebra 4.4.2. The fix routes the P2SH sigop counter through the same C++ FFI already used by the legacy sigop counter.

Workarounds

There is no configuration-level workaround. All Zebra nodes validating blocks on a network shared with zcashd are affected. Upgrade as soon as the patched version is available.

Impact

A chain split between Zebra and zcashd validators. The attacker broadcasts spending transactions referencing P2SH outputs whose redeem scripts contain a disabled opcode followed by OP_CHECKSIG or OP_CHECKMULTISIG opcodes. When a Zebra miner (estimated ~30% of current network hashrate) includes these transactions in a block, Zebra validators accept the block while zcashd validators reject it with bad-blk-sigops. The two halves of the network diverge and every subsequent block extending the Zebra-side tip inherits the divergence.

The attacker does not need mining capability, RPC access, or any special privileges. The cost is the transaction fees for the funding and spending transactions.

Credit

Reported by @samsulselfut via a private GitHub Security Advisory submission.

Description

Am I affected

You are affected if:

1. You run any version of zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node processes blocks past the checkpoint height (non-finalized state is active).

All default configurations are affected.

Summary

Zebra records a block hash in non_finalized_block_write_sent_hashes when the block is sent to the write task, before contextual validation completes. If validation fails, the hash is not removed. A remote unauthenticated peer can deliver a poisoned block body that shares a header hash with a later valid canonical block. The poisoned body is rejected, but the hash remains cached. When the valid canonical block arrives, Zebra treats it as a duplicate and rejects it. The node cannot advance past that height until restart or a reorg event.

Details

ZIP-244 defines txid_v5 without binding transparent input scriptSig, which lives in auth_digest and is committed to by hashBlockCommitments in the block header. Because merkle_root is computed over txids (not auth digests), and the block hash is computed over the header, an attacker can construct two blocks with identical header hashes but different transaction bodies by mutating the coinbase scriptSig.

The attack flow over P2P:

1. Attacker observes a new block header (from any peer).
2. Attacker constructs a poisoned body by flipping a byte of the coinbase scriptSig extra-data section. The block hash is unchanged.
3. Attacker advertises the block hash via inv to the target node.
4. Target requests the block via getdata; attacker serves the poisoned body.
5. Zebra adds the hash to non_finalized_block_write_sent_hashes before validation.
6. The write task rejects the body at block_commitment_is_valid_for_chain_history (auth_data_root mismatch).
7. The hash is not removed from non_finalized_block_write_sent_hashes.
8. When the valid canonical block arrives (from honest peers or RPC), queue_and_commit_to_non_finalized_state sees the hash in the cache and returns KnownBlock::WriteChannel duplicate.
9. The node is stuck at height N-1.

A secondary variant exists where chain pruning (via MAX_NON_FINALIZED_CHAIN_FORKS) removes a chain from chain_set but leaves its block hashes in non_finalized_block_write_sent_hashes, producing the same lockout for children of the pruned fork.

Patches

Patched in Zebra 4.4.2. The fix removes stale entries from non_finalized_block_write_sent_hashes on every failed non-finalized write path.

Workarounds

There is no complete configuration-level workaround. Reducing the node's inbound peer count (network.peerset_initial_target_size) narrows the attack surface but does not eliminate it. Restarting the node clears the in-memory cache and allows the valid block to be re-fetched.

Impact

A remote unauthenticated P2P peer can permanently stall a targeted Zebra node at a specific block height. The node diverges from the network tip; downstream consumers (lightwalletd, wallets, explorers, mining infrastructure) relying on the node see a stalled chain. The attack requires winning a propagation race: delivering the poisoned block body before honest peers deliver the canonical block. A well-positioned attacker (low-latency connection to the target, observation of new blocks from other peers) can reliably win this race. In sustained form, the attacker repeats for each new block, keeping the target permanently behind.

Recovery requires restarting the node (which clears the in-memory sent-hash cache) or waiting for a reorg at the affected height (rare on the canonical chain).

Credit

Reported independently by @ipwning (primary, with ZIP-244 malleability analysis and zcashd cross-reference) and @x15-eth (first reporter, with E2E reproduction and control experiment).

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).

Summary

The P2P codec's Codec::decode() method calls src.reserve(body_len + HEADER_LEN) after parsing a 24-byte protocol header, using the attacker-claimed body_len field. This reserves up to MAX_PROTOCOL_MESSAGE_LEN (~2 MiB) of virtual buffer capacity per connection before any body bytes arrive and before the handshake completes.

However, BytesMut::reserve() sets virtual capacity without committing physical memory pages. The operating system does not allocate physical RAM until bytes are actually written into the buffer. Since the attacker never sends body bytes, the reserved capacity remains uncommitted. Reproduction of the reporter's PoC (256 threads, 30 seconds of sustained connections) showed negligible RSS impact on the Zebra process.

Zebra's existing mitigations further constrain the practical attack surface: per-IP connection limits (max_connections_per_ip = 1), a per-connection accept rate of approximately one per second, and a 3-second handshake timeout that cleans up idle connections.

Details

At zebra-network/src/protocol/external/codec.rs:406, after parsing the 24-byte header and validating the network magic and body length against MAX_PROTOCOL_MESSAGE_LEN, the codec calls src.reserve(body_len + HEADER_LEN). The codec is constructed on the bare TCP stream before negotiate_version() runs, so the reservation is reachable from any TCP peer that can send 24 bytes.

No legitimate Zcash handshake message (version, verack) is anywhere close to 2 MiB. The codec makes no distinction between pre-handshake and post-handshake message types when sizing the reservation.

Patches

The fix defers large buffer reservations until after the handshake completes, or caps the per-message reservation for pre-handshake messages to what version/verack actually require.

Workarounds

No workaround is needed. The existing per-IP rate limiting, handshake timeout, and connection limits effectively mitigate the practical impact.

Impact

Minimal. The reservation affects virtual address space only, not physical memory. Zebra's existing connection-management mitigations (per-IP limits, accept rate, handshake timeout) further constrain the attack. The code path is worth cleaning up for defense-in-depth but does not produce a measurable denial-of-service effect.

Credit

Reported by @ouicate via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

Summary

A single unauthenticated P2P peer can monopolize all 25 inbound mempool download/verification slots (MAX_INBOUND_CONCURRENCY) by advertising fake transaction IDs. While the slots are occupied, all other inbound transactions from honest peers and local RPC sendrawtransaction calls are rejected with MempoolError::FullQueue. The attacker peer is never scored for misbehavior and is not disconnected, allowing sustained denial of mempool admission.

Details

The mempool download/verification pipeline at zebrad/src/components/mempool/downloads.rs uses a single bounded pool of 25 concurrent tasks. Three architectural gaps combine to produce the vulnerability:

1. No per-peer accounting: the 25 slots are shared across all peers with no cap on how many a single peer can hold.
2. No overload signaling: when FullQueue is returned, the inbound service at zebrad/src/components/inbound.rs maps it to Response::Nil, hiding the overload from the peer connection layer. The existing handle_inbound_overload disconnection logic never fires.
3. No misbehavior attribution: peer identity is not carried through the Gossip type into the download pipeline, so verification failures cannot be attributed to the originating peer.

The attacker sends inv messages advertising fake transaction IDs. Zebra queues download tasks for each ID. The attacker stays silent; each slot is held until the TRANSACTION_DOWNLOAD_TIMEOUT (20 seconds) fires. The attacker periodically sends fresh inv waves to re-fill slots as they expire.

Two additional slot-holding techniques have been independently demonstrated: invalid-prevout transactions that park in AwaitOutput for 60 seconds, and expensive shielded proof verification with auth-variant cache bypass. All three techniques are addressed by the same per-peer accounting fix.

Patches

zebrad 4.5.0

The fix adds per-peer queue accounting to the mempool download pipeline. A single peer is limited to a fraction of MAX_INBOUND_CONCURRENCY (e.g., 5 slots out of 25). FullQueue is surfaced as an overload signal to the peer connection layer. Peer identity is plumbed through the Gossip type for misbehavior attribution.

Workarounds

There is no complete configuration-level workaround. Reducing network.peerset_initial_target_size limits the total inbound peer count but does not prevent a single peer from holding all mempool slots.

Impact

Mempool transaction admission is denied for all honest peers and local RPC clients while the attack is sustained. Block validation and chain synchronization continue normally. The attacker needs only one TCP connection and minimal bandwidth (~1 KB/s of fake inv messages). The node recovers immediately when the attacker stops. This does not affect consensus, funds, or on-disk state.

Credit

Reported by @dingledropper via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file (typically local access). With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The z_listunifiedreceivers RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (sapling_crypto::PaymentAddress::from_bytes returns None for non-subgroup Jubjub points). The handler calls .expect("using data already decoded as valid") on the fallible result. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process, not just the RPC task.

Details

zcash_address::unified::Encoding::decode validates only the structural envelope of a Unified Address (F4Jumble, bech32m, typecode ordering, 43-byte length for Sapling). It does not validate that the embedded pk_d is a valid Jubjub subgroup point or that the diversifier produces a valid g_d preimage.

At zebra-rpc/src/methods.rs:2893, the handler calls Address::try_from_sapling(network, data), which delegates to sapling_crypto::PaymentAddress::from_bytes. When from_bytes returns None (most random 32-byte strings fail the subgroup check), the .expect() fires and the process aborts.

The same crate already handles this correctly in try_from_unified at zebra-chain/src/primitives/address.rs:99-110, which returns Err when from_bytes fails. The vulnerable code path bypasses this validated route.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace .expect() with .map_err(|e| ErrorObject::owned(...)) for proper error propagation, or route through the existing try_from_unified path which already handles this case correctly.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that rejects z_listunifiedreceivers calls with untrusted address parameters.

Impact

A single authenticated RPC request terminates the zebrad process. The attack is repeatable on restart (the same request triggers the same abort), allowing an attacker to keep the node down indefinitely until the request is filtered upstream. Operators using lightwalletd backends, Zaino indexers, or mining pool infrastructure that forward RPC calls to zebrad may be exposed if the forwarding path passes through z_listunifiedreceivers.

Credit

Reported by @robustfengbin via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections.

Summary

The read_getblocks and read_getheaders codec paths accepted block locator vectors up to approximately 65,535 entries (the generic TrustedPreallocate ceiling derived from MAX_PROTOCOL_MESSAGE_LEN), rather than the protocol-specification limit of 101 entries (matching zcashd's MAX_LOCATOR_SZ). Each entry in the locator vector triggers a per-hash chain lookup (HashMap::contains_key + RocksDB::contains_hash) in find_chain_intersection on a tokio blocking-pool thread.

A single maximally-sized getblocks message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups.

Details

The read_headers codec path already implements the correct pattern: it reads the CompactSize count, validates against MAX_HEADERS_PER_MESSAGE = 160 before deserialization, and rejects oversized messages. The read_getblocks and read_getheaders paths were missing this pre-deserialization count check and instead relied on the generic block::Hash::max_allocation() bound, which allows (MAX_PROTOCOL_MESSAGE_LEN - 1) / 32 = 65,535 hashes.

A legitimate block locator is logarithmic in chain length (approximately 30 hashes for the current ~3M-block Zcash chain). Zebra's own send-side cap is MAX_FIND_BLOCK_HASHES_RESULTS = 500.

The practical impact requires significant attacker bandwidth (approximately 2 MiB per request) and multiple Sybil peers to meaningfully degrade the blocking pool, which limits real-world exploitability.

Patches

Patched in Zebra 4.4.2. The fix caps block::Hash::max_allocation() at MAX_BLOCK_LOCATOR_LENGTH = 101, matching zcashd's MAX_LOCATOR_SZ. This causes the deserializer to reject oversized locators before any allocation or iteration occurs.

Workarounds

No specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.

Impact

Under sustained load from multiple Sybil peers, oversized locator vectors can occupy blocking-pool threads and degrade state-read performance. The effect is bounded by connection limits and requires significant attacker bandwidth.

Credit

Vulnerability identified by @dingledropper, who submitted the fix in PR #10570. Downstream CPU/blocking-pool impact analysis contributed by @ouicate.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

Summary

A soundness vulnerability in the variable-base scalar multiplication gadget of halo2_gadgets allowed a malicious prover to produce a valid proof for an Orchard Action with an under-constrained base point. Because this gadget enforces the diversified-address-integrity condition of the Orchard Action statement, the flaw let a prover satisfy that condition for an arbitrary (pkd, gd, ivk) triple, effectively bypassing the check that binds an Action to the correct incoming viewing key — and therefore to the correct nullifier (nf) and spend validating key (ak) — of the note being spent.

The main practical consequence is that an adversary could have performed a double-spend within the Orchard pool, resulting in a balance violation: the same note could be spent multiple times, each time revealing a distinct, valid-looking nullifier. The total ZEC supply was protected by Zcash's turnstile mechanism, which bounds value flowing out of any pool, so unbounded inflation of the overall supply was not possible; the exposure was inflation of value within the Orchard pool up to the turnstile-enforced limit.

Exploiting the vulnerability via a double-spend is undetectable on-chain. Exploitation only requires setting private circuit inputs to chosen values, and nullifiers produced by a double-spend are indistinguishable from honest nullifiers, so the zero-knowledge property hides any signature of the attack.

Alternatively, an adversary could (before the fix) have stolen funds by forging a spend authorization for an existing note. To do so they would have to know the note plaintext, which in practice they might obtain by knowing the corresponding incoming viewing key. For example, this could be used to bypass the protection provided by holding spending keys on a hardware wallet, if the linked software wallet were compromised. This form of exploitation cannot be detected via the turnstile (which might be a motivation to exploit the vulnerability in this way rather than via balance violation). It can be detected by the legitimate holder of stolen funds being unable to spend them, or by seeing the note's nullifier on-chain — but this cannot necessarily be distinguished from compromise of the spending key by other means.

The vulnerability has existed since the Orchard pool was introduced in the NU5 network upgrade (activated May 31, 2022). There is no evidence it was exploited prior to remediation.

Note that use of the vulnerability, either for balance violation or for theft of funds, would need to have occurred before it was remediated. Theft would be in principle detectable from that point (since the real nullifier would appear on-chain). Balance violation would not be detectable at the point of exploitation.

Root cause

The defect is in the double-and-add implementation of variable-base scalar multiplication in halo2_gadgets/src/ecc/chip/mul/incomplete.rs. For performance, the algorithm uses incomplete point-addition formulas in its intermediate stage. (Incomplete addition is safe here in principle: the first and last stages use complete addition, and reaching a degenerate case would require breaking discrete log.)

The base point is fed into the incomplete-addition stage via assign_advice(), which assigns a witness value (a private circuit input) without introducing a constraint that ties that value to the actual base the algorithm is supposed to operate on:

region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?;
region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?;

(halo2_gadgets/src/ecc/chip/mul/incomplete.rs, around L309–L310 at commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea.)

The existing q_mul_2 constraint forces the base values used across the incomplete-addition loop to be equal to one another, but nothing forces them to equal the actual base. A malicious prover therefore has complete freedom to choose the base used by the loop. Given target pkd, gd, and ivk, the prover can solve for the base value that makes the computed [ivk] gd equal the desired pkd, satisfying the diversified-address-integrity equation pkdold = [ivk] gdold for inputs that an honest prover could never satisfy.

Why this enables a double-spend

The Orchard Action statement constrains the nullifier of the spent note to be derived from the correct nullifier key nk, which in turn is bound to the correct incoming viewing key ivk, via ivk = Commitivkrivk(Extractℙ(akℙ), nk). The diversified-address-integrity check pkd = [ivk] gd is what normally guarantees the prover used the correct ivk —and hence the correct nk— for the note. With that check bypassable:

1. The prover picks a fresh, incorrect nk for the note being spent. Since nk feeds the nullifier computation, a wrong nk yields a different nullifier for the same note.
2. Other circuit constraints still force the prover to derive ivk honestly from that wrong nk, producing a wrong ivk for the note — which would normally be caught by the integrity check.
3. The prover uses the under-constrained base to satisfy pkd = [ivk] gd anyway, defeating the check.
4. Each distinct wrong nk produces a distinct valid nullifier, allowing the note to be spent repeatedly.

Why this enables theft

The spend validating key, akℙ (essentially equivalent to ak), is also constrained via ivk = Commitivkrivk(Extractℙ(akℙ), nk). As above, the diversified-address-integrity check is what normally guarantees the prover used the correct ivk —and hence the correct ak— for the note. With that check bypassable:

1. The prover picks an ak for which they know the private key, ask.
2. They construct a transaction that spends the victim's notes, and sign it using that ask.

Impact

• Integrity: High. A malicious prover could spend Orchard notes multiple times, inflating value within the Orchard pool. This is bounded only by the turnstile limit on the pool. Alternatively, the prover could authorize spending other users' notes without having the spending key.
• Confidentiality: None. The zero-knowledge property is intact; no private data is disclosed. This is also why the attack leaves no observable on-chain signature.
• Availability: Not directly affected by the bug. (The coordinated response temporarily disabled Orchard actions as a mitigation; that was an operational choice, not an effect of the vulnerability.) On the other hand, either theft of funds, or inability to spend funds due to a future turnstile violation could be considered an availability consequence.

Affected versions

• halo2_gadgets < 0.5.0
• orchard < 0.14.0
• zcash_primitives < 0.28.0
• zcashd < 6.20.0
• zebrad < 5.0.0

Patches

The circuit-level fix replaces the first-iteration assign_advice() calls for the base point with copy_advice(), introducing a copy constraint that requires the first base value to equal the correct base. Combined with the existing q_mul_2 equality constraint across the loop, this transitively constrains every base value in the incomplete-addition stage to the correct base, closing the freedom the attacker relied on.

Because remediating a zero-knowledge circuit changes the pinned verifying key, the network-level fix required a hard fork (NU6.2). NU6.2 re-enables Orchard with the corrected circuit and routes Orchard proofs to a per-circuit verifying key (InsecurePreNu6_2 / FixedPostNu6_2).

• halo2_gadgets 0.5.0
• orchard 0.14.0
• zcash_primitives 0.28.0
• zebrad 5.0.0 (NU6.2); 4.5.3 ships the interim soft-fork mitigation
• zcashd 6.20.0 (NU6.2)

Workarounds / mitigations

There is no client-side workaround for the underlying soundness flaw short of the circuit fix. The deployed interim mitigation (Zebra 4.5.3 / equivalent) was a soft fork that rejected all Orchard-containing transactions and blocks, fully neutralizing exploitation until NU6.2 activated.

Downstream projects that depend on the affected crates should:

• Upgrade halo2_gadgets, orchard, and zcash_primitives to the patched versions above.
• Audit any other use of assign_advice() (and similar non-constraining assignment APIs) where the intended invariant is that a witnessed value equals a known/fixed value; such sites should use copy_advice() (or otherwise enforce an explicit constraint).

Indicators / detection

Exploitation produces no distinguishing on-chain signature. The turnstile mechanism, which tracks total ZEC across all value pools, provides a ground-truth supply check and confirmed the total supply remained intact. Heuristic analysis of Orchard transaction arity (e.g. patterns of duplicate-then-consolidate behavior) is possible but inconclusive against normal shielded-activity variance.

Timeline (MDT)

| Date / Time | Event | |---|---| | 2022-05-31 11:50 | Vulnerable NU5 upgrade activates (bug introduced) | | 2026-05-29 (evening) | Vulnerability discovered during a protocol audit | | 2026-05-29 23:53 | Responsibly disclosed to ZODL core engineers | | 2026-05-30 06:30 | Disclosure acknowledged by ZODL | | 2026-06-01 (~21:30) | Emergency soft-fork mitigation activated (block 3,363,426) | | 2026-06-03 00:05 EDT | NU6.2 hard fork activates, Orchard re-enabled with fix (block 3,364,600) |

Credits

Discovered and responsibly disclosed by Taylor Hornby, independent security researcher, during a protocol audit conducted on behalf of Shielded Labs. Analysis and remediation was led by ZODL engineers Jack Grigg, Daira-Emma Hopwood, and Kris Nuttycombe, with Zebra patch work by Arya Solhi (Zcash Foundation).

Resources

• Zcash Foundation: Zebra 4.5.3 and 5.0.0: Emergency Soft Fork and NU6.2 Activation — https://zfnd.org/zebra-4-5-3-and-5-0-0-emergency-soft-fork-and-nu6-2-activation/
• Affected source (pre-fix): halo2_gadgets/src/ecc/chip/mul/incomplete.rs @ commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea, L309–L310

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node listens on the default [::] address on a Linux host (the standard deployment configuration — net.ipv6.bindv6only=0 is the default on all common Linux distributions).
3. Your node is synced near the chain tip (the expected production state for any node participating in the network).

Summary

An address normalization mismatch between the handshake path and the mempool misbehavior path causes a deterministic assertion panic when a peer connects via IPv4 to a dual-stack IPv6 listener and then triggers a mempool misbehavior penalty.

The handshake path canonicalizes IPv4-mapped IPv6 addresses to plain IPv4 when storing the peer in the address book via MetaAddr::new_connected. The mempool misbehavior path forwards the raw transient socket address (IPv4-mapped IPv6 form) when sending MetaAddrChange::UpdateMisbehavior to the address book. The address book looks up the canonical IPv4 entry but then asserts that the previous entry's address matches the change's address. The mismatch between the canonical IPv4 address and the raw IPv4-mapped IPv6 address triggers the assertion, and panic = "abort" terminates the process.

Details

On Linux with net.ipv6.bindv6only=0, an IPv4 connection accepted by a [::] listener is represented internally as an IPv4-mapped IPv6 socket address (e.g., ::ffff:127.0.0.1:8233). Zebra's canonical_peer_addr helper converts these to plain IPv4 (e.g., 127.0.0.1:8233).

The handshake path uses MetaAddr::new_connected, which canonicalizes the address before storing in the address book. However, inbound inventory registration uses connected_addr.get_transient_addr(), preserving the raw IPv4-mapped form. When the mempool later downloads an invalid transaction from this peer and generates a misbehavior penalty, the raw transient address is forwarded through the misbehavior channel to MetaAddrChange::UpdateMisbehavior, which does not canonicalize.

After the 30-second misbehavior batch flush, AddressBook::update retrieves the canonical IPv4 entry but MetaAddrChange::apply_to_meta_addr asserts that previous.addr == self.addr(), which fails because one is IPv4 and the other is IPv4-mapped IPv6.

The attacker needs only to complete a P2P handshake over IPv4 to a dual-stack listener and advertise an invalid mempool transaction (such as a coinbase transaction). The assertion fires after the 30-second misbehavior batch flush.

Patches

Patched in Zebra 4.5.0. The fix canonicalizes the address in the misbehavior update path via a new MetaAddr::new_misbehavior constructor that applies canonical_peer_addr before creating the UpdateMisbehavior change.

Workarounds

Configuring listen_addr to an IPv4-only address (e.g., 0.0.0.0:8233) avoids the IPv4-mapped IPv6 representation and prevents this specific assertion. Alternatively, setting net.ipv6.bindv6only=1 on Linux prevents dual-stack acceptance.

Impact

A remote unauthenticated peer can deterministically crash any synced Zebra node running the default Linux dual-stack configuration with a single invalid mempool transaction advertisement, followed by a 30-second wait. The attack requires no mining capability, no RPC access, no funds, and no special privileges. The crash can be repeated after each restart, causing persistent downtime. Linux dual-stack sockets and mempool activation are the default production state, not special preconditions.

Credit

Reported by @Haxatron.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

Summary

The mempool download pipeline's cancel_handles map retains entries for transactions whose verification times out at the outer RATE_LIMIT_DELAY (73-second) boundary. The tokio::time::error::Elapsed error carries no payload, so the transaction ID is unrecoverable and the corresponding cancel_handles entry (including the full Gossip::Tx(UnminedTx), up to ~2 MB) is never removed. Entries accumulate monotonically with no upper bound or garbage collection, leading to eventual out-of-memory process termination.

Details

Downloads::poll_next() at zebrad/src/components/mempool/downloads.rs:215-228 handles three terminal states for a verification task:

• Ok(Ok(...)): success. Calls cancel_handles.remove(&tx.transaction.id). Correct.
• Ok(Err(...)): verification error. Calls cancel_handles.remove(&hash). Correct.
• Err(elapsed): outer timeout. Returns Err(elapsed) without removing anything. Bug.

tokio::time::error::Elapsed has no payload, so the timed-out transaction's UnminedTxId is unrecoverable from the error. The consumer at zebrad/src/components/mempool.rs:663-672 explicitly acknowledges this gap with a TODO comment.

The only cleanup paths for cancel_handles are cancel(mined_ids) (removes entries matching mined transaction IDs; attacker transactions are never mined) and cancel_all() (clears everything on shutdown or chain reset). No periodic GC, no time-based eviction, and no count cap exists.

For direct tx pushes (Gossip::Tx), the retained entry holds the full deserialized transaction, which can be up to ~9 MB in memory for a transaction near the transparent-output extreme. Per-connection leak rate at worst case: ~685 KB/s (~2.4 GB/hour).

Patches

The fix preserves the UnminedTxId through the timeout error path: wrap the timeout future so the spawned task's outer error carries the txid (e.g., Err((txid, elapsed))). In Downloads::poll_next(), on the timeout arm, call cancel_handles.remove(&txid).

Workarounds

There is no configuration-level workaround. Restarting the node clears the accumulated entries. Operators running in memory-constrained environments (containers with cgroup limits) may see the process killed by the OOM killer before natural recovery.

Impact

Gradual, unbounded memory exhaustion of a Zebra node from unauthenticated P2P traffic. The leak is monotonic (entries are never freed under normal operation) but slow (~685 KB/s per connection worst case). An attacker must sustain traffic for hours to exhaust typical server memory. The node continues operating normally until memory pressure becomes critical, at which point the OS OOM killer terminates the process or the node degrades due to swap pressure. No consensus impact, no fund loss, no on-disk corruption.

Credit

Reported by @AnticsDecoded via a private GitHub Security Advisory submission. Working E2E reproduction on a live regtest node with staged parent/child transaction dependencies.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node participates in a network where chain forks occur (mainnet, testnet, or any network with multiple miners).

All default configurations are affected. The corruption persists across restarts because it is written to RocksDB.

Summary

When pop_tip removes the tip block during a chain fork, stale Sapling and Orchard note commitment subtree root data is retained in the in-memory non-finalized state. When the chain subsequently finalizes, this stale data is written to the persistent RocksDB state. The corrupted subtree root history affects z_getsubtreesbyindex (used by lightwalletd for wallet synchronization) and could affect future chain verification that depends on correct subtree roots.

Details

The non-finalized state provides two methods for removing blocks: pop_root (removes the oldest block during finalization) and pop_tip (removes the newest block during a fork revert). pop_root correctly cleans up note commitment subtree contributions. pop_tip does not: it removes the block but retains the block's subtree root contributions in the in-memory state.

When a chain fork occurs and pop_tip reverts the old tip, the winning fork's chain is extended. When that chain is later finalized, the stale subtree data from the reverted blocks is included in the RocksDB write batch and persisted to disk.

The pop_root/pop_tip asymmetry is specific to subtree root handling. Other state managed by pop_tip (nullifiers, UTXOs, anchors, block hashes) uses different cleanup patterns that are not affected.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

The fix adds subtree root cleanup to pop_tip matching the pattern already used by pop_root.

Workarounds

There is no configuration-level workaround. Chain forks are natural events on any Proof-of-Work network. Operators can mitigate the downstream impact by periodically verifying subtree root consistency using z_getsubtreesbyindex against a known-good reference.

Impact

Persistent corruption of Sapling and Orchard subtree root history in the RocksDB state database. The corruption survives node restarts. Downstream consumers that rely on z_getsubtreesbyindex for wallet synchronization (primarily lightwalletd and light wallets) receive incorrect subtree roots. This does not directly affect consensus validation of new blocks but can cause wallet synchronization failures or incorrect wallet state. Recovery requires rebuilding the state database from scratch.

Credit

Reported by @dingledropper via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node processes blocks past the checkpoint height (non-finalized state is active).
3. The network has NU5 or later activated.

All default configurations are affected.

Summary

Chain::push in the non-finalized state updates the transaction-location index (tx_loc_by_hash) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the assert_eq!(prior_pair, None, "transactions must be unique within a single chain") fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's panic = "abort" release profile, this terminates the entire node process.

The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within Chain::push causes the process to abort.

Details

In zebra-state/src/service/non_finalized_state/chain.rs:1608-1628, the block push sequence is:

1. Insert transaction hash into tx_loc_by_hash with assert_eq! on uniqueness
2. Update transparent outputs and inputs
3. Update shielded data (JoinSplit, Sapling, Orchard) — including nullifier uniqueness checks

The shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the assert_eq! at step 1 fires first because the transaction hash is already in tx_loc_by_hash from the parent block on the same chain.

The block transaction verifier does not run the best-chain nullifier query for block transactions — that check is gated on mempool transactions only (zebra-consensus/src/transaction.rs:521-526). Initial contextual validation checks nullifiers in finalized state only (zebra-state/src/service/check.rs:407-415), but the parent transaction is still in non-finalized state.

There are two attack models:

Model A (two attacker blocks): The attacker mines two consecutive valid-work blocks: parent B1 containing a shielded transaction T, and child B2 repeating T. This requires controlling both blocks consecutively.

Model B (one attacker block after an honest block): The attacker broadcasts a shielded transaction T into the mempool. When any honest miner includes T in their block B1, the attacker only needs to mine the next child block B2 containing the same T. This requires controlling only one block immediately after an honest block that included the attacker's transaction. The attacker can broadcast a suitable shielded transaction every block until one is included by an honest miner, then attempt to mine the follow-up.

Both models require the child block to repeat the shielded-only V5 transaction while the parent is still in non-finalized state.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

Replace the assert_eq! with an Entry-based check that returns ValidateContextError::DuplicateTransaction instead of panicking:

match self.tx_loc_by_hash.entry(transaction_hash) {
    Entry::Vacant(entry) => {
        entry.insert(transaction_location);
    }
    Entry::Occupied(_) => {
        return Err(ValidateContextError::DuplicateTransaction { transaction_hash });
    }
}

Workarounds

There is no configuration-level workaround. The assert is in the non-finalized state push path, which is exercised by all block processing past the checkpoint height.

Impact

A malicious block producer can crash targeted Zebra nodes. There are two attack models:

In the first model, the attacker mines two consecutive valid-work blocks where the child repeats a shielded transaction from the parent. At 10% hashrate, the attacker has approximately 11.5 opportunities per day; at 5%, approximately 2.9 per day; at 1%, approximately one every 8.7 days.

In the second model, the attacker broadcasts a shielded transaction into the mempool and waits for any honest miner to include it. The attacker then only needs to mine the next block containing the same transaction. This is cheaper because the attacker does not need to mine the parent block. At 10% hashrate, the attacker has approximately 14.4 single-block opportunities per day; at 5%, approximately 7.2 per day; at 1%, approximately 1.4 per day.

The crash is a process abort (not recoverable within the process). The node must be restarted. Repeated attacks can keep a node down for extended periods. This is a liveness issue, not a consensus divergence: zcashd cleanly rejects the invalid child block while Zebra aborts.

Credit

Reported by @haxatron via email disclosure.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node processes blocks on any Zcash network.

Summary

The finalized transparent address balance writer processes all newly-created outputs (credits) before processing spent outputs (debits) within the same block. A consensus-valid block containing a long chain of same-address transparent self-spends can cause the intermediate per-address balance during the credit pass to exceed MAX_MONEY, triggering a panic in the finalized state writer.

Because the triggering block is consensus-valid (zcashd accepts it), the panic recurs on restart when the node re-encounters the same block. This creates a persistent chain halt that can only be resolved by a software patch.

Details

The finalized state writer at zebra-state/src/service/finalized_state/zebra_db/transparent.rs iterates all transaction outputs in a block and credits them to per-address balances before iterating inputs and debiting spent outputs. When a block contains many transparent self-spends to the same address, the intermediate credit-only balance can exceed the MAX_MONEY supply cap even though the final net balance (credits minus debits) is valid.

The code panics on the intermediate overflow via .expect() on the balance addition. Under Zebra's panic = "abort" release profile, this terminates the process. On restart, the node re-downloads and re-processes the same consensus-valid block, triggering the same panic.

An attacker with approximately 1,100–2,100 ZEC and mining capability can construct a block that permanently halts all Zebra nodes. The attacker recovers their capital (the self-spends return funds to the same address), so the net cost is the mining effort only.

Patches

Patched in Zebra 4.4.2. The fix processes credits and debits together per transaction rather than all credits then all debits, matching zcashd's approach.

Workarounds

No workaround is available. Upgrade to Zebra 4.4.2.

Impact

A single consensus-valid mined block can permanently halt all Zebra nodes on the network. The halt persists across restarts. Recovery requires deploying a patched version. Downstream consumers (light wallets, exchanges, mining infrastructure) lose service for the duration of the halt.

Credit

Reported by @sangsoo-osec.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections and is syncing or catching up to the chain tip.

Summary

A malicious peer can answer Zebra's outbound getblocks/FindBlocks request with a small two-hash inventory, then serve a syntactically valid block whose coinbase height is far above the victim's local tip. The AboveLookaheadHeightLimit error in the sync download pipeline triggers a global sync restart rather than being scoped to the offending peer. The peer is never scored or disconnected because the error type does not carry the advertiser address.

On mainnet, each successful cycle imposes a 67-second sync restart delay. All in-flight downloads from honest peers are cancelled on each restart.

Details

The bug is the interaction of three layers:

1. The syncer promotes unvalidated FindBlocks peer responses into concrete download schedules without checking that the advertised hashes are plausible chain extensions.

2. When a downloaded block's coinbase height exceeds tip + VERIFICATION_PIPELINE_DROP_LIMIT, the sync downloader returns BlockDownloadVerifyError::AboveLookaheadHeightLimit. This error variant carries only the block height and hash, not the advertiser peer address.

3. The sync error handler in handle_block_response only sends misbehaviour scores for BlockDownloadVerifyError::Invalid errors that carry an advertiser_addr and have a nonzero misbehavior_score(). AboveLookaheadHeightLimit falls through to the default restart-worthy path, cancelling all in-flight downloads and waiting 67 seconds before restarting sync.

The attacker needs only an unauthenticated P2P connection (post-handshake), a tiny payload (one two-hash inv message plus one small block per cycle), and no mining capability, funds, or valid chain data. The peer is never penalised, so the attack is repeatable indefinitely.

Additionally, several other pre-consensus sync-layer errors had zero misbehaviour scores even when peer-attributed. Contextual validation failures (InvalidDifficultyThreshold, TimeTooEarly, TimeTooLate, NonSequentialBlock) and locktime failures from block-serving peers all scored zero, allowing repeated abuse without penalty.

Patches

Patched in Zebra 4.4.2. The fix:

• Carries advertiser_addr through AboveLookaheadHeightLimit and InvalidHeight error variants.
• Makes above-lookahead and invalid-height failures peer-local (the block is dropped and the peer is banned with score 100) rather than triggering a global sync restart.
• Expands misbehavior_score() across BlockError, VerifyBlockError, and CommitBlockError to cover contextual validation failures that previously scored zero.

Workarounds

No configuration-level workaround is available. The attack is mitigated by having a diverse honest peer set, but cannot be prevented while the vulnerable code is running.

Impact

A single unauthenticated peer can repeatedly stall a syncing Zebra node by forcing 67-second global sync restart cycles. All unrelated in-flight downloads are cancelled on each restart. The node does not crash and no state is corrupted, but sync progress is significantly degraded for the duration of the attack.

Credit

Reported by @ipwning.

Am I affected

You are affected if:

1. You run any version of zebrad up to and including v4.4.1.
2. Your node validates blocks on mainnet, testnet, or any network where both Zebra and zcashd nodes participate.

All default configurations are affected. No feature flags, non-default settings, or special build options are required.

Summary

Zebra's P2SH sigop counter uses a pure-Rust code path that short-circuits on disabled opcodes (such as OP_CODESEPARATOR), returning a partial count of zero for any sigops following the disabled opcode. The reference implementation (zcashd) correctly counts through disabled opcodes in its static sigop analysis. This produces a consensus divergence: Zebra accepts blocks that zcashd rejects when the block-wide MAX_BLOCK_SIGOPS = 20,000 threshold is crossed on one side but not the other.

An attacker can exploit this without mining capability. Broadcasting transactions that spend P2SH outputs with malicious redeem scripts is sufficient; any Zebra miner who includes those transactions in a block triggers a chain split between Zebra and zcashd validators.

Details

The P2SH sigop counter at zebra-script/src/lib.rs:399 calls script::Code(redeemed_bytes).sig_op_count(true), which is a pure-Rust path through zcash_script-0.4.4. The legacy (non-P2SH) sigop counter at lib.rs:282-289 correctly uses the C++ FFI via interpreter.legacy_sigop_count_script(). Only the P2SH path bypasses the FFI.

The Rust parser in zcash_script-0.4.4/src/opcode/mod.rs:1247-1260 treats 16 disabled opcodes (0x7e through 0xab, including OP_CAT, OP_SUBSTR, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT, OP_RSHIFT, and OP_CODESEPARATOR) as Err(Error::Disabled(...)). The sig_op_count function at iter.rs:104-115 uses try_fold, which terminates on the first Err and returns the partial sum accumulated so far.

zcashd's GetOp2 (script.h:514-562) returns true for all non-push opcodes including the disabled range. Its GetSigOpCount(true) (script.cpp:152-174) continues counting through disabled opcodes. zcashd rejects disabled opcodes at execution time in the interpreter, not during static sigop analysis.

A redeem script of [0xab, OP_CHECKMULTISIG x 50] produces: Zebra = 0 sigops, zcashd = 1,000 sigops. Across 21 inputs in a block, Zebra computes 0 while zcashd computes 21,000, crossing the MAX_BLOCK_SIGOPS = 20,000 threshold on one side only.

Patches

Patched in Zebra 4.4.2. The fix routes the P2SH sigop counter through the same C++ FFI already used by the legacy sigop counter.

Workarounds

There is no configuration-level workaround. All Zebra nodes validating blocks on a network shared with zcashd are affected. Upgrade as soon as the patched version is available.

Impact

A chain split between Zebra and zcashd validators. The attacker broadcasts spending transactions referencing P2SH outputs whose redeem scripts contain a disabled opcode followed by OP_CHECKSIG or OP_CHECKMULTISIG opcodes. When a Zebra miner (estimated ~30% of current network hashrate) includes these transactions in a block, Zebra validators accept the block while zcashd validators reject it with bad-blk-sigops. The two halves of the network diverge and every subsequent block extending the Zebra-side tip inherits the divergence.

The attacker does not need mining capability, RPC access, or any special privileges. The cost is the transaction fees for the funding and spending transactions.

Credit

Reported by @samsulselfut via a private GitHub Security Advisory submission.

Description

Am I affected

You are affected if:

1. You run any version of zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node processes blocks past the checkpoint height (non-finalized state is active).

All default configurations are affected.

Summary

Zebra records a block hash in non_finalized_block_write_sent_hashes when the block is sent to the write task, before contextual validation completes. If validation fails, the hash is not removed. A remote unauthenticated peer can deliver a poisoned block body that shares a header hash with a later valid canonical block. The poisoned body is rejected, but the hash remains cached. When the valid canonical block arrives, Zebra treats it as a duplicate and rejects it. The node cannot advance past that height until restart or a reorg event.

Details

ZIP-244 defines txid_v5 without binding transparent input scriptSig, which lives in auth_digest and is committed to by hashBlockCommitments in the block header. Because merkle_root is computed over txids (not auth digests), and the block hash is computed over the header, an attacker can construct two blocks with identical header hashes but different transaction bodies by mutating the coinbase scriptSig.

The attack flow over P2P:

1. Attacker observes a new block header (from any peer).
2. Attacker constructs a poisoned body by flipping a byte of the coinbase scriptSig extra-data section. The block hash is unchanged.
3. Attacker advertises the block hash via inv to the target node.
4. Target requests the block via getdata; attacker serves the poisoned body.
5. Zebra adds the hash to non_finalized_block_write_sent_hashes before validation.
6. The write task rejects the body at block_commitment_is_valid_for_chain_history (auth_data_root mismatch).
7. The hash is not removed from non_finalized_block_write_sent_hashes.
8. When the valid canonical block arrives (from honest peers or RPC), queue_and_commit_to_non_finalized_state sees the hash in the cache and returns KnownBlock::WriteChannel duplicate.
9. The node is stuck at height N-1.

A secondary variant exists where chain pruning (via MAX_NON_FINALIZED_CHAIN_FORKS) removes a chain from chain_set but leaves its block hashes in non_finalized_block_write_sent_hashes, producing the same lockout for children of the pruned fork.

Patches

Patched in Zebra 4.4.2. The fix removes stale entries from non_finalized_block_write_sent_hashes on every failed non-finalized write path.

Workarounds

There is no complete configuration-level workaround. Reducing the node's inbound peer count (network.peerset_initial_target_size) narrows the attack surface but does not eliminate it. Restarting the node clears the in-memory cache and allows the valid block to be re-fetched.

Impact

A remote unauthenticated P2P peer can permanently stall a targeted Zebra node at a specific block height. The node diverges from the network tip; downstream consumers (lightwalletd, wallets, explorers, mining infrastructure) relying on the node see a stalled chain. The attack requires winning a propagation race: delivering the poisoned block body before honest peers deliver the canonical block. A well-positioned attacker (low-latency connection to the target, observation of new blocks from other peers) can reliably win this race. In sustained form, the attacker repeats for each new block, keeping the target permanently behind.

Recovery requires restarting the node (which clears the in-memory sent-hash cache) or waiting for a reorg at the affected height (rare on the canonical chain).

Credit

Reported independently by @ipwning (primary, with ZIP-244 malleability analysis and zcashd cross-reference) and @x15-eth (first reporter, with E2E reproduction and control experiment).

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).

Summary

The P2P codec's Codec::decode() method calls src.reserve(body_len + HEADER_LEN) after parsing a 24-byte protocol header, using the attacker-claimed body_len field. This reserves up to MAX_PROTOCOL_MESSAGE_LEN (~2 MiB) of virtual buffer capacity per connection before any body bytes arrive and before the handshake completes.

However, BytesMut::reserve() sets virtual capacity without committing physical memory pages. The operating system does not allocate physical RAM until bytes are actually written into the buffer. Since the attacker never sends body bytes, the reserved capacity remains uncommitted. Reproduction of the reporter's PoC (256 threads, 30 seconds of sustained connections) showed negligible RSS impact on the Zebra process.

Zebra's existing mitigations further constrain the practical attack surface: per-IP connection limits (max_connections_per_ip = 1), a per-connection accept rate of approximately one per second, and a 3-second handshake timeout that cleans up idle connections.

Details

At zebra-network/src/protocol/external/codec.rs:406, after parsing the 24-byte header and validating the network magic and body length against MAX_PROTOCOL_MESSAGE_LEN, the codec calls src.reserve(body_len + HEADER_LEN). The codec is constructed on the bare TCP stream before negotiate_version() runs, so the reservation is reachable from any TCP peer that can send 24 bytes.

No legitimate Zcash handshake message (version, verack) is anywhere close to 2 MiB. The codec makes no distinction between pre-handshake and post-handshake message types when sizing the reservation.

Patches

The fix defers large buffer reservations until after the handshake completes, or caps the per-message reservation for pre-handshake messages to what version/verack actually require.

Workarounds

No workaround is needed. The existing per-IP rate limiting, handshake timeout, and connection limits effectively mitigate the practical impact.

Impact

Minimal. The reservation affects virtual address space only, not physical memory. Zebra's existing connection-management mitigations (per-IP limits, accept rate, handshake timeout) further constrain the attack. The code path is worth cleaning up for defense-in-depth but does not produce a measurable denial-of-service effect.

Credit

Reported by @ouicate via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

Summary

A single unauthenticated P2P peer can monopolize all 25 inbound mempool download/verification slots (MAX_INBOUND_CONCURRENCY) by advertising fake transaction IDs. While the slots are occupied, all other inbound transactions from honest peers and local RPC sendrawtransaction calls are rejected with MempoolError::FullQueue. The attacker peer is never scored for misbehavior and is not disconnected, allowing sustained denial of mempool admission.

Details

The mempool download/verification pipeline at zebrad/src/components/mempool/downloads.rs uses a single bounded pool of 25 concurrent tasks. Three architectural gaps combine to produce the vulnerability:

1. No per-peer accounting: the 25 slots are shared across all peers with no cap on how many a single peer can hold.
2. No overload signaling: when FullQueue is returned, the inbound service at zebrad/src/components/inbound.rs maps it to Response::Nil, hiding the overload from the peer connection layer. The existing handle_inbound_overload disconnection logic never fires.
3. No misbehavior attribution: peer identity is not carried through the Gossip type into the download pipeline, so verification failures cannot be attributed to the originating peer.

The attacker sends inv messages advertising fake transaction IDs. Zebra queues download tasks for each ID. The attacker stays silent; each slot is held until the TRANSACTION_DOWNLOAD_TIMEOUT (20 seconds) fires. The attacker periodically sends fresh inv waves to re-fill slots as they expire.

Two additional slot-holding techniques have been independently demonstrated: invalid-prevout transactions that park in AwaitOutput for 60 seconds, and expensive shielded proof verification with auth-variant cache bypass. All three techniques are addressed by the same per-peer accounting fix.

Patches

zebrad 4.5.0

The fix adds per-peer queue accounting to the mempool download pipeline. A single peer is limited to a fraction of MAX_INBOUND_CONCURRENCY (e.g., 5 slots out of 25). FullQueue is surfaced as an overload signal to the peer connection layer. Peer identity is plumbed through the Gossip type for misbehavior attribution.

Workarounds

There is no complete configuration-level workaround. Reducing network.peerset_initial_target_size limits the total inbound peer count but does not prevent a single peer from holding all mempool slots.

Impact

Mempool transaction admission is denied for all honest peers and local RPC clients while the attack is sustained. Block validation and chain synchronization continue normally. The attacker needs only one TCP connection and minimal bandwidth (~1 KB/s of fake inv messages). The node recovers immediately when the attacker stops. This does not affect consensus, funds, or on-disk state.

Credit

Reported by @dingledropper via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file (typically local access). With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The z_listunifiedreceivers RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (sapling_crypto::PaymentAddress::from_bytes returns None for non-subgroup Jubjub points). The handler calls .expect("using data already decoded as valid") on the fallible result. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process, not just the RPC task.

Details

zcash_address::unified::Encoding::decode validates only the structural envelope of a Unified Address (F4Jumble, bech32m, typecode ordering, 43-byte length for Sapling). It does not validate that the embedded pk_d is a valid Jubjub subgroup point or that the diversifier produces a valid g_d preimage.

At zebra-rpc/src/methods.rs:2893, the handler calls Address::try_from_sapling(network, data), which delegates to sapling_crypto::PaymentAddress::from_bytes. When from_bytes returns None (most random 32-byte strings fail the subgroup check), the .expect() fires and the process aborts.

The same crate already handles this correctly in try_from_unified at zebra-chain/src/primitives/address.rs:99-110, which returns Err when from_bytes fails. The vulnerable code path bypasses this validated route.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace .expect() with .map_err(|e| ErrorObject::owned(...)) for proper error propagation, or route through the existing try_from_unified path which already handles this case correctly.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that rejects z_listunifiedreceivers calls with untrusted address parameters.

Impact

A single authenticated RPC request terminates the zebrad process. The attack is repeatable on restart (the same request triggers the same abort), allowing an attacker to keep the node down indefinitely until the request is filtered upstream. Operators using lightwalletd backends, Zaino indexers, or mining pool infrastructure that forward RPC calls to zebrad may be exposed if the forwarding path passes through z_listunifiedreceivers.

Credit

Reported by @robustfengbin via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections.

Summary

The read_getblocks and read_getheaders codec paths accepted block locator vectors up to approximately 65,535 entries (the generic TrustedPreallocate ceiling derived from MAX_PROTOCOL_MESSAGE_LEN), rather than the protocol-specification limit of 101 entries (matching zcashd's MAX_LOCATOR_SZ). Each entry in the locator vector triggers a per-hash chain lookup (HashMap::contains_key + RocksDB::contains_hash) in find_chain_intersection on a tokio blocking-pool thread.

A single maximally-sized getblocks message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups.

Details

The read_headers codec path already implements the correct pattern: it reads the CompactSize count, validates against MAX_HEADERS_PER_MESSAGE = 160 before deserialization, and rejects oversized messages. The read_getblocks and read_getheaders paths were missing this pre-deserialization count check and instead relied on the generic block::Hash::max_allocation() bound, which allows (MAX_PROTOCOL_MESSAGE_LEN - 1) / 32 = 65,535 hashes.

A legitimate block locator is logarithmic in chain length (approximately 30 hashes for the current ~3M-block Zcash chain). Zebra's own send-side cap is MAX_FIND_BLOCK_HASHES_RESULTS = 500.

The practical impact requires significant attacker bandwidth (approximately 2 MiB per request) and multiple Sybil peers to meaningfully degrade the blocking pool, which limits real-world exploitability.

Patches

Patched in Zebra 4.4.2. The fix caps block::Hash::max_allocation() at MAX_BLOCK_LOCATOR_LENGTH = 101, matching zcashd's MAX_LOCATOR_SZ. This causes the deserializer to reject oversized locators before any allocation or iteration occurs.

Workarounds

No specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.

Impact

Under sustained load from multiple Sybil peers, oversized locator vectors can occupy blocking-pool threads and degrade state-read performance. The effect is bounded by connection limits and requires significant attacker bandwidth.

Credit

Vulnerability identified by @dingledropper, who submitted the fix in PR #10570. Downstream CPU/blocking-pool impact analysis contributed by @ouicate.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output

Summary

Zebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with SIGHASH_SINGLE and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but zcashd rejects, creating a consensus split between Zebra and zcashd nodes.

A previous fix (GHSA-cwfq-rfcr-8hmp) addressed a closely related case in the same area of the code, but did not cover this specific one.

Severity

Critical - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.

Note that the impact is currently alleviated by the fact that currently most miners run zcashd.

Affected Versions

Zebra 4.4.0.

Description

Verification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code is called from Zebra through a foreign function interface (FFI), with a Rust callback that computes the sighash for each input being verified.

ZIP-244 §S.2a marks two situations as consensus failure for V5 transparent signatures:

1. The signed hash type is not one of the six canonical values; and
2. The hash type is SIGHASH_SINGLE (alone or combined with ANYONECANPAY) and the input has no transparent output at the same index.

zcashd enforces both rules: its SignatureHash raises an exception, and CheckSig catches it and fails the script. A previous fix (GHSA-cwfq-rfcr-8hmp) added the first rule to Zebra's V5 sighash callback. The second rule, however, was not added — Zebra's callback forwarded the request to librustzcash's ZIP-244 implementation, which handles an out-of-range SIGHASH_SINGLE output index by hashing an empty output set rather than refusing to produce a digest. As a result, Zebra would compute a well-defined sighash for the missing-output case and accept any signature that verified against it.

An attacker could exploit this by:

• Constructing a V5 transaction with two or more transparent inputs and fewer transparent outputs;
• Signing an input whose index has no matching vout entry with SIGHASH_SINGLE (0x03) or SIGHASH_SINGLE|ANYONECANPAY (0x83), using the digest Zebra computes;
• Broadcasting the transaction, or a block containing it, to the network.

Zebra would verify the transaction's transparent script and accept the transaction (and any block containing it), while zcashd would reject both, splitting Zebra nodes from the rest of the network.

Impact

Consensus Failure

• Attack Vector: Network.
• Effect: Network partition/consensus split.
• Scope: Any affected Zebra node.

Fixed Versions

This issue is fixed in Zebra 4.4.1.

Mitigation

Users should upgrade to Zebra 4.4.1 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.

Credits

Zebra thanks @sangsoo-osec, @zmanian, and @fivelittleducks for finding and reporting the issue.

Summary

A soundness vulnerability in the variable-base scalar multiplication gadget of halo2_gadgets allowed a malicious prover to produce a valid proof for an Orchard Action with an under-constrained base point. Because this gadget enforces the diversified-address-integrity condition of the Orchard Action statement, the flaw let a prover satisfy that condition for an arbitrary (pkd, gd, ivk) triple, effectively bypassing the check that binds an Action to the correct incoming viewing key — and therefore to the correct nullifier (nf) and spend validating key (ak) — of the note being spent.

The main practical consequence is that an adversary could have performed a double-spend within the Orchard pool, resulting in a balance violation: the same note could be spent multiple times, each time revealing a distinct, valid-looking nullifier. The total ZEC supply was protected by Zcash's turnstile mechanism, which bounds value flowing out of any pool, so unbounded inflation of the overall supply was not possible; the exposure was inflation of value within the Orchard pool up to the turnstile-enforced limit.

Exploiting the vulnerability via a double-spend is undetectable on-chain. Exploitation only requires setting private circuit inputs to chosen values, and nullifiers produced by a double-spend are indistinguishable from honest nullifiers, so the zero-knowledge property hides any signature of the attack.

Alternatively, an adversary could (before the fix) have stolen funds by forging a spend authorization for an existing note. To do so they would have to know the note plaintext, which in practice they might obtain by knowing the corresponding incoming viewing key. For example, this could be used to bypass the protection provided by holding spending keys on a hardware wallet, if the linked software wallet were compromised. This form of exploitation cannot be detected via the turnstile (which might be a motivation to exploit the vulnerability in this way rather than via balance violation). It can be detected by the legitimate holder of stolen funds being unable to spend them, or by seeing the note's nullifier on-chain — but this cannot necessarily be distinguished from compromise of the spending key by other means.

The vulnerability has existed since the Orchard pool was introduced in the NU5 network upgrade (activated May 31, 2022). There is no evidence it was exploited prior to remediation.

Note that use of the vulnerability, either for balance violation or for theft of funds, would need to have occurred before it was remediated. Theft would be in principle detectable from that point (since the real nullifier would appear on-chain). Balance violation would not be detectable at the point of exploitation.

Root cause

The defect is in the double-and-add implementation of variable-base scalar multiplication in halo2_gadgets/src/ecc/chip/mul/incomplete.rs. For performance, the algorithm uses incomplete point-addition formulas in its intermediate stage. (Incomplete addition is safe here in principle: the first and last stages use complete addition, and reaching a degenerate case would require breaking discrete log.)

The base point is fed into the incomplete-addition stage via assign_advice(), which assigns a witness value (a private circuit input) without introducing a constraint that ties that value to the actual base the algorithm is supposed to operate on:

region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?;
region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?;

(halo2_gadgets/src/ecc/chip/mul/incomplete.rs, around L309–L310 at commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea.)

The existing q_mul_2 constraint forces the base values used across the incomplete-addition loop to be equal to one another, but nothing forces them to equal the actual base. A malicious prover therefore has complete freedom to choose the base used by the loop. Given target pkd, gd, and ivk, the prover can solve for the base value that makes the computed [ivk] gd equal the desired pkd, satisfying the diversified-address-integrity equation pkdold = [ivk] gdold for inputs that an honest prover could never satisfy.

Why this enables a double-spend

The Orchard Action statement constrains the nullifier of the spent note to be derived from the correct nullifier key nk, which in turn is bound to the correct incoming viewing key ivk, via ivk = Commitivkrivk(Extractℙ(akℙ), nk). The diversified-address-integrity check pkd = [ivk] gd is what normally guarantees the prover used the correct ivk —and hence the correct nk— for the note. With that check bypassable:

1. The prover picks a fresh, incorrect nk for the note being spent. Since nk feeds the nullifier computation, a wrong nk yields a different nullifier for the same note.
2. Other circuit constraints still force the prover to derive ivk honestly from that wrong nk, producing a wrong ivk for the note — which would normally be caught by the integrity check.
3. The prover uses the under-constrained base to satisfy pkd = [ivk] gd anyway, defeating the check.
4. Each distinct wrong nk produces a distinct valid nullifier, allowing the note to be spent repeatedly.

Why this enables theft

The spend validating key, akℙ (essentially equivalent to ak), is also constrained via ivk = Commitivkrivk(Extractℙ(akℙ), nk). As above, the diversified-address-integrity check is what normally guarantees the prover used the correct ivk —and hence the correct ak— for the note. With that check bypassable:

1. The prover picks an ak for which they know the private key, ask.
2. They construct a transaction that spends the victim's notes, and sign it using that ask.

Impact

• Integrity: High. A malicious prover could spend Orchard notes multiple times, inflating value within the Orchard pool. This is bounded only by the turnstile limit on the pool. Alternatively, the prover could authorize spending other users' notes without having the spending key.
• Confidentiality: None. The zero-knowledge property is intact; no private data is disclosed. This is also why the attack leaves no observable on-chain signature.
• Availability: Not directly affected by the bug. (The coordinated response temporarily disabled Orchard actions as a mitigation; that was an operational choice, not an effect of the vulnerability.) On the other hand, either theft of funds, or inability to spend funds due to a future turnstile violation could be considered an availability consequence.

Affected versions

• halo2_gadgets < 0.5.0
• orchard < 0.14.0
• zcash_primitives < 0.28.0
• zcashd < 6.20.0
• zebrad < 5.0.0

Patches

The circuit-level fix replaces the first-iteration assign_advice() calls for the base point with copy_advice(), introducing a copy constraint that requires the first base value to equal the correct base. Combined with the existing q_mul_2 equality constraint across the loop, this transitively constrains every base value in the incomplete-addition stage to the correct base, closing the freedom the attacker relied on.

Because remediating a zero-knowledge circuit changes the pinned verifying key, the network-level fix required a hard fork (NU6.2). NU6.2 re-enables Orchard with the corrected circuit and routes Orchard proofs to a per-circuit verifying key (InsecurePreNu6_2 / FixedPostNu6_2).

• halo2_gadgets 0.5.0
• orchard 0.14.0
• zcash_primitives 0.28.0
• zebrad 5.0.0 (NU6.2); 4.5.3 ships the interim soft-fork mitigation
• zcashd 6.20.0 (NU6.2)

Workarounds / mitigations

There is no client-side workaround for the underlying soundness flaw short of the circuit fix. The deployed interim mitigation (Zebra 4.5.3 / equivalent) was a soft fork that rejected all Orchard-containing transactions and blocks, fully neutralizing exploitation until NU6.2 activated.

Downstream projects that depend on the affected crates should:

• Upgrade halo2_gadgets, orchard, and zcash_primitives to the patched versions above.
• Audit any other use of assign_advice() (and similar non-constraining assignment APIs) where the intended invariant is that a witnessed value equals a known/fixed value; such sites should use copy_advice() (or otherwise enforce an explicit constraint).

Indicators / detection

Exploitation produces no distinguishing on-chain signature. The turnstile mechanism, which tracks total ZEC across all value pools, provides a ground-truth supply check and confirmed the total supply remained intact. Heuristic analysis of Orchard transaction arity (e.g. patterns of duplicate-then-consolidate behavior) is possible but inconclusive against normal shielded-activity variance.

Timeline (MDT)

| Date / Time | Event | |---|---| | 2022-05-31 11:50 | Vulnerable NU5 upgrade activates (bug introduced) | | 2026-05-29 (evening) | Vulnerability discovered during a protocol audit | | 2026-05-29 23:53 | Responsibly disclosed to ZODL core engineers | | 2026-05-30 06:30 | Disclosure acknowledged by ZODL | | 2026-06-01 (~21:30) | Emergency soft-fork mitigation activated (block 3,363,426) | | 2026-06-03 00:05 EDT | NU6.2 hard fork activates, Orchard re-enabled with fix (block 3,364,600) |

Credits

Discovered and responsibly disclosed by Taylor Hornby, independent security researcher, during a protocol audit conducted on behalf of Shielded Labs. Analysis and remediation was led by ZODL engineers Jack Grigg, Daira-Emma Hopwood, and Kris Nuttycombe, with Zebra patch work by Arya Solhi (Zcash Foundation).

Resources

• Zcash Foundation: Zebra 4.5.3 and 5.0.0: Emergency Soft Fork and NU6.2 Activation — https://zfnd.org/zebra-4-5-3-and-5-0-0-emergency-soft-fork-and-nu6-2-activation/
• Affected source (pre-fix): halo2_gadgets/src/ecc/chip/mul/incomplete.rs @ commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea, L309–L310

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node listens on the default [::] address on a Linux host (the standard deployment configuration — net.ipv6.bindv6only=0 is the default on all common Linux distributions).
3. Your node is synced near the chain tip (the expected production state for any node participating in the network).

Summary

An address normalization mismatch between the handshake path and the mempool misbehavior path causes a deterministic assertion panic when a peer connects via IPv4 to a dual-stack IPv6 listener and then triggers a mempool misbehavior penalty.

The handshake path canonicalizes IPv4-mapped IPv6 addresses to plain IPv4 when storing the peer in the address book via MetaAddr::new_connected. The mempool misbehavior path forwards the raw transient socket address (IPv4-mapped IPv6 form) when sending MetaAddrChange::UpdateMisbehavior to the address book. The address book looks up the canonical IPv4 entry but then asserts that the previous entry's address matches the change's address. The mismatch between the canonical IPv4 address and the raw IPv4-mapped IPv6 address triggers the assertion, and panic = "abort" terminates the process.

Details

On Linux with net.ipv6.bindv6only=0, an IPv4 connection accepted by a [::] listener is represented internally as an IPv4-mapped IPv6 socket address (e.g., ::ffff:127.0.0.1:8233). Zebra's canonical_peer_addr helper converts these to plain IPv4 (e.g., 127.0.0.1:8233).

The handshake path uses MetaAddr::new_connected, which canonicalizes the address before storing in the address book. However, inbound inventory registration uses connected_addr.get_transient_addr(), preserving the raw IPv4-mapped form. When the mempool later downloads an invalid transaction from this peer and generates a misbehavior penalty, the raw transient address is forwarded through the misbehavior channel to MetaAddrChange::UpdateMisbehavior, which does not canonicalize.

After the 30-second misbehavior batch flush, AddressBook::update retrieves the canonical IPv4 entry but MetaAddrChange::apply_to_meta_addr asserts that previous.addr == self.addr(), which fails because one is IPv4 and the other is IPv4-mapped IPv6.

The attacker needs only to complete a P2P handshake over IPv4 to a dual-stack listener and advertise an invalid mempool transaction (such as a coinbase transaction). The assertion fires after the 30-second misbehavior batch flush.

Patches

Patched in Zebra 4.5.0. The fix canonicalizes the address in the misbehavior update path via a new MetaAddr::new_misbehavior constructor that applies canonical_peer_addr before creating the UpdateMisbehavior change.

Workarounds

Configuring listen_addr to an IPv4-only address (e.g., 0.0.0.0:8233) avoids the IPv4-mapped IPv6 representation and prevents this specific assertion. Alternatively, setting net.ipv6.bindv6only=1 on Linux prevents dual-stack acceptance.

Impact

A remote unauthenticated peer can deterministically crash any synced Zebra node running the default Linux dual-stack configuration with a single invalid mempool transaction advertisement, followed by a 30-second wait. The attack requires no mining capability, no RPC access, no funds, and no special privileges. The crash can be repeated after each restart, causing persistent downtime. Linux dual-stack sockets and mempool activation are the default production state, not special preconditions.

Credit

Reported by @Haxatron.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

Summary

The mempool download pipeline's cancel_handles map retains entries for transactions whose verification times out at the outer RATE_LIMIT_DELAY (73-second) boundary. The tokio::time::error::Elapsed error carries no payload, so the transaction ID is unrecoverable and the corresponding cancel_handles entry (including the full Gossip::Tx(UnminedTx), up to ~2 MB) is never removed. Entries accumulate monotonically with no upper bound or garbage collection, leading to eventual out-of-memory process termination.

Details

Downloads::poll_next() at zebrad/src/components/mempool/downloads.rs:215-228 handles three terminal states for a verification task:

• Ok(Ok(...)): success. Calls cancel_handles.remove(&tx.transaction.id). Correct.
• Ok(Err(...)): verification error. Calls cancel_handles.remove(&hash). Correct.
• Err(elapsed): outer timeout. Returns Err(elapsed) without removing anything. Bug.

tokio::time::error::Elapsed has no payload, so the timed-out transaction's UnminedTxId is unrecoverable from the error. The consumer at zebrad/src/components/mempool.rs:663-672 explicitly acknowledges this gap with a TODO comment.

The only cleanup paths for cancel_handles are cancel(mined_ids) (removes entries matching mined transaction IDs; attacker transactions are never mined) and cancel_all() (clears everything on shutdown or chain reset). No periodic GC, no time-based eviction, and no count cap exists.

For direct tx pushes (Gossip::Tx), the retained entry holds the full deserialized transaction, which can be up to ~9 MB in memory for a transaction near the transparent-output extreme. Per-connection leak rate at worst case: ~685 KB/s (~2.4 GB/hour).

Patches

The fix preserves the UnminedTxId through the timeout error path: wrap the timeout future so the spawned task's outer error carries the txid (e.g., Err((txid, elapsed))). In Downloads::poll_next(), on the timeout arm, call cancel_handles.remove(&txid).

Workarounds

There is no configuration-level workaround. Restarting the node clears the accumulated entries. Operators running in memory-constrained environments (containers with cgroup limits) may see the process killed by the OOM killer before natural recovery.

Impact

Gradual, unbounded memory exhaustion of a Zebra node from unauthenticated P2P traffic. The leak is monotonic (entries are never freed under normal operation) but slow (~685 KB/s per connection worst case). An attacker must sustain traffic for hours to exhaust typical server memory. The node continues operating normally until memory pressure becomes critical, at which point the OS OOM killer terminates the process or the node degrades due to swap pressure. No consensus impact, no fund loss, no on-disk corruption.

Credit

Reported by @AnticsDecoded via a private GitHub Security Advisory submission. Working E2E reproduction on a live regtest node with staged parent/child transaction dependencies.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node participates in a network where chain forks occur (mainnet, testnet, or any network with multiple miners).

All default configurations are affected. The corruption persists across restarts because it is written to RocksDB.

Summary

When pop_tip removes the tip block during a chain fork, stale Sapling and Orchard note commitment subtree root data is retained in the in-memory non-finalized state. When the chain subsequently finalizes, this stale data is written to the persistent RocksDB state. The corrupted subtree root history affects z_getsubtreesbyindex (used by lightwalletd for wallet synchronization) and could affect future chain verification that depends on correct subtree roots.

Details

The non-finalized state provides two methods for removing blocks: pop_root (removes the oldest block during finalization) and pop_tip (removes the newest block during a fork revert). pop_root correctly cleans up note commitment subtree contributions. pop_tip does not: it removes the block but retains the block's subtree root contributions in the in-memory state.

When a chain fork occurs and pop_tip reverts the old tip, the winning fork's chain is extended. When that chain is later finalized, the stale subtree data from the reverted blocks is included in the RocksDB write batch and persisted to disk.

The pop_root/pop_tip asymmetry is specific to subtree root handling. Other state managed by pop_tip (nullifiers, UTXOs, anchors, block hashes) uses different cleanup patterns that are not affected.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

The fix adds subtree root cleanup to pop_tip matching the pattern already used by pop_root.

Workarounds

There is no configuration-level workaround. Chain forks are natural events on any Proof-of-Work network. Operators can mitigate the downstream impact by periodically verifying subtree root consistency using z_getsubtreesbyindex against a known-good reference.

Impact

Persistent corruption of Sapling and Orchard subtree root history in the RocksDB state database. The corruption survives node restarts. Downstream consumers that rely on z_getsubtreesbyindex for wallet synchronization (primarily lightwalletd and light wallets) receive incorrect subtree roots. This does not directly affect consensus validation of new blocks but can cause wallet synchronization failures or incorrect wallet state. Recovery requires rebuilding the state database from scratch.

Credit

Reported by @dingledropper via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node processes blocks past the checkpoint height (non-finalized state is active).
3. The network has NU5 or later activated.

All default configurations are affected.

Summary

Chain::push in the non-finalized state updates the transaction-location index (tx_loc_by_hash) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the assert_eq!(prior_pair, None, "transactions must be unique within a single chain") fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's panic = "abort" release profile, this terminates the entire node process.

The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within Chain::push causes the process to abort.

Details

In zebra-state/src/service/non_finalized_state/chain.rs:1608-1628, the block push sequence is:

1. Insert transaction hash into tx_loc_by_hash with assert_eq! on uniqueness
2. Update transparent outputs and inputs
3. Update shielded data (JoinSplit, Sapling, Orchard) — including nullifier uniqueness checks

The shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the assert_eq! at step 1 fires first because the transaction hash is already in tx_loc_by_hash from the parent block on the same chain.

The block transaction verifier does not run the best-chain nullifier query for block transactions — that check is gated on mempool transactions only (zebra-consensus/src/transaction.rs:521-526). Initial contextual validation checks nullifiers in finalized state only (zebra-state/src/service/check.rs:407-415), but the parent transaction is still in non-finalized state.

There are two attack models:

Model A (two attacker blocks): The attacker mines two consecutive valid-work blocks: parent B1 containing a shielded transaction T, and child B2 repeating T. This requires controlling both blocks consecutively.

Model B (one attacker block after an honest block): The attacker broadcasts a shielded transaction T into the mempool. When any honest miner includes T in their block B1, the attacker only needs to mine the next child block B2 containing the same T. This requires controlling only one block immediately after an honest block that included the attacker's transaction. The attacker can broadcast a suitable shielded transaction every block until one is included by an honest miner, then attempt to mine the follow-up.

Both models require the child block to repeat the shielded-only V5 transaction while the parent is still in non-finalized state.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

Replace the assert_eq! with an Entry-based check that returns ValidateContextError::DuplicateTransaction instead of panicking:

match self.tx_loc_by_hash.entry(transaction_hash) {
    Entry::Vacant(entry) => {
        entry.insert(transaction_location);
    }
    Entry::Occupied(_) => {
        return Err(ValidateContextError::DuplicateTransaction { transaction_hash });
    }
}

Workarounds

There is no configuration-level workaround. The assert is in the non-finalized state push path, which is exercised by all block processing past the checkpoint height.

Impact

A malicious block producer can crash targeted Zebra nodes. There are two attack models:

In the first model, the attacker mines two consecutive valid-work blocks where the child repeats a shielded transaction from the parent. At 10% hashrate, the attacker has approximately 11.5 opportunities per day; at 5%, approximately 2.9 per day; at 1%, approximately one every 8.7 days.

In the second model, the attacker broadcasts a shielded transaction into the mempool and waits for any honest miner to include it. The attacker then only needs to mine the next block containing the same transaction. This is cheaper because the attacker does not need to mine the parent block. At 10% hashrate, the attacker has approximately 14.4 single-block opportunities per day; at 5%, approximately 7.2 per day; at 1%, approximately 1.4 per day.

The crash is a process abort (not recoverable within the process). The node must be restarted. Repeated attacks can keep a node down for extended periods. This is a liveness issue, not a consensus divergence: zcashd cleanly rejects the invalid child block while Zebra aborts.

Credit

Reported by @haxatron via email disclosure.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node processes blocks on any Zcash network.

Summary

The finalized transparent address balance writer processes all newly-created outputs (credits) before processing spent outputs (debits) within the same block. A consensus-valid block containing a long chain of same-address transparent self-spends can cause the intermediate per-address balance during the credit pass to exceed MAX_MONEY, triggering a panic in the finalized state writer.

Because the triggering block is consensus-valid (zcashd accepts it), the panic recurs on restart when the node re-encounters the same block. This creates a persistent chain halt that can only be resolved by a software patch.

Details

The finalized state writer at zebra-state/src/service/finalized_state/zebra_db/transparent.rs iterates all transaction outputs in a block and credits them to per-address balances before iterating inputs and debiting spent outputs. When a block contains many transparent self-spends to the same address, the intermediate credit-only balance can exceed the MAX_MONEY supply cap even though the final net balance (credits minus debits) is valid.

The code panics on the intermediate overflow via .expect() on the balance addition. Under Zebra's panic = "abort" release profile, this terminates the process. On restart, the node re-downloads and re-processes the same consensus-valid block, triggering the same panic.

An attacker with approximately 1,100–2,100 ZEC and mining capability can construct a block that permanently halts all Zebra nodes. The attacker recovers their capital (the self-spends return funds to the same address), so the net cost is the mining effort only.

Patches

Patched in Zebra 4.4.2. The fix processes credits and debits together per transaction rather than all credits then all debits, matching zcashd's approach.

Workarounds

No workaround is available. Upgrade to Zebra 4.4.2.

Impact

A single consensus-valid mined block can permanently halt all Zebra nodes on the network. The halt persists across restarts. Recovery requires deploying a patched version. Downstream consumers (light wallets, exchanges, mining infrastructure) lose service for the duration of the halt.

Credit

Reported by @sangsoo-osec.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections and is syncing or catching up to the chain tip.

Summary

A malicious peer can answer Zebra's outbound getblocks/FindBlocks request with a small two-hash inventory, then serve a syntactically valid block whose coinbase height is far above the victim's local tip. The AboveLookaheadHeightLimit error in the sync download pipeline triggers a global sync restart rather than being scoped to the offending peer. The peer is never scored or disconnected because the error type does not carry the advertiser address.

On mainnet, each successful cycle imposes a 67-second sync restart delay. All in-flight downloads from honest peers are cancelled on each restart.

Details

The bug is the interaction of three layers:

1. The syncer promotes unvalidated FindBlocks peer responses into concrete download schedules without checking that the advertised hashes are plausible chain extensions.

2. When a downloaded block's coinbase height exceeds tip + VERIFICATION_PIPELINE_DROP_LIMIT, the sync downloader returns BlockDownloadVerifyError::AboveLookaheadHeightLimit. This error variant carries only the block height and hash, not the advertiser peer address.

3. The sync error handler in handle_block_response only sends misbehaviour scores for BlockDownloadVerifyError::Invalid errors that carry an advertiser_addr and have a nonzero misbehavior_score(). AboveLookaheadHeightLimit falls through to the default restart-worthy path, cancelling all in-flight downloads and waiting 67 seconds before restarting sync.

The attacker needs only an unauthenticated P2P connection (post-handshake), a tiny payload (one two-hash inv message plus one small block per cycle), and no mining capability, funds, or valid chain data. The peer is never penalised, so the attack is repeatable indefinitely.

Additionally, several other pre-consensus sync-layer errors had zero misbehaviour scores even when peer-attributed. Contextual validation failures (InvalidDifficultyThreshold, TimeTooEarly, TimeTooLate, NonSequentialBlock) and locktime failures from block-serving peers all scored zero, allowing repeated abuse without penalty.

Patches

Patched in Zebra 4.4.2. The fix:

• Carries advertiser_addr through AboveLookaheadHeightLimit and InvalidHeight error variants.
• Makes above-lookahead and invalid-height failures peer-local (the block is dropped and the peer is banned with score 100) rather than triggering a global sync restart.
• Expands misbehavior_score() across BlockError, VerifyBlockError, and CommitBlockError to cover contextual validation failures that previously scored zero.

Workarounds

No configuration-level workaround is available. The attack is mitigated by having a diverse honest peer set, but cannot be prevented while the vulnerable code is running.

Impact

A single unauthenticated peer can repeatedly stall a syncing Zebra node by forcing 67-second global sync restart cycles. All unrelated in-flight downloads are cancelled on each restart. The node does not crash and no state is corrupted, but sync progress is significantly degraded for the duration of the attack.

Credit

Reported by @ipwning.

Am I affected

You are affected if:

1. You run any version of zebrad up to and including v4.4.1.
2. Your node validates blocks on mainnet, testnet, or any network where both Zebra and zcashd nodes participate.

All default configurations are affected. No feature flags, non-default settings, or special build options are required.

Summary

Zebra's P2SH sigop counter uses a pure-Rust code path that short-circuits on disabled opcodes (such as OP_CODESEPARATOR), returning a partial count of zero for any sigops following the disabled opcode. The reference implementation (zcashd) correctly counts through disabled opcodes in its static sigop analysis. This produces a consensus divergence: Zebra accepts blocks that zcashd rejects when the block-wide MAX_BLOCK_SIGOPS = 20,000 threshold is crossed on one side but not the other.

An attacker can exploit this without mining capability. Broadcasting transactions that spend P2SH outputs with malicious redeem scripts is sufficient; any Zebra miner who includes those transactions in a block triggers a chain split between Zebra and zcashd validators.

Details

The P2SH sigop counter at zebra-script/src/lib.rs:399 calls script::Code(redeemed_bytes).sig_op_count(true), which is a pure-Rust path through zcash_script-0.4.4. The legacy (non-P2SH) sigop counter at lib.rs:282-289 correctly uses the C++ FFI via interpreter.legacy_sigop_count_script(). Only the P2SH path bypasses the FFI.

The Rust parser in zcash_script-0.4.4/src/opcode/mod.rs:1247-1260 treats 16 disabled opcodes (0x7e through 0xab, including OP_CAT, OP_SUBSTR, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT, OP_RSHIFT, and OP_CODESEPARATOR) as Err(Error::Disabled(...)). The sig_op_count function at iter.rs:104-115 uses try_fold, which terminates on the first Err and returns the partial sum accumulated so far.

zcashd's GetOp2 (script.h:514-562) returns true for all non-push opcodes including the disabled range. Its GetSigOpCount(true) (script.cpp:152-174) continues counting through disabled opcodes. zcashd rejects disabled opcodes at execution time in the interpreter, not during static sigop analysis.

A redeem script of [0xab, OP_CHECKMULTISIG x 50] produces: Zebra = 0 sigops, zcashd = 1,000 sigops. Across 21 inputs in a block, Zebra computes 0 while zcashd computes 21,000, crossing the MAX_BLOCK_SIGOPS = 20,000 threshold on one side only.

Patches

Patched in Zebra 4.4.2. The fix routes the P2SH sigop counter through the same C++ FFI already used by the legacy sigop counter.

Workarounds

There is no configuration-level workaround. All Zebra nodes validating blocks on a network shared with zcashd are affected. Upgrade as soon as the patched version is available.

Impact

A chain split between Zebra and zcashd validators. The attacker broadcasts spending transactions referencing P2SH outputs whose redeem scripts contain a disabled opcode followed by OP_CHECKSIG or OP_CHECKMULTISIG opcodes. When a Zebra miner (estimated ~30% of current network hashrate) includes these transactions in a block, Zebra validators accept the block while zcashd validators reject it with bad-blk-sigops. The two halves of the network diverge and every subsequent block extending the Zebra-side tip inherits the divergence.

The attacker does not need mining capability, RPC access, or any special privileges. The cost is the transaction fees for the funding and spending transactions.

Credit

Reported by @samsulselfut via a private GitHub Security Advisory submission.

Description

Am I affected

You are affected if:

1. You run any version of zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node processes blocks past the checkpoint height (non-finalized state is active).

All default configurations are affected.

Summary

Zebra records a block hash in non_finalized_block_write_sent_hashes when the block is sent to the write task, before contextual validation completes. If validation fails, the hash is not removed. A remote unauthenticated peer can deliver a poisoned block body that shares a header hash with a later valid canonical block. The poisoned body is rejected, but the hash remains cached. When the valid canonical block arrives, Zebra treats it as a duplicate and rejects it. The node cannot advance past that height until restart or a reorg event.

Details

ZIP-244 defines txid_v5 without binding transparent input scriptSig, which lives in auth_digest and is committed to by hashBlockCommitments in the block header. Because merkle_root is computed over txids (not auth digests), and the block hash is computed over the header, an attacker can construct two blocks with identical header hashes but different transaction bodies by mutating the coinbase scriptSig.

The attack flow over P2P:

1. Attacker observes a new block header (from any peer).
2. Attacker constructs a poisoned body by flipping a byte of the coinbase scriptSig extra-data section. The block hash is unchanged.
3. Attacker advertises the block hash via inv to the target node.
4. Target requests the block via getdata; attacker serves the poisoned body.
5. Zebra adds the hash to non_finalized_block_write_sent_hashes before validation.
6. The write task rejects the body at block_commitment_is_valid_for_chain_history (auth_data_root mismatch).
7. The hash is not removed from non_finalized_block_write_sent_hashes.
8. When the valid canonical block arrives (from honest peers or RPC), queue_and_commit_to_non_finalized_state sees the hash in the cache and returns KnownBlock::WriteChannel duplicate.
9. The node is stuck at height N-1.

A secondary variant exists where chain pruning (via MAX_NON_FINALIZED_CHAIN_FORKS) removes a chain from chain_set but leaves its block hashes in non_finalized_block_write_sent_hashes, producing the same lockout for children of the pruned fork.

Patches

Patched in Zebra 4.4.2. The fix removes stale entries from non_finalized_block_write_sent_hashes on every failed non-finalized write path.

Workarounds

There is no complete configuration-level workaround. Reducing the node's inbound peer count (network.peerset_initial_target_size) narrows the attack surface but does not eliminate it. Restarting the node clears the in-memory cache and allows the valid block to be re-fetched.

Impact

A remote unauthenticated P2P peer can permanently stall a targeted Zebra node at a specific block height. The node diverges from the network tip; downstream consumers (lightwalletd, wallets, explorers, mining infrastructure) relying on the node see a stalled chain. The attack requires winning a propagation race: delivering the poisoned block body before honest peers deliver the canonical block. A well-positioned attacker (low-latency connection to the target, observation of new blocks from other peers) can reliably win this race. In sustained form, the attacker repeats for each new block, keeping the target permanently behind.

Recovery requires restarting the node (which clears the in-memory sent-hash cache) or waiting for a reorg at the affected height (rare on the canonical chain).

Credit

Reported independently by @ipwning (primary, with ZIP-244 malleability analysis and zcashd cross-reference) and @x15-eth (first reporter, with E2E reproduction and control experiment).

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).

Summary

The P2P codec's Codec::decode() method calls src.reserve(body_len + HEADER_LEN) after parsing a 24-byte protocol header, using the attacker-claimed body_len field. This reserves up to MAX_PROTOCOL_MESSAGE_LEN (~2 MiB) of virtual buffer capacity per connection before any body bytes arrive and before the handshake completes.

However, BytesMut::reserve() sets virtual capacity without committing physical memory pages. The operating system does not allocate physical RAM until bytes are actually written into the buffer. Since the attacker never sends body bytes, the reserved capacity remains uncommitted. Reproduction of the reporter's PoC (256 threads, 30 seconds of sustained connections) showed negligible RSS impact on the Zebra process.

Zebra's existing mitigations further constrain the practical attack surface: per-IP connection limits (max_connections_per_ip = 1), a per-connection accept rate of approximately one per second, and a 3-second handshake timeout that cleans up idle connections.

Details

At zebra-network/src/protocol/external/codec.rs:406, after parsing the 24-byte header and validating the network magic and body length against MAX_PROTOCOL_MESSAGE_LEN, the codec calls src.reserve(body_len + HEADER_LEN). The codec is constructed on the bare TCP stream before negotiate_version() runs, so the reservation is reachable from any TCP peer that can send 24 bytes.

No legitimate Zcash handshake message (version, verack) is anywhere close to 2 MiB. The codec makes no distinction between pre-handshake and post-handshake message types when sizing the reservation.

Patches

The fix defers large buffer reservations until after the handshake completes, or caps the per-message reservation for pre-handshake messages to what version/verack actually require.

Workarounds

No workaround is needed. The existing per-IP rate limiting, handshake timeout, and connection limits effectively mitigate the practical impact.

Impact

Minimal. The reservation affects virtual address space only, not physical memory. Zebra's existing connection-management mitigations (per-IP limits, accept rate, handshake timeout) further constrain the attack. The code path is worth cleaning up for defense-in-depth but does not produce a measurable denial-of-service effect.

Credit

Reported by @ouicate via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

Summary

A single unauthenticated P2P peer can monopolize all 25 inbound mempool download/verification slots (MAX_INBOUND_CONCURRENCY) by advertising fake transaction IDs. While the slots are occupied, all other inbound transactions from honest peers and local RPC sendrawtransaction calls are rejected with MempoolError::FullQueue. The attacker peer is never scored for misbehavior and is not disconnected, allowing sustained denial of mempool admission.

Details

The mempool download/verification pipeline at zebrad/src/components/mempool/downloads.rs uses a single bounded pool of 25 concurrent tasks. Three architectural gaps combine to produce the vulnerability:

1. No per-peer accounting: the 25 slots are shared across all peers with no cap on how many a single peer can hold.
2. No overload signaling: when FullQueue is returned, the inbound service at zebrad/src/components/inbound.rs maps it to Response::Nil, hiding the overload from the peer connection layer. The existing handle_inbound_overload disconnection logic never fires.
3. No misbehavior attribution: peer identity is not carried through the Gossip type into the download pipeline, so verification failures cannot be attributed to the originating peer.

The attacker sends inv messages advertising fake transaction IDs. Zebra queues download tasks for each ID. The attacker stays silent; each slot is held until the TRANSACTION_DOWNLOAD_TIMEOUT (20 seconds) fires. The attacker periodically sends fresh inv waves to re-fill slots as they expire.

Two additional slot-holding techniques have been independently demonstrated: invalid-prevout transactions that park in AwaitOutput for 60 seconds, and expensive shielded proof verification with auth-variant cache bypass. All three techniques are addressed by the same per-peer accounting fix.

Patches

zebrad 4.5.0

The fix adds per-peer queue accounting to the mempool download pipeline. A single peer is limited to a fraction of MAX_INBOUND_CONCURRENCY (e.g., 5 slots out of 25). FullQueue is surfaced as an overload signal to the peer connection layer. Peer identity is plumbed through the Gossip type for misbehavior attribution.

Workarounds

There is no complete configuration-level workaround. Reducing network.peerset_initial_target_size limits the total inbound peer count but does not prevent a single peer from holding all mempool slots.

Impact

Mempool transaction admission is denied for all honest peers and local RPC clients while the attack is sustained. Block validation and chain synchronization continue normally. The attacker needs only one TCP connection and minimal bandwidth (~1 KB/s of fake inv messages). The node recovers immediately when the attacker stops. This does not affect consensus, funds, or on-disk state.

Credit

Reported by @dingledropper via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file (typically local access). With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The z_listunifiedreceivers RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (sapling_crypto::PaymentAddress::from_bytes returns None for non-subgroup Jubjub points). The handler calls .expect("using data already decoded as valid") on the fallible result. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process, not just the RPC task.

Details

zcash_address::unified::Encoding::decode validates only the structural envelope of a Unified Address (F4Jumble, bech32m, typecode ordering, 43-byte length for Sapling). It does not validate that the embedded pk_d is a valid Jubjub subgroup point or that the diversifier produces a valid g_d preimage.

At zebra-rpc/src/methods.rs:2893, the handler calls Address::try_from_sapling(network, data), which delegates to sapling_crypto::PaymentAddress::from_bytes. When from_bytes returns None (most random 32-byte strings fail the subgroup check), the .expect() fires and the process aborts.

The same crate already handles this correctly in try_from_unified at zebra-chain/src/primitives/address.rs:99-110, which returns Err when from_bytes fails. The vulnerable code path bypasses this validated route.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace .expect() with .map_err(|e| ErrorObject::owned(...)) for proper error propagation, or route through the existing try_from_unified path which already handles this case correctly.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that rejects z_listunifiedreceivers calls with untrusted address parameters.

Impact

A single authenticated RPC request terminates the zebrad process. The attack is repeatable on restart (the same request triggers the same abort), allowing an attacker to keep the node down indefinitely until the request is filtered upstream. Operators using lightwalletd backends, Zaino indexers, or mining pool infrastructure that forward RPC calls to zebrad may be exposed if the forwarding path passes through z_listunifiedreceivers.

Credit

Reported by @robustfengbin via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections.

Summary

The read_getblocks and read_getheaders codec paths accepted block locator vectors up to approximately 65,535 entries (the generic TrustedPreallocate ceiling derived from MAX_PROTOCOL_MESSAGE_LEN), rather than the protocol-specification limit of 101 entries (matching zcashd's MAX_LOCATOR_SZ). Each entry in the locator vector triggers a per-hash chain lookup (HashMap::contains_key + RocksDB::contains_hash) in find_chain_intersection on a tokio blocking-pool thread.

A single maximally-sized getblocks message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups.

Details

The read_headers codec path already implements the correct pattern: it reads the CompactSize count, validates against MAX_HEADERS_PER_MESSAGE = 160 before deserialization, and rejects oversized messages. The read_getblocks and read_getheaders paths were missing this pre-deserialization count check and instead relied on the generic block::Hash::max_allocation() bound, which allows (MAX_PROTOCOL_MESSAGE_LEN - 1) / 32 = 65,535 hashes.

A legitimate block locator is logarithmic in chain length (approximately 30 hashes for the current ~3M-block Zcash chain). Zebra's own send-side cap is MAX_FIND_BLOCK_HASHES_RESULTS = 500.

The practical impact requires significant attacker bandwidth (approximately 2 MiB per request) and multiple Sybil peers to meaningfully degrade the blocking pool, which limits real-world exploitability.

Patches

Patched in Zebra 4.4.2. The fix caps block::Hash::max_allocation() at MAX_BLOCK_LOCATOR_LENGTH = 101, matching zcashd's MAX_LOCATOR_SZ. This causes the deserializer to reject oversized locators before any allocation or iteration occurs.

Workarounds

No specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.

Impact

Under sustained load from multiple Sybil peers, oversized locator vectors can occupy blocking-pool threads and degrade state-read performance. The effect is bounded by connection limits and requires significant attacker bandwidth.

Credit

Vulnerability identified by @dingledropper, who submitted the fix in PR #10570. Downstream CPU/blocking-pool impact analysis contributed by @ouicate.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

Summary

A composite denial-of-service vulnerability in Zebra's block discovery pipeline allows an unauthenticated remote attacker to permanently halt all new block discovery on a targeted node. The attack exploits three independent weaknesses in the gossip, syncer, and download subsystems — all exercisable from a single TCP connection — to create a monotonically growing block deficit that never self-heals.

Severity

Critical — This is a Denial of Service vulnerability that requires no authentication, no special privileges, and only a single peer connection. The halt is permanent: the node will never recover without operator intervention.

Affected Versions

All Zebra versions prior to 4.4.0.

Description

Zebra discovers new blocks through two complementary paths: a gossip path (peers announce blocks via inv messages, triggering individual block downloads) and a syncer path (Zebra periodically queries peers with FindBlocks/FindHeaders to discover chains of missing blocks). Both paths must function for normal operation.

The gossip path was vulnerable because there was no per-connection rate limit on inv messages. A single connection could send enough sequential inv messages with fake block hashes to fill the entire gossip download queue in under a millisecond. The FullQueue return value was silently ignored, so legitimate block announcements from honest peers were dropped with no warning.

The syncer backup path could be degraded by responding with empty inv to FindBlocks requests and with NotFound to block download requests. Both are valid protocol responses that carried zero misbehavior penalty. The attacker's connection was never banned and never disconnected, allowing the degradation to persist indefinitely.

Combining these two vectors, an attacker could suppress both block discovery paths simultaneously from a single connection, causing the node to fall permanently behind the chain tip.

Impact

Denial of Service

• Attack Vector: Network, unauthenticated. Requires only a single TCP peer connection.
• Effect: Permanent halt of block discovery. The targeted node falls behind the chain tip and never recovers without operator intervention.
• Scope: Any Zebra node reachable by the attacker over the peer-to-peer network.

Fixed Versions

This issue is fixed in Zebra 4.4.0.

The fix drops connections that send empty responses to FindBlocks and FindHeaders messages, preventing attackers from degrading the syncer path without consequence.

Mitigation

Users should upgrade to Zebra 4.4.0 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to protect against this attack.

Credits

Zebra the researcher who reported this issue through the coordinated disclosure process.

Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output

Summary

Zebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with SIGHASH_SINGLE and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but zcashd rejects, creating a consensus split between Zebra and zcashd nodes.

A previous fix (GHSA-cwfq-rfcr-8hmp) addressed a closely related case in the same area of the code, but did not cover this specific one.

Severity

Critical - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.

Note that the impact is currently alleviated by the fact that currently most miners run zcashd.

Affected Versions

Zebra 4.4.0.

Description

Verification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code is called from Zebra through a foreign function interface (FFI), with a Rust callback that computes the sighash for each input being verified.

ZIP-244 §S.2a marks two situations as consensus failure for V5 transparent signatures:

1. The signed hash type is not one of the six canonical values; and
2. The hash type is SIGHASH_SINGLE (alone or combined with ANYONECANPAY) and the input has no transparent output at the same index.

zcashd enforces both rules: its SignatureHash raises an exception, and CheckSig catches it and fails the script. A previous fix (GHSA-cwfq-rfcr-8hmp) added the first rule to Zebra's V5 sighash callback. The second rule, however, was not added — Zebra's callback forwarded the request to librustzcash's ZIP-244 implementation, which handles an out-of-range SIGHASH_SINGLE output index by hashing an empty output set rather than refusing to produce a digest. As a result, Zebra would compute a well-defined sighash for the missing-output case and accept any signature that verified against it.

An attacker could exploit this by:

• Constructing a V5 transaction with two or more transparent inputs and fewer transparent outputs;
• Signing an input whose index has no matching vout entry with SIGHASH_SINGLE (0x03) or SIGHASH_SINGLE|ANYONECANPAY (0x83), using the digest Zebra computes;
• Broadcasting the transaction, or a block containing it, to the network.

Zebra would verify the transaction's transparent script and accept the transaction (and any block containing it), while zcashd would reject both, splitting Zebra nodes from the rest of the network.

Impact

Consensus Failure

• Attack Vector: Network.
• Effect: Network partition/consensus split.
• Scope: Any affected Zebra node.

Fixed Versions

This issue is fixed in Zebra 4.4.1.

Mitigation

Users should upgrade to Zebra 4.4.1 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.

Credits

Zebra thanks @sangsoo-osec, @zmanian, and @fivelittleducks for finding and reporting the issue.

Zebra Transparent SIGHASH_SINGLE Corresponding-Output Handling Diverges From zcashd

Summary

For V5+ transparent spends, Zebra and zcashd disagree on the same consensus rule: SIGHASH_SINGLE must fail when the input index has no corresponding output. zcashd treats this as consensus-invalid under ZIP-244, while Zebra's transparent verification path computes a digest for the missing-output case instead of failing.

The result is a direct block-validity split. A malformed V5 transparent transaction can be accepted by Zebra, retained in Zebra's mempool, selected into Zebra getblocktemplate, mined into a block, and then rejected by zcashd.

Details

Validated code revisions used during analysis:

• zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
• Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Scope note:

• earlier triage material grouped pre-V5 and V5 behavior together;
• re-execution on the pinned revisions did not reproduce the claimed pre-V5 / V4 reject-side behavior;
• this advisory therefore covers the V5+ / ZIP-244 variant only.

zcashd side:

• Transparent scripts in blocks are checked through TransactionSignatureChecker::CheckSig() and SignatureHash(): zcash/src/script/interpreter.cpp.
• In the ZIP-244 branch, SignatureHash() explicitly throws when SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY is used with nIn >= txTo.vout.size(): zcash/src/script/interpreter.cpp.
• CheckSig() catches that exception and returns false, causing the transparent script to fail.

Zebra side:

• V5 transparent inputs route into the same FFI-based transparent script verifier used for block validation: zebra/zebra-consensus/src/transaction.rs.
• Zebra converts the decoded hash type and asks its Rust sighash engine for a digest without adding the corresponding-output pre-check that zcashd enforces first: zebra/zebra-script/src/lib.rs, zebra/zebra-chain/src/primitives/zcash_primitives.rs.
• Zebra forwards canonical SIGHASH_SINGLE into the Rust ZIP-244 implementation.
• In that implementation, when input.index() >= bundle.vout.len(), the code uses transparent_outputs_hash::<TxOut>(&[]) instead of erroring: zcash_primitives/src/transaction/sighash_v5.rs, zcash_primitives/src/transaction/sighash_v5.rs.

Why this is exploitable:

• the malformed transaction only needs fewer transparent outputs than inputs;
• the attacker signs the digest that Zebra computes for the missing-output case;
• Zebra then sees a valid transparent signature, while zcashd never reaches the same digest because it fails first.

Ordinary path viability:

• zcashd ordinary mempool admission is not the practical trigger path, because the same ZIP-244 SignatureHash() checks fail there first: zcash/src/main.cpp, zcash/src/script/interpreter.cpp.
• Zebra ordinary mempool admission is viable because Zebra uses the same transparent verifier for mempool and block validation and does not have a separate "one output per input" standardness rule here: zebra/zebra-consensus/src/transaction.rs, zebra/zebrad/src/components/mempool/storage.rs.
• Zebra is a block-template producer, so the realistic stock path is Zebra mempool -> Zebra getblocktemplate -> external miner: zebra/zebra-rpc/src/methods/types/get_block_template/zip317.rs.

PoC

Validated commits:

• zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
• Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Manual reproduction steps:

1. Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.
2. Sign input 0 normally.
3. Sign input 1 with canonical SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY.
4. Use the digest returned by Zebra's ZIP-244 path, where the missing output contributes transparent_outputs_hash([]).
5. Submit the transaction to Zebra and to zcashd.
6. Observe:
   • Zebra accepts it into the mempool;
   • Zebra selects it into getblocktemplate;
   • Zebra can mine and accept a block containing it;
   • zcashd rejects it in the ordinary mempool path.

Impact

This is a direct V5+ transparent consensus split.

Who can trigger it:

• an ordinary transaction author can craft the malformed V5 transparent transaction;
• the accept-side stock path is Zebra's mempool and block-template path;
• an external miner still has to include the transaction in a block for the split to materialize.

Who is impacted:

• Zebra can accept and template a transaction / block that zcashd rejects;
• this makes the issue both a consensus-divergence problem and a practical Zebra block-template safety problem.

CVE-2026-44497: Consensus Divergence in Transparent Sighash Hash-Type Handling due to Stale Buffer

Summary

The fix for https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj introduced a separate issue due to insuficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes.

Severity

Critical - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.

Note that the impact is currently alleviated by the fact that currently most miners run zcashd.

Affected Versions

Zebra 4.3.1.

Description

Verification of transparent transactions inherits the Bitcoin Script verification code in C++, called from Zebra through a foreign function interface (FFI) with a Rust callback that computes the sighash. The fix for https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj added the missing V5 hash-type consensus check on the Rust side, returning None for undefined hash types. However, the FFI bridge only writes to the C++ sighash buffer when the callback returns Some, and the C++ checker reads that buffer unconditionally, so the failure signal is lost.

An attacker could exploit this by:

• Constructing a transparent output spent by a script that runs a valid OP_CHECKSIGVERIFY immediately before an OP_CHECKSIG with an undefined hash type.
• The first opcode primes the C++ sighash buffer with a valid digest; the second causes Zebra's callback to return None while the C++ checker verifies the invalid signature against the stale digest.
• Zebra accepts the spend, zcashd rejects it, creating a consensus split in the network.

Impact

Consensus Failure

• Attack Vector: Network.
• Effect: Network partition/consensus split.
• Scope: Any affected Zebra node, and any miner or template pipeline that relies on Zebra's validation result.

Fixed Versions

This issue is fixed in 4.4.0.

The fixes uses a workaround where the input buffer is filled with random bytes on validation failure, which makes signature validation fail (as expected) with overwhelming probability. This avoids a breaking release of the zcash_script crate. A future release will propagate the error correctly for a direct fix.

Mitigation

Users should upgrade to 4.4.0 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.

Credits

Zebra thanks @sangsoo-osec for finding and reporting the issue.

CVE-2026-44500: Allocation Amplification in Inbound Network Deserializers

Summary

Several inbound deserialization paths in Zebra allocated buffers sized against generic transport or block-size ceilings before the tighter protocol or consensus limits were enforced. An unauthenticated or post-handshake peer could therefore force the node to preallocate and parse for orders of magnitude more data than the protocol intended, across headers messages, equihash solutions in block headers, Sapling spend vectors in V5/V4 transactions, and coinbase script bytes in blocks.

Severity

Moderate - This is a Denial-of-Service Vulnerability that could allow a malicious peer to amplify per-message memory and parse cost on Zebra nodes, with effects amplified by multi-peer fan-in.

Each individual case is bounded by the 2 MiB transport ceiling or the block-size cap, so no single message causes unbounded allocation, but the cumulative gap between intended and actual limits is significant.

Affected Versions

All Zebra versions prior to 4.4.0.

Description

Zebra's network codec uses TrustedPreallocate and generic Vec deserialization to bound inbound message parsing. In several places the bound used at the deserializer was the generic transport or block-size ceiling rather than the tighter protocol or consensus rule that applies to the field, so allocation happened first and the real limit was only enforced afterwards. Four such cases were identified:

• headers message receive cap. read_headers() deserialized the CountedHeader vector via the generic TrustedPreallocate path, which allowed up to ~1,409 entries per message. The protocol ceiling MAX_FIND_BLOCK_HEADERS_RESULTS = 160 was only used on the send side, giving an ~8.8x preallocation gap on receive. Reachable before the version handshake completes since the codec is installed on raw bytes.
• Equihash solution length. Solution::zcash_deserialize decoded the solution as a generic Vec<u8> and only checked the exact consensus size (1344 bytes mainnet/testnet, 36 bytes regtest) afterwards in Solution::from_bytes. A single fixed-size header field could be inflated to nearly the full block-size ceiling before rejection.
• Sapling spend vectors in coinbase transactions. V5 spend_prefixes and V4 shielded_spends were allocated generically with block-size-derived ceilings (~5,681 / ~5,208 entries) before the consensus rule that coinbase transactions have zero Sapling spends was enforced in the verifier.
• Coinbase script bytes. Input::zcash_deserialize() read the coinbase script as a generic Vec<u8> up to the message-size cap before enforcing the consensus rule that coinbase scripts are between 2 and 100 bytes.

An attacker could exploit this by:

• Opening an inbound TCP connection (and, for the latter three cases, completing the version handshake).
• Sending one of: a headers message with a CompactSize count up to ~1,409, a block whose header carries an inflated equihash CompactSize, a tx declaring a coinbase input with a large nSpendsSapling, or a block with a coinbase input whose script length is near the message-size ceiling.
• The deserializer allocates against the loose ceiling, parses, and only then rejects.

Impact

Denial of Service

• Attack Vector: Network.
• Effect: Amplified per-message allocation and parse cost on inbound peer messages, stackable across concurrent connections. The concrete effect will be influenced by how much memory Zebra has available.
• Scope: Any affected Zebra node.

Fixed Versions

This issue is fixed in Zebra 4.4.0.

Mitigation

Users should upgrade to Zebra 4.4.0 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to remove the amplified allocation surface on inbound peer messages.

Credits

Zebra thanks @Zk-nd3r for finding and reporting the issues.

Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAX_BLOCK_SIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not.

Two distinct undercounts:

A: Coinbase Hidden Legacy Sigops

zcashd's GetLegacySigOpCount() includes the coinbase input's scriptSig. Zebra's Sigops impl skipped the coinbase input entirely, so up to ~98 sigops (the 100-byte coinbase script length cap, less the height prefix) could be hidden inside the coinbase scriptSig without being charged against the block limit.

B: Aggregate P2SH Sigops.

zcashd's GetP2SHSigOpCount() parses each P2SH input's redeem script with accurate=true and sums those sigops into the block-wide total via ConnectBlock. The check is per-block, not per-transaction, and the limit applies regardless of who mines the offending block — a miner just needs to include enough P2SH-spending transactions whose redeem scripts together exceed 20000 sigops. Zebra computed P2SH sigops only on the mempool-acceptance path (used for ZIP-317 weighting) and never accumulated them during block validation. A block whose aggregate redeem-script sigops exceed 20000 (e.g. 1334 P2SH spends × 15 sigops = 20010) would be accepted by Zebra and rejected by zcashd.

Patches

Fixed in this release: https://github.com/ZcashFoundation/zebra/releases/tag/v4.4.0.

Workarounds

None. Operators relying on Zebra for consensus should upgrade.

Resources

• MAX_BLOCK_SIGOPS constant inherited from Bitcoin via the Zcash protocol spec's §7.6 catch-all "Other rules inherited from Bitcoin", tracked for explicit documentation in zcash/zips#568.
• zcashd GetLegacySigOpCount: https://github.com/zcash/zcash/blob/v6.11.0/src/main.cpp#L826-L836
• zcashd GetP2SHSigOpCount: https://github.com/zcash/zcash/blob/v6.11.0/src/main.cpp#L840-L852
• zcashd ConnectBlock aggregates per-tx sigops and compares against MAX_BLOCK_SIGOPS.

Summary

A soundness vulnerability in the variable-base scalar multiplication gadget of halo2_gadgets allowed a malicious prover to produce a valid proof for an Orchard Action with an under-constrained base point. Because this gadget enforces the diversified-address-integrity condition of the Orchard Action statement, the flaw let a prover satisfy that condition for an arbitrary (pkd, gd, ivk) triple, effectively bypassing the check that binds an Action to the correct incoming viewing key — and therefore to the correct nullifier (nf) and spend validating key (ak) — of the note being spent.

The main practical consequence is that an adversary could have performed a double-spend within the Orchard pool, resulting in a balance violation: the same note could be spent multiple times, each time revealing a distinct, valid-looking nullifier. The total ZEC supply was protected by Zcash's turnstile mechanism, which bounds value flowing out of any pool, so unbounded inflation of the overall supply was not possible; the exposure was inflation of value within the Orchard pool up to the turnstile-enforced limit.

Exploiting the vulnerability via a double-spend is undetectable on-chain. Exploitation only requires setting private circuit inputs to chosen values, and nullifiers produced by a double-spend are indistinguishable from honest nullifiers, so the zero-knowledge property hides any signature of the attack.

Alternatively, an adversary could (before the fix) have stolen funds by forging a spend authorization for an existing note. To do so they would have to know the note plaintext, which in practice they might obtain by knowing the corresponding incoming viewing key. For example, this could be used to bypass the protection provided by holding spending keys on a hardware wallet, if the linked software wallet were compromised. This form of exploitation cannot be detected via the turnstile (which might be a motivation to exploit the vulnerability in this way rather than via balance violation). It can be detected by the legitimate holder of stolen funds being unable to spend them, or by seeing the note's nullifier on-chain — but this cannot necessarily be distinguished from compromise of the spending key by other means.

The vulnerability has existed since the Orchard pool was introduced in the NU5 network upgrade (activated May 31, 2022). There is no evidence it was exploited prior to remediation.

Note that use of the vulnerability, either for balance violation or for theft of funds, would need to have occurred before it was remediated. Theft would be in principle detectable from that point (since the real nullifier would appear on-chain). Balance violation would not be detectable at the point of exploitation.

Root cause

The defect is in the double-and-add implementation of variable-base scalar multiplication in halo2_gadgets/src/ecc/chip/mul/incomplete.rs. For performance, the algorithm uses incomplete point-addition formulas in its intermediate stage. (Incomplete addition is safe here in principle: the first and last stages use complete addition, and reaching a degenerate case would require breaking discrete log.)

The base point is fed into the incomplete-addition stage via assign_advice(), which assigns a witness value (a private circuit input) without introducing a constraint that ties that value to the actual base the algorithm is supposed to operate on:

region.assign_advice(|| "x_p", self.double_and_add.x_p, row + offset, || x_p)?;
region.assign_advice(|| "y_p", self.y_p, row + offset, || y_p)?;

(halo2_gadgets/src/ecc/chip/mul/incomplete.rs, around L309–L310 at commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea.)

The existing q_mul_2 constraint forces the base values used across the incomplete-addition loop to be equal to one another, but nothing forces them to equal the actual base. A malicious prover therefore has complete freedom to choose the base used by the loop. Given target pkd, gd, and ivk, the prover can solve for the base value that makes the computed [ivk] gd equal the desired pkd, satisfying the diversified-address-integrity equation pkdold = [ivk] gdold for inputs that an honest prover could never satisfy.

Why this enables a double-spend

The Orchard Action statement constrains the nullifier of the spent note to be derived from the correct nullifier key nk, which in turn is bound to the correct incoming viewing key ivk, via ivk = Commitivkrivk(Extractℙ(akℙ), nk). The diversified-address-integrity check pkd = [ivk] gd is what normally guarantees the prover used the correct ivk —and hence the correct nk— for the note. With that check bypassable:

1. The prover picks a fresh, incorrect nk for the note being spent. Since nk feeds the nullifier computation, a wrong nk yields a different nullifier for the same note.
2. Other circuit constraints still force the prover to derive ivk honestly from that wrong nk, producing a wrong ivk for the note — which would normally be caught by the integrity check.
3. The prover uses the under-constrained base to satisfy pkd = [ivk] gd anyway, defeating the check.
4. Each distinct wrong nk produces a distinct valid nullifier, allowing the note to be spent repeatedly.

Why this enables theft

The spend validating key, akℙ (essentially equivalent to ak), is also constrained via ivk = Commitivkrivk(Extractℙ(akℙ), nk). As above, the diversified-address-integrity check is what normally guarantees the prover used the correct ivk —and hence the correct ak— for the note. With that check bypassable:

1. The prover picks an ak for which they know the private key, ask.
2. They construct a transaction that spends the victim's notes, and sign it using that ask.

Impact

• Integrity: High. A malicious prover could spend Orchard notes multiple times, inflating value within the Orchard pool. This is bounded only by the turnstile limit on the pool. Alternatively, the prover could authorize spending other users' notes without having the spending key.
• Confidentiality: None. The zero-knowledge property is intact; no private data is disclosed. This is also why the attack leaves no observable on-chain signature.
• Availability: Not directly affected by the bug. (The coordinated response temporarily disabled Orchard actions as a mitigation; that was an operational choice, not an effect of the vulnerability.) On the other hand, either theft of funds, or inability to spend funds due to a future turnstile violation could be considered an availability consequence.

Affected versions

• halo2_gadgets < 0.5.0
• orchard < 0.14.0
• zcash_primitives < 0.28.0
• zcashd < 6.20.0
• zebrad < 5.0.0

Patches

The circuit-level fix replaces the first-iteration assign_advice() calls for the base point with copy_advice(), introducing a copy constraint that requires the first base value to equal the correct base. Combined with the existing q_mul_2 equality constraint across the loop, this transitively constrains every base value in the incomplete-addition stage to the correct base, closing the freedom the attacker relied on.

Because remediating a zero-knowledge circuit changes the pinned verifying key, the network-level fix required a hard fork (NU6.2). NU6.2 re-enables Orchard with the corrected circuit and routes Orchard proofs to a per-circuit verifying key (InsecurePreNu6_2 / FixedPostNu6_2).

• halo2_gadgets 0.5.0
• orchard 0.14.0
• zcash_primitives 0.28.0
• zebrad 5.0.0 (NU6.2); 4.5.3 ships the interim soft-fork mitigation
• zcashd 6.20.0 (NU6.2)

Workarounds / mitigations

There is no client-side workaround for the underlying soundness flaw short of the circuit fix. The deployed interim mitigation (Zebra 4.5.3 / equivalent) was a soft fork that rejected all Orchard-containing transactions and blocks, fully neutralizing exploitation until NU6.2 activated.

Downstream projects that depend on the affected crates should:

• Upgrade halo2_gadgets, orchard, and zcash_primitives to the patched versions above.
• Audit any other use of assign_advice() (and similar non-constraining assignment APIs) where the intended invariant is that a witnessed value equals a known/fixed value; such sites should use copy_advice() (or otherwise enforce an explicit constraint).

Indicators / detection

Exploitation produces no distinguishing on-chain signature. The turnstile mechanism, which tracks total ZEC across all value pools, provides a ground-truth supply check and confirmed the total supply remained intact. Heuristic analysis of Orchard transaction arity (e.g. patterns of duplicate-then-consolidate behavior) is possible but inconclusive against normal shielded-activity variance.

Timeline (MDT)

| Date / Time | Event | |---|---| | 2022-05-31 11:50 | Vulnerable NU5 upgrade activates (bug introduced) | | 2026-05-29 (evening) | Vulnerability discovered during a protocol audit | | 2026-05-29 23:53 | Responsibly disclosed to ZODL core engineers | | 2026-05-30 06:30 | Disclosure acknowledged by ZODL | | 2026-06-01 (~21:30) | Emergency soft-fork mitigation activated (block 3,363,426) | | 2026-06-03 00:05 EDT | NU6.2 hard fork activates, Orchard re-enabled with fix (block 3,364,600) |

Credits

Discovered and responsibly disclosed by Taylor Hornby, independent security researcher, during a protocol audit conducted on behalf of Shielded Labs. Analysis and remediation was led by ZODL engineers Jack Grigg, Daira-Emma Hopwood, and Kris Nuttycombe, with Zebra patch work by Arya Solhi (Zcash Foundation).

Resources

• Zcash Foundation: Zebra 4.5.3 and 5.0.0: Emergency Soft Fork and NU6.2 Activation — https://zfnd.org/zebra-4-5-3-and-5-0-0-emergency-soft-fork-and-nu6-2-activation/
• Affected source (pre-fix): halo2_gadgets/src/ecc/chip/mul/incomplete.rs @ commit 32a87582dfb0ad9364ef3ffe71751ceab2a502ea, L309–L310

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node listens on the default [::] address on a Linux host (the standard deployment configuration — net.ipv6.bindv6only=0 is the default on all common Linux distributions).
3. Your node is synced near the chain tip (the expected production state for any node participating in the network).

Summary

An address normalization mismatch between the handshake path and the mempool misbehavior path causes a deterministic assertion panic when a peer connects via IPv4 to a dual-stack IPv6 listener and then triggers a mempool misbehavior penalty.

The handshake path canonicalizes IPv4-mapped IPv6 addresses to plain IPv4 when storing the peer in the address book via MetaAddr::new_connected. The mempool misbehavior path forwards the raw transient socket address (IPv4-mapped IPv6 form) when sending MetaAddrChange::UpdateMisbehavior to the address book. The address book looks up the canonical IPv4 entry but then asserts that the previous entry's address matches the change's address. The mismatch between the canonical IPv4 address and the raw IPv4-mapped IPv6 address triggers the assertion, and panic = "abort" terminates the process.

Details

On Linux with net.ipv6.bindv6only=0, an IPv4 connection accepted by a [::] listener is represented internally as an IPv4-mapped IPv6 socket address (e.g., ::ffff:127.0.0.1:8233). Zebra's canonical_peer_addr helper converts these to plain IPv4 (e.g., 127.0.0.1:8233).

The handshake path uses MetaAddr::new_connected, which canonicalizes the address before storing in the address book. However, inbound inventory registration uses connected_addr.get_transient_addr(), preserving the raw IPv4-mapped form. When the mempool later downloads an invalid transaction from this peer and generates a misbehavior penalty, the raw transient address is forwarded through the misbehavior channel to MetaAddrChange::UpdateMisbehavior, which does not canonicalize.

After the 30-second misbehavior batch flush, AddressBook::update retrieves the canonical IPv4 entry but MetaAddrChange::apply_to_meta_addr asserts that previous.addr == self.addr(), which fails because one is IPv4 and the other is IPv4-mapped IPv6.

The attacker needs only to complete a P2P handshake over IPv4 to a dual-stack listener and advertise an invalid mempool transaction (such as a coinbase transaction). The assertion fires after the 30-second misbehavior batch flush.

Patches

Patched in Zebra 4.5.0. The fix canonicalizes the address in the misbehavior update path via a new MetaAddr::new_misbehavior constructor that applies canonical_peer_addr before creating the UpdateMisbehavior change.

Workarounds

Configuring listen_addr to an IPv4-only address (e.g., 0.0.0.0:8233) avoids the IPv4-mapped IPv6 representation and prevents this specific assertion. Alternatively, setting net.ipv6.bindv6only=1 on Linux prevents dual-stack acceptance.

Impact

A remote unauthenticated peer can deterministically crash any synced Zebra node running the default Linux dual-stack configuration with a single invalid mempool transaction advertisement, followed by a 30-second wait. The attack requires no mining capability, no RPC access, no funds, and no special privileges. The crash can be repeated after each restart, causing persistent downtime. Linux dual-stack sockets and mempool activation are the default production state, not special preconditions.

Credit

Reported by @Haxatron.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

Summary

The mempool download pipeline's cancel_handles map retains entries for transactions whose verification times out at the outer RATE_LIMIT_DELAY (73-second) boundary. The tokio::time::error::Elapsed error carries no payload, so the transaction ID is unrecoverable and the corresponding cancel_handles entry (including the full Gossip::Tx(UnminedTx), up to ~2 MB) is never removed. Entries accumulate monotonically with no upper bound or garbage collection, leading to eventual out-of-memory process termination.

Details

Downloads::poll_next() at zebrad/src/components/mempool/downloads.rs:215-228 handles three terminal states for a verification task:

• Ok(Ok(...)): success. Calls cancel_handles.remove(&tx.transaction.id). Correct.
• Ok(Err(...)): verification error. Calls cancel_handles.remove(&hash). Correct.
• Err(elapsed): outer timeout. Returns Err(elapsed) without removing anything. Bug.

tokio::time::error::Elapsed has no payload, so the timed-out transaction's UnminedTxId is unrecoverable from the error. The consumer at zebrad/src/components/mempool.rs:663-672 explicitly acknowledges this gap with a TODO comment.

The only cleanup paths for cancel_handles are cancel(mined_ids) (removes entries matching mined transaction IDs; attacker transactions are never mined) and cancel_all() (clears everything on shutdown or chain reset). No periodic GC, no time-based eviction, and no count cap exists.

For direct tx pushes (Gossip::Tx), the retained entry holds the full deserialized transaction, which can be up to ~9 MB in memory for a transaction near the transparent-output extreme. Per-connection leak rate at worst case: ~685 KB/s (~2.4 GB/hour).

Patches

The fix preserves the UnminedTxId through the timeout error path: wrap the timeout future so the spawned task's outer error carries the txid (e.g., Err((txid, elapsed))). In Downloads::poll_next(), on the timeout arm, call cancel_handles.remove(&txid).

Workarounds

There is no configuration-level workaround. Restarting the node clears the accumulated entries. Operators running in memory-constrained environments (containers with cgroup limits) may see the process killed by the OOM killer before natural recovery.

Impact

Gradual, unbounded memory exhaustion of a Zebra node from unauthenticated P2P traffic. The leak is monotonic (entries are never freed under normal operation) but slow (~685 KB/s per connection worst case). An attacker must sustain traffic for hours to exhaust typical server memory. The node continues operating normally until memory pressure becomes critical, at which point the OS OOM killer terminates the process or the node degrades due to swap pressure. No consensus impact, no fund loss, no on-disk corruption.

Credit

Reported by @AnticsDecoded via a private GitHub Security Advisory submission. Working E2E reproduction on a live regtest node with staged parent/child transaction dependencies.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node participates in a network where chain forks occur (mainnet, testnet, or any network with multiple miners).

All default configurations are affected. The corruption persists across restarts because it is written to RocksDB.

Summary

When pop_tip removes the tip block during a chain fork, stale Sapling and Orchard note commitment subtree root data is retained in the in-memory non-finalized state. When the chain subsequently finalizes, this stale data is written to the persistent RocksDB state. The corrupted subtree root history affects z_getsubtreesbyindex (used by lightwalletd for wallet synchronization) and could affect future chain verification that depends on correct subtree roots.

Details

The non-finalized state provides two methods for removing blocks: pop_root (removes the oldest block during finalization) and pop_tip (removes the newest block during a fork revert). pop_root correctly cleans up note commitment subtree contributions. pop_tip does not: it removes the block but retains the block's subtree root contributions in the in-memory state.

When a chain fork occurs and pop_tip reverts the old tip, the winning fork's chain is extended. When that chain is later finalized, the stale subtree data from the reverted blocks is included in the RocksDB write batch and persisted to disk.

The pop_root/pop_tip asymmetry is specific to subtree root handling. Other state managed by pop_tip (nullifiers, UTXOs, anchors, block hashes) uses different cleanup patterns that are not affected.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

The fix adds subtree root cleanup to pop_tip matching the pattern already used by pop_root.

Workarounds

There is no configuration-level workaround. Chain forks are natural events on any Proof-of-Work network. Operators can mitigate the downstream impact by periodically verifying subtree root consistency using z_getsubtreesbyindex against a known-good reference.

Impact

Persistent corruption of Sapling and Orchard subtree root history in the RocksDB state database. The corruption survives node restarts. Downstream consumers that rely on z_getsubtreesbyindex for wallet synchronization (primarily lightwalletd and light wallets) receive incorrect subtree roots. This does not directly affect consensus validation of new blocks but can cause wallet synchronization failures or incorrect wallet state. Recovery requires rebuilding the state database from scratch.

Credit

Reported by @dingledropper via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node processes blocks past the checkpoint height (non-finalized state is active).
3. The network has NU5 or later activated.

All default configurations are affected.

Summary

Chain::push in the non-finalized state updates the transaction-location index (tx_loc_by_hash) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the assert_eq!(prior_pair, None, "transactions must be unique within a single chain") fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's panic = "abort" release profile, this terminates the entire node process.

The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within Chain::push causes the process to abort.

Details

In zebra-state/src/service/non_finalized_state/chain.rs:1608-1628, the block push sequence is:

1. Insert transaction hash into tx_loc_by_hash with assert_eq! on uniqueness
2. Update transparent outputs and inputs
3. Update shielded data (JoinSplit, Sapling, Orchard) — including nullifier uniqueness checks

The shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the assert_eq! at step 1 fires first because the transaction hash is already in tx_loc_by_hash from the parent block on the same chain.

The block transaction verifier does not run the best-chain nullifier query for block transactions — that check is gated on mempool transactions only (zebra-consensus/src/transaction.rs:521-526). Initial contextual validation checks nullifiers in finalized state only (zebra-state/src/service/check.rs:407-415), but the parent transaction is still in non-finalized state.

There are two attack models:

Model A (two attacker blocks): The attacker mines two consecutive valid-work blocks: parent B1 containing a shielded transaction T, and child B2 repeating T. This requires controlling both blocks consecutively.

Model B (one attacker block after an honest block): The attacker broadcasts a shielded transaction T into the mempool. When any honest miner includes T in their block B1, the attacker only needs to mine the next child block B2 containing the same T. This requires controlling only one block immediately after an honest block that included the attacker's transaction. The attacker can broadcast a suitable shielded transaction every block until one is included by an honest miner, then attempt to mine the follow-up.

Both models require the child block to repeat the shielded-only V5 transaction while the parent is still in non-finalized state.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

Replace the assert_eq! with an Entry-based check that returns ValidateContextError::DuplicateTransaction instead of panicking:

match self.tx_loc_by_hash.entry(transaction_hash) {
    Entry::Vacant(entry) => {
        entry.insert(transaction_location);
    }
    Entry::Occupied(_) => {
        return Err(ValidateContextError::DuplicateTransaction { transaction_hash });
    }
}

Workarounds

There is no configuration-level workaround. The assert is in the non-finalized state push path, which is exercised by all block processing past the checkpoint height.

Impact

A malicious block producer can crash targeted Zebra nodes. There are two attack models:

In the first model, the attacker mines two consecutive valid-work blocks where the child repeats a shielded transaction from the parent. At 10% hashrate, the attacker has approximately 11.5 opportunities per day; at 5%, approximately 2.9 per day; at 1%, approximately one every 8.7 days.

In the second model, the attacker broadcasts a shielded transaction into the mempool and waits for any honest miner to include it. The attacker then only needs to mine the next block containing the same transaction. This is cheaper because the attacker does not need to mine the parent block. At 10% hashrate, the attacker has approximately 14.4 single-block opportunities per day; at 5%, approximately 7.2 per day; at 1%, approximately 1.4 per day.

The crash is a process abort (not recoverable within the process). The node must be restarted. Repeated attacks can keep a node down for extended periods. This is a liveness issue, not a consensus divergence: zcashd cleanly rejects the invalid child block while Zebra aborts.

Credit

Reported by @haxatron via email disclosure.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node processes blocks on any Zcash network.

Summary

The finalized transparent address balance writer processes all newly-created outputs (credits) before processing spent outputs (debits) within the same block. A consensus-valid block containing a long chain of same-address transparent self-spends can cause the intermediate per-address balance during the credit pass to exceed MAX_MONEY, triggering a panic in the finalized state writer.

Because the triggering block is consensus-valid (zcashd accepts it), the panic recurs on restart when the node re-encounters the same block. This creates a persistent chain halt that can only be resolved by a software patch.

Details

The finalized state writer at zebra-state/src/service/finalized_state/zebra_db/transparent.rs iterates all transaction outputs in a block and credits them to per-address balances before iterating inputs and debiting spent outputs. When a block contains many transparent self-spends to the same address, the intermediate credit-only balance can exceed the MAX_MONEY supply cap even though the final net balance (credits minus debits) is valid.

The code panics on the intermediate overflow via .expect() on the balance addition. Under Zebra's panic = "abort" release profile, this terminates the process. On restart, the node re-downloads and re-processes the same consensus-valid block, triggering the same panic.

An attacker with approximately 1,100–2,100 ZEC and mining capability can construct a block that permanently halts all Zebra nodes. The attacker recovers their capital (the self-spends return funds to the same address), so the net cost is the mining effort only.

Patches

Patched in Zebra 4.4.2. The fix processes credits and debits together per transaction rather than all credits then all debits, matching zcashd's approach.

Workarounds

No workaround is available. Upgrade to Zebra 4.4.2.

Impact

A single consensus-valid mined block can permanently halt all Zebra nodes on the network. The halt persists across restarts. Recovery requires deploying a patched version. Downstream consumers (light wallets, exchanges, mining infrastructure) lose service for the duration of the halt.

Credit

Reported by @sangsoo-osec.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections and is syncing or catching up to the chain tip.

Summary

A malicious peer can answer Zebra's outbound getblocks/FindBlocks request with a small two-hash inventory, then serve a syntactically valid block whose coinbase height is far above the victim's local tip. The AboveLookaheadHeightLimit error in the sync download pipeline triggers a global sync restart rather than being scoped to the offending peer. The peer is never scored or disconnected because the error type does not carry the advertiser address.

On mainnet, each successful cycle imposes a 67-second sync restart delay. All in-flight downloads from honest peers are cancelled on each restart.

Details

The bug is the interaction of three layers:

1. The syncer promotes unvalidated FindBlocks peer responses into concrete download schedules without checking that the advertised hashes are plausible chain extensions.

2. When a downloaded block's coinbase height exceeds tip + VERIFICATION_PIPELINE_DROP_LIMIT, the sync downloader returns BlockDownloadVerifyError::AboveLookaheadHeightLimit. This error variant carries only the block height and hash, not the advertiser peer address.

3. The sync error handler in handle_block_response only sends misbehaviour scores for BlockDownloadVerifyError::Invalid errors that carry an advertiser_addr and have a nonzero misbehavior_score(). AboveLookaheadHeightLimit falls through to the default restart-worthy path, cancelling all in-flight downloads and waiting 67 seconds before restarting sync.

The attacker needs only an unauthenticated P2P connection (post-handshake), a tiny payload (one two-hash inv message plus one small block per cycle), and no mining capability, funds, or valid chain data. The peer is never penalised, so the attack is repeatable indefinitely.

Additionally, several other pre-consensus sync-layer errors had zero misbehaviour scores even when peer-attributed. Contextual validation failures (InvalidDifficultyThreshold, TimeTooEarly, TimeTooLate, NonSequentialBlock) and locktime failures from block-serving peers all scored zero, allowing repeated abuse without penalty.

Patches

Patched in Zebra 4.4.2. The fix:

• Carries advertiser_addr through AboveLookaheadHeightLimit and InvalidHeight error variants.
• Makes above-lookahead and invalid-height failures peer-local (the block is dropped and the peer is banned with score 100) rather than triggering a global sync restart.
• Expands misbehavior_score() across BlockError, VerifyBlockError, and CommitBlockError to cover contextual validation failures that previously scored zero.

Workarounds

No configuration-level workaround is available. The attack is mitigated by having a diverse honest peer set, but cannot be prevented while the vulnerable code is running.

Impact

A single unauthenticated peer can repeatedly stall a syncing Zebra node by forcing 67-second global sync restart cycles. All unrelated in-flight downloads are cancelled on each restart. The node does not crash and no state is corrupted, but sync progress is significantly degraded for the duration of the attack.

Credit

Reported by @ipwning.

Am I affected

You are affected if:

1. You run any version of zebrad up to and including v4.4.1.
2. Your node validates blocks on mainnet, testnet, or any network where both Zebra and zcashd nodes participate.

All default configurations are affected. No feature flags, non-default settings, or special build options are required.

Summary

Zebra's P2SH sigop counter uses a pure-Rust code path that short-circuits on disabled opcodes (such as OP_CODESEPARATOR), returning a partial count of zero for any sigops following the disabled opcode. The reference implementation (zcashd) correctly counts through disabled opcodes in its static sigop analysis. This produces a consensus divergence: Zebra accepts blocks that zcashd rejects when the block-wide MAX_BLOCK_SIGOPS = 20,000 threshold is crossed on one side but not the other.

An attacker can exploit this without mining capability. Broadcasting transactions that spend P2SH outputs with malicious redeem scripts is sufficient; any Zebra miner who includes those transactions in a block triggers a chain split between Zebra and zcashd validators.

Details

The P2SH sigop counter at zebra-script/src/lib.rs:399 calls script::Code(redeemed_bytes).sig_op_count(true), which is a pure-Rust path through zcash_script-0.4.4. The legacy (non-P2SH) sigop counter at lib.rs:282-289 correctly uses the C++ FFI via interpreter.legacy_sigop_count_script(). Only the P2SH path bypasses the FFI.

The Rust parser in zcash_script-0.4.4/src/opcode/mod.rs:1247-1260 treats 16 disabled opcodes (0x7e through 0xab, including OP_CAT, OP_SUBSTR, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT, OP_RSHIFT, and OP_CODESEPARATOR) as Err(Error::Disabled(...)). The sig_op_count function at iter.rs:104-115 uses try_fold, which terminates on the first Err and returns the partial sum accumulated so far.

zcashd's GetOp2 (script.h:514-562) returns true for all non-push opcodes including the disabled range. Its GetSigOpCount(true) (script.cpp:152-174) continues counting through disabled opcodes. zcashd rejects disabled opcodes at execution time in the interpreter, not during static sigop analysis.

A redeem script of [0xab, OP_CHECKMULTISIG x 50] produces: Zebra = 0 sigops, zcashd = 1,000 sigops. Across 21 inputs in a block, Zebra computes 0 while zcashd computes 21,000, crossing the MAX_BLOCK_SIGOPS = 20,000 threshold on one side only.

Patches

Patched in Zebra 4.4.2. The fix routes the P2SH sigop counter through the same C++ FFI already used by the legacy sigop counter.

Workarounds

There is no configuration-level workaround. All Zebra nodes validating blocks on a network shared with zcashd are affected. Upgrade as soon as the patched version is available.

Impact

A chain split between Zebra and zcashd validators. The attacker broadcasts spending transactions referencing P2SH outputs whose redeem scripts contain a disabled opcode followed by OP_CHECKSIG or OP_CHECKMULTISIG opcodes. When a Zebra miner (estimated ~30% of current network hashrate) includes these transactions in a block, Zebra validators accept the block while zcashd validators reject it with bad-blk-sigops. The two halves of the network diverge and every subsequent block extending the Zebra-side tip inherits the divergence.

The attacker does not need mining capability, RPC access, or any special privileges. The cost is the transaction fees for the funding and spending transactions.

Credit

Reported by @samsulselfut via a private GitHub Security Advisory submission.

Description

Am I affected

You are affected if:

1. You run any version of zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node processes blocks past the checkpoint height (non-finalized state is active).

All default configurations are affected.

Summary

Zebra records a block hash in non_finalized_block_write_sent_hashes when the block is sent to the write task, before contextual validation completes. If validation fails, the hash is not removed. A remote unauthenticated peer can deliver a poisoned block body that shares a header hash with a later valid canonical block. The poisoned body is rejected, but the hash remains cached. When the valid canonical block arrives, Zebra treats it as a duplicate and rejects it. The node cannot advance past that height until restart or a reorg event.

Details

ZIP-244 defines txid_v5 without binding transparent input scriptSig, which lives in auth_digest and is committed to by hashBlockCommitments in the block header. Because merkle_root is computed over txids (not auth digests), and the block hash is computed over the header, an attacker can construct two blocks with identical header hashes but different transaction bodies by mutating the coinbase scriptSig.

The attack flow over P2P:

1. Attacker observes a new block header (from any peer).
2. Attacker constructs a poisoned body by flipping a byte of the coinbase scriptSig extra-data section. The block hash is unchanged.
3. Attacker advertises the block hash via inv to the target node.
4. Target requests the block via getdata; attacker serves the poisoned body.
5. Zebra adds the hash to non_finalized_block_write_sent_hashes before validation.
6. The write task rejects the body at block_commitment_is_valid_for_chain_history (auth_data_root mismatch).
7. The hash is not removed from non_finalized_block_write_sent_hashes.
8. When the valid canonical block arrives (from honest peers or RPC), queue_and_commit_to_non_finalized_state sees the hash in the cache and returns KnownBlock::WriteChannel duplicate.
9. The node is stuck at height N-1.

A secondary variant exists where chain pruning (via MAX_NON_FINALIZED_CHAIN_FORKS) removes a chain from chain_set but leaves its block hashes in non_finalized_block_write_sent_hashes, producing the same lockout for children of the pruned fork.

Patches

Patched in Zebra 4.4.2. The fix removes stale entries from non_finalized_block_write_sent_hashes on every failed non-finalized write path.

Workarounds

There is no complete configuration-level workaround. Reducing the node's inbound peer count (network.peerset_initial_target_size) narrows the attack surface but does not eliminate it. Restarting the node clears the in-memory cache and allows the valid block to be re-fetched.

Impact

A remote unauthenticated P2P peer can permanently stall a targeted Zebra node at a specific block height. The node diverges from the network tip; downstream consumers (lightwalletd, wallets, explorers, mining infrastructure) relying on the node see a stalled chain. The attack requires winning a propagation race: delivering the poisoned block body before honest peers deliver the canonical block. A well-positioned attacker (low-latency connection to the target, observation of new blocks from other peers) can reliably win this race. In sustained form, the attacker repeats for each new block, keeping the target permanently behind.

Recovery requires restarting the node (which clears the in-memory sent-hash cache) or waiting for a reorg at the affected height (rare on the canonical chain).

Credit

Reported independently by @ipwning (primary, with ZIP-244 malleability analysis and zcashd cross-reference) and @x15-eth (first reporter, with E2E reproduction and control experiment).

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).

Summary

The P2P codec's Codec::decode() method calls src.reserve(body_len + HEADER_LEN) after parsing a 24-byte protocol header, using the attacker-claimed body_len field. This reserves up to MAX_PROTOCOL_MESSAGE_LEN (~2 MiB) of virtual buffer capacity per connection before any body bytes arrive and before the handshake completes.

However, BytesMut::reserve() sets virtual capacity without committing physical memory pages. The operating system does not allocate physical RAM until bytes are actually written into the buffer. Since the attacker never sends body bytes, the reserved capacity remains uncommitted. Reproduction of the reporter's PoC (256 threads, 30 seconds of sustained connections) showed negligible RSS impact on the Zebra process.

Zebra's existing mitigations further constrain the practical attack surface: per-IP connection limits (max_connections_per_ip = 1), a per-connection accept rate of approximately one per second, and a 3-second handshake timeout that cleans up idle connections.

Details

At zebra-network/src/protocol/external/codec.rs:406, after parsing the 24-byte header and validating the network magic and body length against MAX_PROTOCOL_MESSAGE_LEN, the codec calls src.reserve(body_len + HEADER_LEN). The codec is constructed on the bare TCP stream before negotiate_version() runs, so the reservation is reachable from any TCP peer that can send 24 bytes.

No legitimate Zcash handshake message (version, verack) is anywhere close to 2 MiB. The codec makes no distinction between pre-handshake and post-handshake message types when sizing the reservation.

Patches

The fix defers large buffer reservations until after the handshake completes, or caps the per-message reservation for pre-handshake messages to what version/verack actually require.

Workarounds

No workaround is needed. The existing per-IP rate limiting, handshake timeout, and connection limits effectively mitigate the practical impact.

Impact

Minimal. The reservation affects virtual address space only, not physical memory. Zebra's existing connection-management mitigations (per-IP limits, accept rate, handshake timeout) further constrain the attack. The code path is worth cleaning up for defense-in-depth but does not produce a measurable denial-of-service effect.

Credit

Reported by @ouicate via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

Summary

A single unauthenticated P2P peer can monopolize all 25 inbound mempool download/verification slots (MAX_INBOUND_CONCURRENCY) by advertising fake transaction IDs. While the slots are occupied, all other inbound transactions from honest peers and local RPC sendrawtransaction calls are rejected with MempoolError::FullQueue. The attacker peer is never scored for misbehavior and is not disconnected, allowing sustained denial of mempool admission.

Details

The mempool download/verification pipeline at zebrad/src/components/mempool/downloads.rs uses a single bounded pool of 25 concurrent tasks. Three architectural gaps combine to produce the vulnerability:

1. No per-peer accounting: the 25 slots are shared across all peers with no cap on how many a single peer can hold.
2. No overload signaling: when FullQueue is returned, the inbound service at zebrad/src/components/inbound.rs maps it to Response::Nil, hiding the overload from the peer connection layer. The existing handle_inbound_overload disconnection logic never fires.
3. No misbehavior attribution: peer identity is not carried through the Gossip type into the download pipeline, so verification failures cannot be attributed to the originating peer.

The attacker sends inv messages advertising fake transaction IDs. Zebra queues download tasks for each ID. The attacker stays silent; each slot is held until the TRANSACTION_DOWNLOAD_TIMEOUT (20 seconds) fires. The attacker periodically sends fresh inv waves to re-fill slots as they expire.

Two additional slot-holding techniques have been independently demonstrated: invalid-prevout transactions that park in AwaitOutput for 60 seconds, and expensive shielded proof verification with auth-variant cache bypass. All three techniques are addressed by the same per-peer accounting fix.

Patches

zebrad 4.5.0

The fix adds per-peer queue accounting to the mempool download pipeline. A single peer is limited to a fraction of MAX_INBOUND_CONCURRENCY (e.g., 5 slots out of 25). FullQueue is surfaced as an overload signal to the peer connection layer. Peer identity is plumbed through the Gossip type for misbehavior attribution.

Workarounds

There is no complete configuration-level workaround. Reducing network.peerset_initial_target_size limits the total inbound peer count but does not prevent a single peer from holding all mempool slots.

Impact

Mempool transaction admission is denied for all honest peers and local RPC clients while the attack is sustained. Block validation and chain synchronization continue normally. The attacker needs only one TCP connection and minimal bandwidth (~1 KB/s of fake inv messages). The node recovers immediately when the attacker stops. This does not affect consensus, funds, or on-disk state.

Credit

Reported by @dingledropper via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file (typically local access). With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The z_listunifiedreceivers RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (sapling_crypto::PaymentAddress::from_bytes returns None for non-subgroup Jubjub points). The handler calls .expect("using data already decoded as valid") on the fallible result. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process, not just the RPC task.

Details

zcash_address::unified::Encoding::decode validates only the structural envelope of a Unified Address (F4Jumble, bech32m, typecode ordering, 43-byte length for Sapling). It does not validate that the embedded pk_d is a valid Jubjub subgroup point or that the diversifier produces a valid g_d preimage.

At zebra-rpc/src/methods.rs:2893, the handler calls Address::try_from_sapling(network, data), which delegates to sapling_crypto::PaymentAddress::from_bytes. When from_bytes returns None (most random 32-byte strings fail the subgroup check), the .expect() fires and the process aborts.

The same crate already handles this correctly in try_from_unified at zebra-chain/src/primitives/address.rs:99-110, which returns Err when from_bytes fails. The vulnerable code path bypasses this validated route.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace .expect() with .map_err(|e| ErrorObject::owned(...)) for proper error propagation, or route through the existing try_from_unified path which already handles this case correctly.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that rejects z_listunifiedreceivers calls with untrusted address parameters.

Impact

A single authenticated RPC request terminates the zebrad process. The attack is repeatable on restart (the same request triggers the same abort), allowing an attacker to keep the node down indefinitely until the request is filtered upstream. Operators using lightwalletd backends, Zaino indexers, or mining pool infrastructure that forward RPC calls to zebrad may be exposed if the forwarding path passes through z_listunifiedreceivers.

Credit

Reported by @robustfengbin via a private GitHub Security Advisory submission.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your node accepts inbound P2P connections.

Summary

The read_getblocks and read_getheaders codec paths accepted block locator vectors up to approximately 65,535 entries (the generic TrustedPreallocate ceiling derived from MAX_PROTOCOL_MESSAGE_LEN), rather than the protocol-specification limit of 101 entries (matching zcashd's MAX_LOCATOR_SZ). Each entry in the locator vector triggers a per-hash chain lookup (HashMap::contains_key + RocksDB::contains_hash) in find_chain_intersection on a tokio blocking-pool thread.

A single maximally-sized getblocks message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups.

Details

The read_headers codec path already implements the correct pattern: it reads the CompactSize count, validates against MAX_HEADERS_PER_MESSAGE = 160 before deserialization, and rejects oversized messages. The read_getblocks and read_getheaders paths were missing this pre-deserialization count check and instead relied on the generic block::Hash::max_allocation() bound, which allows (MAX_PROTOCOL_MESSAGE_LEN - 1) / 32 = 65,535 hashes.

A legitimate block locator is logarithmic in chain length (approximately 30 hashes for the current ~3M-block Zcash chain). Zebra's own send-side cap is MAX_FIND_BLOCK_HASHES_RESULTS = 500.

The practical impact requires significant attacker bandwidth (approximately 2 MiB per request) and multiple Sybil peers to meaningfully degrade the blocking pool, which limits real-world exploitability.

Patches

Patched in Zebra 4.4.2. The fix caps block::Hash::max_allocation() at MAX_BLOCK_LOCATOR_LENGTH = 101, matching zcashd's MAX_LOCATOR_SZ. This causes the deserializer to reject oversized locators before any allocation or iteration occurs.

Workarounds

No specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.

Impact

Under sustained load from multiple Sybil peers, oversized locator vectors can occupy blocking-pool threads and degrade state-read performance. The effect is bounded by connection limits and requires significant attacker bandwidth.

Credit

Vulnerability identified by @dingledropper, who submitted the fix in PR #10570. Downstream CPU/blocking-pool impact analysis contributed by @ouicate.

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

Summary

A composite denial-of-service vulnerability in Zebra's block discovery pipeline allows an unauthenticated remote attacker to permanently halt all new block discovery on a targeted node. The attack exploits three independent weaknesses in the gossip, syncer, and download subsystems — all exercisable from a single TCP connection — to create a monotonically growing block deficit that never self-heals.

Severity

Critical — This is a Denial of Service vulnerability that requires no authentication, no special privileges, and only a single peer connection. The halt is permanent: the node will never recover without operator intervention.

Affected Versions

All Zebra versions prior to 4.4.0.

Description

Zebra discovers new blocks through two complementary paths: a gossip path (peers announce blocks via inv messages, triggering individual block downloads) and a syncer path (Zebra periodically queries peers with FindBlocks/FindHeaders to discover chains of missing blocks). Both paths must function for normal operation.

The gossip path was vulnerable because there was no per-connection rate limit on inv messages. A single connection could send enough sequential inv messages with fake block hashes to fill the entire gossip download queue in under a millisecond. The FullQueue return value was silently ignored, so legitimate block announcements from honest peers were dropped with no warning.

The syncer backup path could be degraded by responding with empty inv to FindBlocks requests and with NotFound to block download requests. Both are valid protocol responses that carried zero misbehavior penalty. The attacker's connection was never banned and never disconnected, allowing the degradation to persist indefinitely.

Combining these two vectors, an attacker could suppress both block discovery paths simultaneously from a single connection, causing the node to fall permanently behind the chain tip.

Impact

Denial of Service

• Attack Vector: Network, unauthenticated. Requires only a single TCP peer connection.
• Effect: Permanent halt of block discovery. The targeted node falls behind the chain tip and never recovers without operator intervention.
• Scope: Any Zebra node reachable by the attacker over the peer-to-peer network.

Fixed Versions

This issue is fixed in Zebra 4.4.0.

The fix drops connections that send empty responses to FindBlocks and FindHeaders messages, preventing attackers from degrading the syncer path without consequence.

Mitigation

Users should upgrade to Zebra 4.4.0 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to protect against this attack.

Credits

Zebra the researcher who reported this issue through the coordinated disclosure process.

Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output

Summary

Zebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with SIGHASH_SINGLE and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but zcashd rejects, creating a consensus split between Zebra and zcashd nodes.

A previous fix (GHSA-cwfq-rfcr-8hmp) addressed a closely related case in the same area of the code, but did not cover this specific one.

Severity

Critical - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.

Note that the impact is currently alleviated by the fact that currently most miners run zcashd.

Affected Versions

Zebra 4.4.0.

Description

Verification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code is called from Zebra through a foreign function interface (FFI), with a Rust callback that computes the sighash for each input being verified.

ZIP-244 §S.2a marks two situations as consensus failure for V5 transparent signatures:

1. The signed hash type is not one of the six canonical values; and
2. The hash type is SIGHASH_SINGLE (alone or combined with ANYONECANPAY) and the input has no transparent output at the same index.

zcashd enforces both rules: its SignatureHash raises an exception, and CheckSig catches it and fails the script. A previous fix (GHSA-cwfq-rfcr-8hmp) added the first rule to Zebra's V5 sighash callback. The second rule, however, was not added — Zebra's callback forwarded the request to librustzcash's ZIP-244 implementation, which handles an out-of-range SIGHASH_SINGLE output index by hashing an empty output set rather than refusing to produce a digest. As a result, Zebra would compute a well-defined sighash for the missing-output case and accept any signature that verified against it.

An attacker could exploit this by:

• Constructing a V5 transaction with two or more transparent inputs and fewer transparent outputs;
• Signing an input whose index has no matching vout entry with SIGHASH_SINGLE (0x03) or SIGHASH_SINGLE|ANYONECANPAY (0x83), using the digest Zebra computes;
• Broadcasting the transaction, or a block containing it, to the network.

Zebra would verify the transaction's transparent script and accept the transaction (and any block containing it), while zcashd would reject both, splitting Zebra nodes from the rest of the network.

Impact

Consensus Failure

• Attack Vector: Network.
• Effect: Network partition/consensus split.
• Scope: Any affected Zebra node.

Fixed Versions

This issue is fixed in Zebra 4.4.1.

Mitigation

Users should upgrade to Zebra 4.4.1 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.

Credits

Zebra thanks @sangsoo-osec, @zmanian, and @fivelittleducks for finding and reporting the issue.

Zebra Transparent SIGHASH_SINGLE Corresponding-Output Handling Diverges From zcashd

Summary

For V5+ transparent spends, Zebra and zcashd disagree on the same consensus rule: SIGHASH_SINGLE must fail when the input index has no corresponding output. zcashd treats this as consensus-invalid under ZIP-244, while Zebra's transparent verification path computes a digest for the missing-output case instead of failing.

The result is a direct block-validity split. A malformed V5 transparent transaction can be accepted by Zebra, retained in Zebra's mempool, selected into Zebra getblocktemplate, mined into a block, and then rejected by zcashd.

Details

Validated code revisions used during analysis:

• zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
• Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Scope note:

• earlier triage material grouped pre-V5 and V5 behavior together;
• re-execution on the pinned revisions did not reproduce the claimed pre-V5 / V4 reject-side behavior;
• this advisory therefore covers the V5+ / ZIP-244 variant only.

zcashd side:

• Transparent scripts in blocks are checked through TransactionSignatureChecker::CheckSig() and SignatureHash(): zcash/src/script/interpreter.cpp.
• In the ZIP-244 branch, SignatureHash() explicitly throws when SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY is used with nIn >= txTo.vout.size(): zcash/src/script/interpreter.cpp.
• CheckSig() catches that exception and returns false, causing the transparent script to fail.

Zebra side:

• V5 transparent inputs route into the same FFI-based transparent script verifier used for block validation: zebra/zebra-consensus/src/transaction.rs.
• Zebra converts the decoded hash type and asks its Rust sighash engine for a digest without adding the corresponding-output pre-check that zcashd enforces first: zebra/zebra-script/src/lib.rs, zebra/zebra-chain/src/primitives/zcash_primitives.rs.
• Zebra forwards canonical SIGHASH_SINGLE into the Rust ZIP-244 implementation.
• In that implementation, when input.index() >= bundle.vout.len(), the code uses transparent_outputs_hash::<TxOut>(&[]) instead of erroring: zcash_primitives/src/transaction/sighash_v5.rs, zcash_primitives/src/transaction/sighash_v5.rs.

Why this is exploitable:

• the malformed transaction only needs fewer transparent outputs than inputs;
• the attacker signs the digest that Zebra computes for the missing-output case;
• Zebra then sees a valid transparent signature, while zcashd never reaches the same digest because it fails first.

Ordinary path viability:

• zcashd ordinary mempool admission is not the practical trigger path, because the same ZIP-244 SignatureHash() checks fail there first: zcash/src/main.cpp, zcash/src/script/interpreter.cpp.
• Zebra ordinary mempool admission is viable because Zebra uses the same transparent verifier for mempool and block validation and does not have a separate "one output per input" standardness rule here: zebra/zebra-consensus/src/transaction.rs, zebra/zebrad/src/components/mempool/storage.rs.
• Zebra is a block-template producer, so the realistic stock path is Zebra mempool -> Zebra getblocktemplate -> external miner: zebra/zebra-rpc/src/methods/types/get_block_template/zip317.rs.

PoC

Validated commits:

• zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
• Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Manual reproduction steps:

1. Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.
2. Sign input 0 normally.
3. Sign input 1 with canonical SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY.
4. Use the digest returned by Zebra's ZIP-244 path, where the missing output contributes transparent_outputs_hash([]).
5. Submit the transaction to Zebra and to zcashd.
6. Observe:
   • Zebra accepts it into the mempool;
   • Zebra selects it into getblocktemplate;
   • Zebra can mine and accept a block containing it;
   • zcashd rejects it in the ordinary mempool path.

Impact

This is a direct V5+ transparent consensus split.

Who can trigger it:

• an ordinary transaction author can craft the malformed V5 transparent transaction;
• the accept-side stock path is Zebra's mempool and block-template path;
• an external miner still has to include the transaction in a block for the split to materialize.

Who is impacted:

• Zebra can accept and template a transaction / block that zcashd rejects;
• this makes the issue both a consensus-divergence problem and a practical Zebra block-template safety problem.

CVE-2026-44497: Consensus Divergence in Transparent Sighash Hash-Type Handling due to Stale Buffer

Summary

The fix for https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj introduced a separate issue due to insuficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes.

Severity

Critical - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.

Note that the impact is currently alleviated by the fact that currently most miners run zcashd.

Affected Versions

Zebra 4.3.1.

Description

Verification of transparent transactions inherits the Bitcoin Script verification code in C++, called from Zebra through a foreign function interface (FFI) with a Rust callback that computes the sighash. The fix for https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj added the missing V5 hash-type consensus check on the Rust side, returning None for undefined hash types. However, the FFI bridge only writes to the C++ sighash buffer when the callback returns Some, and the C++ checker reads that buffer unconditionally, so the failure signal is lost.

An attacker could exploit this by:

• Constructing a transparent output spent by a script that runs a valid OP_CHECKSIGVERIFY immediately before an OP_CHECKSIG with an undefined hash type.
• The first opcode primes the C++ sighash buffer with a valid digest; the second causes Zebra's callback to return None while the C++ checker verifies the invalid signature against the stale digest.
• Zebra accepts the spend, zcashd rejects it, creating a consensus split in the network.

Impact

Consensus Failure

• Attack Vector: Network.
• Effect: Network partition/consensus split.
• Scope: Any affected Zebra node, and any miner or template pipeline that relies on Zebra's validation result.

Fixed Versions

This issue is fixed in 4.4.0.

The fixes uses a workaround where the input buffer is filled with random bytes on validation failure, which makes signature validation fail (as expected) with overwhelming probability. This avoids a breaking release of the zcash_script crate. A future release will propagate the error correctly for a direct fix.

Mitigation

Users should upgrade to 4.4.0 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.

Credits

Zebra thanks @sangsoo-osec for finding and reporting the issue.

CVE-2026-44500: Allocation Amplification in Inbound Network Deserializers

Summary

Several inbound deserialization paths in Zebra allocated buffers sized against generic transport or block-size ceilings before the tighter protocol or consensus limits were enforced. An unauthenticated or post-handshake peer could therefore force the node to preallocate and parse for orders of magnitude more data than the protocol intended, across headers messages, equihash solutions in block headers, Sapling spend vectors in V5/V4 transactions, and coinbase script bytes in blocks.

Severity

Moderate - This is a Denial-of-Service Vulnerability that could allow a malicious peer to amplify per-message memory and parse cost on Zebra nodes, with effects amplified by multi-peer fan-in.

Each individual case is bounded by the 2 MiB transport ceiling or the block-size cap, so no single message causes unbounded allocation, but the cumulative gap between intended and actual limits is significant.

Affected Versions

All Zebra versions prior to 4.4.0.

Description

Zebra's network codec uses TrustedPreallocate and generic Vec deserialization to bound inbound message parsing. In several places the bound used at the deserializer was the generic transport or block-size ceiling rather than the tighter protocol or consensus rule that applies to the field, so allocation happened first and the real limit was only enforced afterwards. Four such cases were identified:

• headers message receive cap. read_headers() deserialized the CountedHeader vector via the generic TrustedPreallocate path, which allowed up to ~1,409 entries per message. The protocol ceiling MAX_FIND_BLOCK_HEADERS_RESULTS = 160 was only used on the send side, giving an ~8.8x preallocation gap on receive. Reachable before the version handshake completes since the codec is installed on raw bytes.
• Equihash solution length. Solution::zcash_deserialize decoded the solution as a generic Vec<u8> and only checked the exact consensus size (1344 bytes mainnet/testnet, 36 bytes regtest) afterwards in Solution::from_bytes. A single fixed-size header field could be inflated to nearly the full block-size ceiling before rejection.
• Sapling spend vectors in coinbase transactions. V5 spend_prefixes and V4 shielded_spends were allocated generically with block-size-derived ceilings (~5,681 / ~5,208 entries) before the consensus rule that coinbase transactions have zero Sapling spends was enforced in the verifier.
• Coinbase script bytes. Input::zcash_deserialize() read the coinbase script as a generic Vec<u8> up to the message-size cap before enforcing the consensus rule that coinbase scripts are between 2 and 100 bytes.

An attacker could exploit this by:

• Opening an inbound TCP connection (and, for the latter three cases, completing the version handshake).
• Sending one of: a headers message with a CompactSize count up to ~1,409, a block whose header carries an inflated equihash CompactSize, a tx declaring a coinbase input with a large nSpendsSapling, or a block with a coinbase input whose script length is near the message-size ceiling.
• The deserializer allocates against the loose ceiling, parses, and only then rejects.