Threat Intelligence Database

A soundness vulnerability in the variable-base scalar multiplication gadget of halo2_gadgets in the Zebrad product allowed a malicious prover to bypass the diversified-address-integrity check in Orchard Actions. This flaw enabled an adversary to produce valid proofs with an under-constrained base point, effectively allowing double-spends within the Orchard pool or theft of funds by forging spend authorizations. Exploitation is undetectable on-chain and could result in balance violations within the Orchard pool without inflating the overall ZEC supply. The vulnerability existed since the Orchard pool introduction in May 2022 and has been remediated. No evidence of exploitation prior to the fix is known.

### 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.

### 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](https://github.com/ZcashFoundation/zebra/pull/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 (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 (`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 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.

## 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 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.

### 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 `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`.