Zebra
Monthly
Initial sync in the Zcash Zebra node (zebrad 6.4.2 and earlier, plus 7.0.0-rc.0) can be stalled indefinitely by a single unauthenticated P2P peer that serves one forged checkpoint block body, causing the node to treat missing blocks as already downloaded and stop requesting them until the process is restarted. Only nodes with checkpoint_sync=true (the default) that are syncing from scratch or resyncing within roughly 3,000 blocks below the final compiled checkpoint are exposed; fully synced nodes and zebrad 7.0.0 are not affected. Impact is availability-only on one syncing node per delivery, with no invalid state written to disk, no chain fork and no funds impact; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor advisory credits multiple independent discoverers who built a working reproducer.
Denial of service in Zcash Foundation's Zebra (zebrad) releases before 7.0.0 allows any connected peer to stall block verification for minutes by relaying a single invalid transaction constructed with tens of thousands of transparent inputs, forcing quadratic ZIP-244 (and, on the v4 path, ZIP-243) signature-hash recomputation on the shared Rayon verification pool. No authentication or private key is needed - the signatures only have to be well formed enough to pass standardness and DER-encoding checks before failing - and the attacker needs roughly 1-3 ZEC parked in ~39,000 small outputs to satisfy ZIP-317 fee headroom, which is never actually spent and can be reused indefinitely. The flaw is fixed in zebrad 7.0.0 (via zcash_primitives 0.31.0); the reporter demonstrated a working Regtest proof of concept with scaling measurements, but no publicly available exploit code was identified in the available sources, and no CISA KEV entry exists for this issue.
Checkpoint sync in Zcash Foundation's Zebra node (zebrad before 7.0.0, including 6.4.2 and 7.0.0-rc.0 and the official Docker images) can be stalled indefinitely by a single unauthenticated remote peer, halting initial sync progress until an operator restarts the process. The peer serves a forged block that keeps a genuine header and hash but carries altered authorizing data, plus a second block that makes the sync round fail, so the verifier's rewind to the state tip is discarded with the cancelled future and honest blocks are afterwards rejected as already verified; the peer can repeat the attack after each restart. Impact is availability only - no crash, consensus divergence, on-disk state corruption or effect on funds - nodes already past the final checkpoint are not affected, no exploitation in the wild is reported, and the upstream advisory documents a reporter-supplied end-to-end proof of concept exercised through the P2P interface.
Unauthenticated remote peers can crash a Zcash Foundation Zebra node (zebrad) by exploiting a reachable-assertion race in the P2P connection's request lifecycle. A peer that completes an ordinary handshake, returns empty FindBlocks or FindHeaders replies, and then stops reading its socket can cause its connection to be torn down while an outbound send is still parked; the unresolved MustUseClientResponseSender is dropped, its Drop assertion fires, and because release builds use panic=abort the entire process exits, halting syncing, relaying and RPC until restart. Affected are zebrad builds before 7.0.0 (notably 6.4.2 or earlier and 7.0.0-rc.0) running as release binaries or Docker images with default P2P exposure, with the confirmed trigger path requiring the node to be syncing (more than 1,000 blocks behind tip); the timing-dependent nature (AC:H/AT:P) and availability-only impact keep this a genuine but bounded denial-of-service risk, and no public exploit code was identified at time of analysis, though the vendor has published a full technical advisory and a fixed 7.0.0 release.
Denial of service in the Zcash Foundation's Zebra node (zebrad) 2.3.0 through 7.0.0-rc.0 lets unauthenticated peers exhaust CPU and repeatedly stall block sync by relaying transactions or serving forged v5 block bodies whose transparent scripts fail verification without the peer ever being penalized. The script failure is boxed and downcast to an internal error that scores zero in the misbehavior table, so the 100-point ban never fires on the mempool, block-sync or block-gossip paths. A mempool flood is amplified because transparent signature hashing was quadratic before 7.0.0 (GHSA-j4cw-58mj-7w6v), while a single forged block body cancels the sync round, drops a still-valid hash and idles the syncer for 67 seconds. No public exploit code or CISA KEV entry was identified at time of analysis, the vendor-released patch is Zebra 7.0.0, and impact is bounded: it stops when the attack stops and does not crash the node, corrupt state, or alter what the node accepts into the chain.
Quadratic CPU cost in the mempool coinbase-maturity check of Zcash's Zebra node (zebrad) allows any connected peer to pin transaction-verification threads and stall block verification, peer handling and sync. Only zebrad 6.4.0, 6.4.1, 6.4.2 and 7.0.0-rc.0 are affected - the regression was introduced by the Transaction newtype refactor in 6.4.0 and is gone again in 7.0.0; 6.3.x and earlier are not affected. An unauthenticated peer needs no funds and no valid signatures: it sends an unsigned transaction with many transparent inputs (empty scriptSigs) and many transparent outputs, which the maturity loop processes at O(inputs × outputs) cost before the standardness check rejects it, and because that rejection is a policy error with a misbehavior score of 0 the peer is never banned and can repeat indefinitely. Impact is availability only, with recovery once the attack stops; no public exploit code has been identified at time of analysis, and there is no KEV listing or EPSS signal in the supplied data.
Remote, unauthenticated denial of service in Zcash Foundation's Zebra full node: versions 6.4.0 through 6.4.1 abort when a peer sends a single version-6 transaction that carries a pre-NU6.3 consensus branch ID (Nu5/Nu6/Nu6.1/Nu6.2), because the malformed Orchard bundle cannot be re-serialized during UnminedTx size computation and the resulting error trips an `expect()` that terminates zebrad. The malicious `tx` message is accepted pre-handshake, so the attacker needs only network reachability to the node's P2P port, no credentials or completed peer negotiation, and the crash can be repeated after every restart for sustained unavailability; no public exploit code was identified at time of analysis, but the trigger is a trivial single message and the flaw is specific to Zebra 6.4.0-6.4.1 (patched nodes reject the transaction at parse time).
Consensus divergence in Zebra Zcash nodes before 4.4.0 allows unauthenticated remote attackers to craft V5 transparent transactions that Zebra accepts and includes in getblocktemplate, while zcashd rejects the resulting blocks. Exploitation requires a Zebra miner to select the malformed SIGHASH_SINGLE transaction and mine it into a block, so the impact is a block-validity split affecting integrity and availability rather than confidentiality; no public exploit code has been identified at time of analysis. Vendor-released patch: Zebra 4.4.0.
Zcash Zebra nodes running zebrad 4.4.0 or zebra-script 6.0.0 incorrectly accept V5 transparent transactions in which a SIGHASH_SINGLE-signed input has no corresponding transparent output, allowing an unauthenticated remote attacker to broadcast crafted transactions that Zebra validates while zcashd rejects them and thereby create a consensus split. The flaw is a ZIP-244 signature-verification bypass (CWE-347) with a CVSS v4 base score of 8.3; no public exploit code was identified at time of analysis, and practical impact depends on a mixed Zebra/zcashd network, with most miners currently running zcashd. Vendor patches are available in zebrad 4.4.1 and zebra-script 6.0.1.
An authenticated RPC client can crash a Zcash Foundation Zebra full node by calling the z_listunifiedreceivers RPC method with a crafted Unified Address whose Sapling receiver carries 43 bytes that fail Jubjub subgroup validation, triggering a reachable assertion (.expect()) that aborts the entire zebrad process because Zebra's release profile is built with panic = "abort". Affected releases are zebra-rpc through 7.0.0 and zebrad through 4.4.1 (fixed in zebra-rpc 8.0.0 and zebrad 4.5.0), and the request is repeatable on restart, so a node can be kept persistently offline. Exploitation requires the RPC server to be explicitly enabled via rpc.listen_addr and the attacker to authenticate - with the default enable_cookie_auth=true this generally implies local access to the .cookie file, making fully remote exploitation a non-default configuration - and no public exploit code was identified at time of analysis.
Unauthenticated denial of service in Zebra (Zcash Foundation's full node implementation) before 6.0.0 allows remote peers to stall Tokio worker threads by submitting non-standard, high-sigop P2SH mempool transactions that reach synchronous FFI script verification before standardness checks, saturating the verifier buffer and rendering the node unresponsive. The vulnerability requires no authentication, user interaction, or non-default configuration; only reachable nodes running affected versions are impacted, and impact is limited to availability. No public exploit code has been identified at time of analysis, and the issue is not confirmed as actively exploited.
Remote unauthenticated attackers can cause a consensus divergence in Zcash Zebra nodes (zebrad 4.5.0 and zebra-script 7.0.0) by broadcasting P2SH spends that use low-threshold multisig redeem scripts, causing affected Zebra nodes to reject a block that zcashd accepts and stall off the chain, resulting in a denial of service. The vulnerability stems from incorrect signature operation counting that overcounts CHECKMULTISIG preceded by OP_1 through OP_16 as 20 sigops, inflating the MAX_BLOCK_SIGOPS count. No public exploit code has been identified at time of analysis, and no authentication or user interaction is required per the CVSS vector PR:N/UI:N.
Denial of service in the Zcash Foundation's Zebra full node before 6.1.0 lets remote unauthenticated peers stall node synchronization by poisoning the stale parent_error_map used by the state write task, after which the next canonical block is rejected for roughly 2,000 blocks. Exploitation is gated by a narrow race window: the attacker must act as a network peer and deliver a coinbase-malleated block that shares a legitimate canonical block's hash before that canonical block propagates, an AC:H/AT:P timing condition, so reliable on-demand abuse is materially limited. Impact is availability-only (CVSS 4.0 8.2, VA:H with no confidentiality or integrity effect), unauthenticated per the PR:N vectors, and no public exploit code has been identified at time of analysis; a vendor-released patch is available in Zebra 6.1.0.
Denial of service in the Zcash Foundation's Zebra full node implementation before 6.1.0 allows an unauthenticated remote attacker to stall block validation on every validating node for more than 52 seconds. The root cause is quadratic behaviour in the remaining_transaction_value routine, which clones the entire block-level spent-UTXO map once per transaction during contextual verification, so roughly 26,000 minimal single-input transactions placed in a single block or widely seeded into the mempool are enough to freeze validation work. Exploitation is not trivial: the attacker must get that crafted transaction set mined or broadly propagated (reflected in CVSS AC:H and AT:P), and no public exploit code has been identified at time of analysis; the assessed impact is availability-only (CVSS 3.1 A:H) with no confidentiality or integrity loss.
Zcash Foundation's Zebra full node (zebrad) before 6.2.1 can be stalled in block verification by any unauthenticated peer on the P2P network: an attacker pushes zero-fee V6 mempool transactions containing invalid, zero-filled Orchard and Ironwood Halo2 proofs, which drain the shared, unprioritized proof-verification queue and cause the node to fall behind the chain tip. Impact is confined to availability (CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) - there is no confidentiality or integrity loss - and exploitation requires only that the node accepts untrusted inbound peers and relays mempool transactions, i.e. its normal operating mode. No public exploit code was identified at time of analysis and the CVE is not confirmed actively exploited; the issue is a resource-amplification/denial-of-service class (CWE-405) rather than data compromise.
Block-sync denial of service in Zebra (zebrad), the Rust implementation of a Zcash full node, affects all versions before 6.3.0. During block download, a malicious peer can repeatedly serve a canonical block whose coinbase scriptSig is rewritten to claim height 1 while preserving the requested block hash - an evasion made possible because V5 transaction IDs exclude the scriptSig - causing the node to discard the block as too far behind the tip and repeatedly refetch it instead of advancing to the newest chain tip. The attacker remains unauthenticated (CVSS vector PR:N) and must simply be an accepted block-supplying peer; the flaw is an insufficient verification of data authenticity issue (CWE-345) whose impact our assessment bounds to availability only (VA:H in the CVE 4.0 score, but no confidentiality or integrity loss), so real-world severity is a sync delay rather than node compromise. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
Remote denial-of-service in Zebra (Zcash node implementation) versions prior to 4.4.0 allows unauthenticated attackers to permanently halt block synchronization via a single TCP connection. The attack exploits three independent weaknesses in gossip, syncer, and download subsystems to create an irreversible block discovery deficit. Vendor patch available in version 4.4.0. EPSS data unavailable; no CISA KEV listing or public exploit code identified at time of analysis, but the technical barrier appears low given network attack vector with no authentication or complexity requirements (CVSS 4.0: AV:N/AC:L/PR:N).
Zcash Foundation's Zebra node (zebrad) scores lock-time mempool rejections at the peer-ban threshold, so a node that is one block behind a relaying peer permanently or temporarily bans that honest peer for simply relaying a valid transaction. Affected versions are 4.5.0 through 6.4.2 and 7.0.0-rc.0, and the flaw is remotely reachable without authentication by any peer that can relay or advertise transactions (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/VA:L). The impact is limited to peer-set erosion rather than consensus, funds or node liveness: 6.4.x bans the sender's IP group for 24 hours, while 4.5.0 through 6.3.x hold the ban per IP with no time-based expiry until the node restarts. No public exploit code has been identified at time of analysis, although the issue was independently reported publicly (issue #11623) and the reporter described a complete two-node reproduction.
Zebra versions prior to 6.4.0 improperly validate the integrity of gossiped blocks, allowing an unauthenticated inbound peer to force the node to drop legitimate new blocks without penalizing the attacker. By rewriting a genuine block's coinbase scriptSig to height 1 while preserving the valid ZIP-244 block hash, an attacker can trigger a behind-tip drop before consensus validation, delaying tip discovery for mining backends. No public exploit code has been identified at time of analysis, and the effect is limited to availability with no code execution or data disclosure.
Zcash Zebra nodes before 6.4.0 can be stalled during synchronization by unauthenticated network peers that serve forged block bodies carrying valid header hashes. Attackers can flip authorizing-only bytes such as the coinbase scriptSig, forcing the node to waste computational resources on full Sapling, Orchard, and Ironwood proof verification for up to a 67-second sync stall. This moderate-severity availability issue has no public exploit identified at time of analysis and requires no authentication (PR:N), but the attacker must be a connected peer during a sync operation.
Unauthenticated peers can evade ban enforcement in Zcash Zebra versions 2.3.0 through 6.3.x because the node keys ban decisions and misbehavior scores to exact IP addresses rather than network prefixes. An attacker controlling an IPv6 /64 allocation can rotate source addresses to sidestep bans, or can flood the 20,000-entry FIFO ban list to evict legitimate entries and restore access for previously banned peers. This is a moderate-severity protection-mechanism failure (CWE-693) with integrity-only impact - it does not grant code execution, data access, or node shutdown - and no public exploit identified at time of analysis.
Resource exhaustion in Zcash Zebra (zebrad) 4.4.1 and earlier allows unauthenticated remote P2P peers to tie up blocking-pool threads by sending getblocks or getheaders messages with block-locator vectors far larger than the protocol's 101-entry limit, degrading block validation, RPC, and mempool lookups. The root cause is an uncapped locator length (accepting up to 65,535 hashes derived from the generic MAX_PROTOCOL_MESSAGE_LEN allocation bound) with each hash triggering a chain lookup on a blocking-pool thread. Practical impact is bounded: it requires roughly 2 MiB of attacker bandwidth per request and multiple sustained/Sybil peers, existing backpressure (load shedding, per-peer sequential processing, connection limits) constrains the effect, nodes that do not accept inbound connections are unaffected, and there is no public exploit identified at time of analysis; the independent assessment rates this a modest-priority availability weakness, not a node crash. Vendor patches are available and the fix has been merged upstream.
Zcash Zebra before 6.3.0 can falsely report a ready-to-serve state when a sync peer returns a valid FindBlocks response containing only the next block hash, because the ChainSync::obtain_tips logic discards that response as exceptional and produces a zero-length sync sample. The /ready endpoint then returns 200 OK while the node is still behind the chain tip. This is an unauthenticated remote correctness/reliability issue with low availability impact per the independent assessment (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L); no public exploit was identified at time of analysis, and a vendor patch is available in Zebra 6.3.0.
Mempool resource exhaustion in Zcash's Zebra (zebrad) node affecting versions 5.0.0 through before 6.0.0-rc.0 allows any inbound P2P peer to flood the node with unique transactions that bypass the per-peer mempool admission cap, crowding out honest peers' transaction relay. The bypass exists because transactions delivered as direct P2P 'tx' messages are queued without the sending peer being recorded as their source, so the per-peer admission limit (CWE-770, uncontrolled resource consumption) is never applied to them. Exploitation requires no authentication, user interaction, or special configuration - any node accepting inbound Zcash P2P connections on an affected version is exposed - although the practical effect is degraded transaction propagation rather than node compromise or crash; no public exploit code identified at time of analysis. Vendor-released patch: 6.0.0-rc.0.
Remote, unauthenticated denial of service in the Zcash Foundation's Zebra node: any attacker who can reach the getblock JSON-RPC method - directly or through a lightwalletd instance that forwards block queries - can crash the node process, and by repeating the call hold it in a crash loop, by requesting verbosity 2 for a side-chain block. All Zebra versions before 11.0.0 are affected, and default configurations are vulnerable because the flaw is triggered by a routine, unprivileged RPC request requiring no credentials, privileges, or user interaction. Impact is limited to availability (node crash/crash loop) with no data exposure or code execution; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, though the low complexity and remote reachability make it operationally significant for operators exposing the RPC surface.
Denial of service in Zcash Foundation's Zebra node software before 6.1.0 lets unauthenticated peers on the Zcash peer-to-peer network degrade block processing by roughly sevenfold. An attacker repeatedly pushes transactions carrying invalid Orchard proofs that are routed into the shared halo2 batch verifier; because these pushed transactions are never misbehavior-scored, the offending peer is neither penalized nor disconnected, and the poisoned batch verifier forces honest block proofs onto the much slower individual-verification path. The impact is availability-only with zero confidentiality or integrity loss, and no public exploit code has been identified at time of analysis.
Mining nodes running Zebra, the Zcash Foundation's Rust implementation of a Zcash node, at versions before 6.1.0 can be manipulated into building oversized block templates that the network rejects, wasting the miner's proof-of-work. The ZIP-317 block template selector fails to include block header and transaction-count bytes in its size budget, so a remote, unauthenticated attacker who can get valid, selectable transactions into the victim miner's mempool can shape the template across the maximum block size boundary. Impact is availability-only (assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L; vendor score 6.3), the attack demands precise mempool shaping and timing, and no public exploit code or CISA KEV entry was identified at time of analysis.
Block download denial of service in the Zcash Foundation's Zebra node before 6.2.1 lets any unauthenticated peer on the node's P2P block-sync interface stall synchronization and keep the node behind the chain tip by sending a contextually invalid block whose header hash matches that of an honest block, causing the honest block to be skipped. The root cause is an incomplete-cleanup defect (CWE-459) in which rejected hashes linger in Zebra's SentHashes tracking, so Request::KnownBlock keeps treating the legitimate block as already known. The reporting CNA assigns CVSS:4.0 base 6.9, while the independent assessment rates it CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - a genuine but moderate availability/liveness issue rather than a critical flaw, since it causes no crash, no data disclosure, and no chain alteration; no public exploit code exists and there is no confirmed active exploitation (not listed in CISA KEV) at time of analysis. Only nodes actively catching up are affected - a fully synced node that is not syncing onward is not impacted.
Unauthenticated peer misbehavior-ban bypass in Zcash Foundation Zebra nodes before 6.3.0 lets any remote peer that can open a Zcash P2P connection repeatedly force block download and Equihash verification work while escaping the node's misbehavior scoring, degrading availability through resource exhaustion. The flaw is a type-cast error (CWE-704) in the inbound block cleanup path, where a RouterError is incorrectly downcast to VerifyBlockError so the accumulated misbehavior score is discarded instead of triggering a ban; it affects all Zebra releases from 0 through 6.3.0 in the ZcashFoundation:zebra CPE. CVSS 4.0 scores it 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N, with only low availability impact and no confidentiality or integrity impact), and the independent assessment rates it a medium-severity resource-consumption issue rather than a critical one. No public exploit code was identified at time of analysis and there is no CISA KEV listing, but a vendor fix is available in Zebra 6.3.0.
Peer-set erosion in Zcash Foundation's Zebra (zebrad) node software, versions 4.5.0 through releases prior to 6.3.0, lets a connected P2P peer turn a syncing node's own ban logic against honest peers: the node loses track of which peer supplied block hashes in FindBlocks responses, so when a requested block arrives more than 50,000 heights above its tip, the 100-point misbehavior threshold (the ban threshold) is charged to an innocent peer instead of the attacker. Unauthenticated remote attackers need only ordinary network peering (PR:N), but the victim must be actively mid-sync and well behind the chain tip and the far-ahead condition must be met, making exploitation conditions-dependent (AC:H, AT:P) rather than universally triggerable. The result is a degraded peer set and elevated eclipse risk for the affected node rather than a consensus break; no public exploit code was identified at time of analysis and active exploitation is not confirmed. This is a genuine but moderate-severity peer-to-peer integrity/availability issue, not a high-urgency emergency.
A vulnerability of authentication bypass has been found on a Zebra Technologies ZTC ZT410-203dpi ZPL printer. Rated medium severity (CVSS 4.3), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
An issue was discovered on Zebra (formerly Motorola Solutions) Fixed RFID Reader FX9500 devices. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Motorola FX9500 devices allow remote attackers to conduct absolute path traversal attacks, as demonstrated by PL/SQL Server Pages files such as /include/viewtagdb.psp. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Zebra Industrial Printers All Versions, Zebra printers are shipped with unrestricted end-user access to front panel options. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Initial sync in the Zcash Zebra node (zebrad 6.4.2 and earlier, plus 7.0.0-rc.0) can be stalled indefinitely by a single unauthenticated P2P peer that serves one forged checkpoint block body, causing the node to treat missing blocks as already downloaded and stop requesting them until the process is restarted. Only nodes with checkpoint_sync=true (the default) that are syncing from scratch or resyncing within roughly 3,000 blocks below the final compiled checkpoint are exposed; fully synced nodes and zebrad 7.0.0 are not affected. Impact is availability-only on one syncing node per delivery, with no invalid state written to disk, no chain fork and no funds impact; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor advisory credits multiple independent discoverers who built a working reproducer.
Denial of service in Zcash Foundation's Zebra (zebrad) releases before 7.0.0 allows any connected peer to stall block verification for minutes by relaying a single invalid transaction constructed with tens of thousands of transparent inputs, forcing quadratic ZIP-244 (and, on the v4 path, ZIP-243) signature-hash recomputation on the shared Rayon verification pool. No authentication or private key is needed - the signatures only have to be well formed enough to pass standardness and DER-encoding checks before failing - and the attacker needs roughly 1-3 ZEC parked in ~39,000 small outputs to satisfy ZIP-317 fee headroom, which is never actually spent and can be reused indefinitely. The flaw is fixed in zebrad 7.0.0 (via zcash_primitives 0.31.0); the reporter demonstrated a working Regtest proof of concept with scaling measurements, but no publicly available exploit code was identified in the available sources, and no CISA KEV entry exists for this issue.
Checkpoint sync in Zcash Foundation's Zebra node (zebrad before 7.0.0, including 6.4.2 and 7.0.0-rc.0 and the official Docker images) can be stalled indefinitely by a single unauthenticated remote peer, halting initial sync progress until an operator restarts the process. The peer serves a forged block that keeps a genuine header and hash but carries altered authorizing data, plus a second block that makes the sync round fail, so the verifier's rewind to the state tip is discarded with the cancelled future and honest blocks are afterwards rejected as already verified; the peer can repeat the attack after each restart. Impact is availability only - no crash, consensus divergence, on-disk state corruption or effect on funds - nodes already past the final checkpoint are not affected, no exploitation in the wild is reported, and the upstream advisory documents a reporter-supplied end-to-end proof of concept exercised through the P2P interface.
Unauthenticated remote peers can crash a Zcash Foundation Zebra node (zebrad) by exploiting a reachable-assertion race in the P2P connection's request lifecycle. A peer that completes an ordinary handshake, returns empty FindBlocks or FindHeaders replies, and then stops reading its socket can cause its connection to be torn down while an outbound send is still parked; the unresolved MustUseClientResponseSender is dropped, its Drop assertion fires, and because release builds use panic=abort the entire process exits, halting syncing, relaying and RPC until restart. Affected are zebrad builds before 7.0.0 (notably 6.4.2 or earlier and 7.0.0-rc.0) running as release binaries or Docker images with default P2P exposure, with the confirmed trigger path requiring the node to be syncing (more than 1,000 blocks behind tip); the timing-dependent nature (AC:H/AT:P) and availability-only impact keep this a genuine but bounded denial-of-service risk, and no public exploit code was identified at time of analysis, though the vendor has published a full technical advisory and a fixed 7.0.0 release.
Denial of service in the Zcash Foundation's Zebra node (zebrad) 2.3.0 through 7.0.0-rc.0 lets unauthenticated peers exhaust CPU and repeatedly stall block sync by relaying transactions or serving forged v5 block bodies whose transparent scripts fail verification without the peer ever being penalized. The script failure is boxed and downcast to an internal error that scores zero in the misbehavior table, so the 100-point ban never fires on the mempool, block-sync or block-gossip paths. A mempool flood is amplified because transparent signature hashing was quadratic before 7.0.0 (GHSA-j4cw-58mj-7w6v), while a single forged block body cancels the sync round, drops a still-valid hash and idles the syncer for 67 seconds. No public exploit code or CISA KEV entry was identified at time of analysis, the vendor-released patch is Zebra 7.0.0, and impact is bounded: it stops when the attack stops and does not crash the node, corrupt state, or alter what the node accepts into the chain.
Quadratic CPU cost in the mempool coinbase-maturity check of Zcash's Zebra node (zebrad) allows any connected peer to pin transaction-verification threads and stall block verification, peer handling and sync. Only zebrad 6.4.0, 6.4.1, 6.4.2 and 7.0.0-rc.0 are affected - the regression was introduced by the Transaction newtype refactor in 6.4.0 and is gone again in 7.0.0; 6.3.x and earlier are not affected. An unauthenticated peer needs no funds and no valid signatures: it sends an unsigned transaction with many transparent inputs (empty scriptSigs) and many transparent outputs, which the maturity loop processes at O(inputs × outputs) cost before the standardness check rejects it, and because that rejection is a policy error with a misbehavior score of 0 the peer is never banned and can repeat indefinitely. Impact is availability only, with recovery once the attack stops; no public exploit code has been identified at time of analysis, and there is no KEV listing or EPSS signal in the supplied data.
Remote, unauthenticated denial of service in Zcash Foundation's Zebra full node: versions 6.4.0 through 6.4.1 abort when a peer sends a single version-6 transaction that carries a pre-NU6.3 consensus branch ID (Nu5/Nu6/Nu6.1/Nu6.2), because the malformed Orchard bundle cannot be re-serialized during UnminedTx size computation and the resulting error trips an `expect()` that terminates zebrad. The malicious `tx` message is accepted pre-handshake, so the attacker needs only network reachability to the node's P2P port, no credentials or completed peer negotiation, and the crash can be repeated after every restart for sustained unavailability; no public exploit code was identified at time of analysis, but the trigger is a trivial single message and the flaw is specific to Zebra 6.4.0-6.4.1 (patched nodes reject the transaction at parse time).
Consensus divergence in Zebra Zcash nodes before 4.4.0 allows unauthenticated remote attackers to craft V5 transparent transactions that Zebra accepts and includes in getblocktemplate, while zcashd rejects the resulting blocks. Exploitation requires a Zebra miner to select the malformed SIGHASH_SINGLE transaction and mine it into a block, so the impact is a block-validity split affecting integrity and availability rather than confidentiality; no public exploit code has been identified at time of analysis. Vendor-released patch: Zebra 4.4.0.
Zcash Zebra nodes running zebrad 4.4.0 or zebra-script 6.0.0 incorrectly accept V5 transparent transactions in which a SIGHASH_SINGLE-signed input has no corresponding transparent output, allowing an unauthenticated remote attacker to broadcast crafted transactions that Zebra validates while zcashd rejects them and thereby create a consensus split. The flaw is a ZIP-244 signature-verification bypass (CWE-347) with a CVSS v4 base score of 8.3; no public exploit code was identified at time of analysis, and practical impact depends on a mixed Zebra/zcashd network, with most miners currently running zcashd. Vendor patches are available in zebrad 4.4.1 and zebra-script 6.0.1.
An authenticated RPC client can crash a Zcash Foundation Zebra full node by calling the z_listunifiedreceivers RPC method with a crafted Unified Address whose Sapling receiver carries 43 bytes that fail Jubjub subgroup validation, triggering a reachable assertion (.expect()) that aborts the entire zebrad process because Zebra's release profile is built with panic = "abort". Affected releases are zebra-rpc through 7.0.0 and zebrad through 4.4.1 (fixed in zebra-rpc 8.0.0 and zebrad 4.5.0), and the request is repeatable on restart, so a node can be kept persistently offline. Exploitation requires the RPC server to be explicitly enabled via rpc.listen_addr and the attacker to authenticate - with the default enable_cookie_auth=true this generally implies local access to the .cookie file, making fully remote exploitation a non-default configuration - and no public exploit code was identified at time of analysis.
Unauthenticated denial of service in Zebra (Zcash Foundation's full node implementation) before 6.0.0 allows remote peers to stall Tokio worker threads by submitting non-standard, high-sigop P2SH mempool transactions that reach synchronous FFI script verification before standardness checks, saturating the verifier buffer and rendering the node unresponsive. The vulnerability requires no authentication, user interaction, or non-default configuration; only reachable nodes running affected versions are impacted, and impact is limited to availability. No public exploit code has been identified at time of analysis, and the issue is not confirmed as actively exploited.
Remote unauthenticated attackers can cause a consensus divergence in Zcash Zebra nodes (zebrad 4.5.0 and zebra-script 7.0.0) by broadcasting P2SH spends that use low-threshold multisig redeem scripts, causing affected Zebra nodes to reject a block that zcashd accepts and stall off the chain, resulting in a denial of service. The vulnerability stems from incorrect signature operation counting that overcounts CHECKMULTISIG preceded by OP_1 through OP_16 as 20 sigops, inflating the MAX_BLOCK_SIGOPS count. No public exploit code has been identified at time of analysis, and no authentication or user interaction is required per the CVSS vector PR:N/UI:N.
Denial of service in the Zcash Foundation's Zebra full node before 6.1.0 lets remote unauthenticated peers stall node synchronization by poisoning the stale parent_error_map used by the state write task, after which the next canonical block is rejected for roughly 2,000 blocks. Exploitation is gated by a narrow race window: the attacker must act as a network peer and deliver a coinbase-malleated block that shares a legitimate canonical block's hash before that canonical block propagates, an AC:H/AT:P timing condition, so reliable on-demand abuse is materially limited. Impact is availability-only (CVSS 4.0 8.2, VA:H with no confidentiality or integrity effect), unauthenticated per the PR:N vectors, and no public exploit code has been identified at time of analysis; a vendor-released patch is available in Zebra 6.1.0.
Denial of service in the Zcash Foundation's Zebra full node implementation before 6.1.0 allows an unauthenticated remote attacker to stall block validation on every validating node for more than 52 seconds. The root cause is quadratic behaviour in the remaining_transaction_value routine, which clones the entire block-level spent-UTXO map once per transaction during contextual verification, so roughly 26,000 minimal single-input transactions placed in a single block or widely seeded into the mempool are enough to freeze validation work. Exploitation is not trivial: the attacker must get that crafted transaction set mined or broadly propagated (reflected in CVSS AC:H and AT:P), and no public exploit code has been identified at time of analysis; the assessed impact is availability-only (CVSS 3.1 A:H) with no confidentiality or integrity loss.
Zcash Foundation's Zebra full node (zebrad) before 6.2.1 can be stalled in block verification by any unauthenticated peer on the P2P network: an attacker pushes zero-fee V6 mempool transactions containing invalid, zero-filled Orchard and Ironwood Halo2 proofs, which drain the shared, unprioritized proof-verification queue and cause the node to fall behind the chain tip. Impact is confined to availability (CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) - there is no confidentiality or integrity loss - and exploitation requires only that the node accepts untrusted inbound peers and relays mempool transactions, i.e. its normal operating mode. No public exploit code was identified at time of analysis and the CVE is not confirmed actively exploited; the issue is a resource-amplification/denial-of-service class (CWE-405) rather than data compromise.
Block-sync denial of service in Zebra (zebrad), the Rust implementation of a Zcash full node, affects all versions before 6.3.0. During block download, a malicious peer can repeatedly serve a canonical block whose coinbase scriptSig is rewritten to claim height 1 while preserving the requested block hash - an evasion made possible because V5 transaction IDs exclude the scriptSig - causing the node to discard the block as too far behind the tip and repeatedly refetch it instead of advancing to the newest chain tip. The attacker remains unauthenticated (CVSS vector PR:N) and must simply be an accepted block-supplying peer; the flaw is an insufficient verification of data authenticity issue (CWE-345) whose impact our assessment bounds to availability only (VA:H in the CVE 4.0 score, but no confidentiality or integrity loss), so real-world severity is a sync delay rather than node compromise. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
Remote denial-of-service in Zebra (Zcash node implementation) versions prior to 4.4.0 allows unauthenticated attackers to permanently halt block synchronization via a single TCP connection. The attack exploits three independent weaknesses in gossip, syncer, and download subsystems to create an irreversible block discovery deficit. Vendor patch available in version 4.4.0. EPSS data unavailable; no CISA KEV listing or public exploit code identified at time of analysis, but the technical barrier appears low given network attack vector with no authentication or complexity requirements (CVSS 4.0: AV:N/AC:L/PR:N).
Zcash Foundation's Zebra node (zebrad) scores lock-time mempool rejections at the peer-ban threshold, so a node that is one block behind a relaying peer permanently or temporarily bans that honest peer for simply relaying a valid transaction. Affected versions are 4.5.0 through 6.4.2 and 7.0.0-rc.0, and the flaw is remotely reachable without authentication by any peer that can relay or advertise transactions (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/VA:L). The impact is limited to peer-set erosion rather than consensus, funds or node liveness: 6.4.x bans the sender's IP group for 24 hours, while 4.5.0 through 6.3.x hold the ban per IP with no time-based expiry until the node restarts. No public exploit code has been identified at time of analysis, although the issue was independently reported publicly (issue #11623) and the reporter described a complete two-node reproduction.
Zebra versions prior to 6.4.0 improperly validate the integrity of gossiped blocks, allowing an unauthenticated inbound peer to force the node to drop legitimate new blocks without penalizing the attacker. By rewriting a genuine block's coinbase scriptSig to height 1 while preserving the valid ZIP-244 block hash, an attacker can trigger a behind-tip drop before consensus validation, delaying tip discovery for mining backends. No public exploit code has been identified at time of analysis, and the effect is limited to availability with no code execution or data disclosure.
Zcash Zebra nodes before 6.4.0 can be stalled during synchronization by unauthenticated network peers that serve forged block bodies carrying valid header hashes. Attackers can flip authorizing-only bytes such as the coinbase scriptSig, forcing the node to waste computational resources on full Sapling, Orchard, and Ironwood proof verification for up to a 67-second sync stall. This moderate-severity availability issue has no public exploit identified at time of analysis and requires no authentication (PR:N), but the attacker must be a connected peer during a sync operation.
Unauthenticated peers can evade ban enforcement in Zcash Zebra versions 2.3.0 through 6.3.x because the node keys ban decisions and misbehavior scores to exact IP addresses rather than network prefixes. An attacker controlling an IPv6 /64 allocation can rotate source addresses to sidestep bans, or can flood the 20,000-entry FIFO ban list to evict legitimate entries and restore access for previously banned peers. This is a moderate-severity protection-mechanism failure (CWE-693) with integrity-only impact - it does not grant code execution, data access, or node shutdown - and no public exploit identified at time of analysis.
Resource exhaustion in Zcash Zebra (zebrad) 4.4.1 and earlier allows unauthenticated remote P2P peers to tie up blocking-pool threads by sending getblocks or getheaders messages with block-locator vectors far larger than the protocol's 101-entry limit, degrading block validation, RPC, and mempool lookups. The root cause is an uncapped locator length (accepting up to 65,535 hashes derived from the generic MAX_PROTOCOL_MESSAGE_LEN allocation bound) with each hash triggering a chain lookup on a blocking-pool thread. Practical impact is bounded: it requires roughly 2 MiB of attacker bandwidth per request and multiple sustained/Sybil peers, existing backpressure (load shedding, per-peer sequential processing, connection limits) constrains the effect, nodes that do not accept inbound connections are unaffected, and there is no public exploit identified at time of analysis; the independent assessment rates this a modest-priority availability weakness, not a node crash. Vendor patches are available and the fix has been merged upstream.
Zcash Zebra before 6.3.0 can falsely report a ready-to-serve state when a sync peer returns a valid FindBlocks response containing only the next block hash, because the ChainSync::obtain_tips logic discards that response as exceptional and produces a zero-length sync sample. The /ready endpoint then returns 200 OK while the node is still behind the chain tip. This is an unauthenticated remote correctness/reliability issue with low availability impact per the independent assessment (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L); no public exploit was identified at time of analysis, and a vendor patch is available in Zebra 6.3.0.
Mempool resource exhaustion in Zcash's Zebra (zebrad) node affecting versions 5.0.0 through before 6.0.0-rc.0 allows any inbound P2P peer to flood the node with unique transactions that bypass the per-peer mempool admission cap, crowding out honest peers' transaction relay. The bypass exists because transactions delivered as direct P2P 'tx' messages are queued without the sending peer being recorded as their source, so the per-peer admission limit (CWE-770, uncontrolled resource consumption) is never applied to them. Exploitation requires no authentication, user interaction, or special configuration - any node accepting inbound Zcash P2P connections on an affected version is exposed - although the practical effect is degraded transaction propagation rather than node compromise or crash; no public exploit code identified at time of analysis. Vendor-released patch: 6.0.0-rc.0.
Remote, unauthenticated denial of service in the Zcash Foundation's Zebra node: any attacker who can reach the getblock JSON-RPC method - directly or through a lightwalletd instance that forwards block queries - can crash the node process, and by repeating the call hold it in a crash loop, by requesting verbosity 2 for a side-chain block. All Zebra versions before 11.0.0 are affected, and default configurations are vulnerable because the flaw is triggered by a routine, unprivileged RPC request requiring no credentials, privileges, or user interaction. Impact is limited to availability (node crash/crash loop) with no data exposure or code execution; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, though the low complexity and remote reachability make it operationally significant for operators exposing the RPC surface.
Denial of service in Zcash Foundation's Zebra node software before 6.1.0 lets unauthenticated peers on the Zcash peer-to-peer network degrade block processing by roughly sevenfold. An attacker repeatedly pushes transactions carrying invalid Orchard proofs that are routed into the shared halo2 batch verifier; because these pushed transactions are never misbehavior-scored, the offending peer is neither penalized nor disconnected, and the poisoned batch verifier forces honest block proofs onto the much slower individual-verification path. The impact is availability-only with zero confidentiality or integrity loss, and no public exploit code has been identified at time of analysis.
Mining nodes running Zebra, the Zcash Foundation's Rust implementation of a Zcash node, at versions before 6.1.0 can be manipulated into building oversized block templates that the network rejects, wasting the miner's proof-of-work. The ZIP-317 block template selector fails to include block header and transaction-count bytes in its size budget, so a remote, unauthenticated attacker who can get valid, selectable transactions into the victim miner's mempool can shape the template across the maximum block size boundary. Impact is availability-only (assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L; vendor score 6.3), the attack demands precise mempool shaping and timing, and no public exploit code or CISA KEV entry was identified at time of analysis.
Block download denial of service in the Zcash Foundation's Zebra node before 6.2.1 lets any unauthenticated peer on the node's P2P block-sync interface stall synchronization and keep the node behind the chain tip by sending a contextually invalid block whose header hash matches that of an honest block, causing the honest block to be skipped. The root cause is an incomplete-cleanup defect (CWE-459) in which rejected hashes linger in Zebra's SentHashes tracking, so Request::KnownBlock keeps treating the legitimate block as already known. The reporting CNA assigns CVSS:4.0 base 6.9, while the independent assessment rates it CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - a genuine but moderate availability/liveness issue rather than a critical flaw, since it causes no crash, no data disclosure, and no chain alteration; no public exploit code exists and there is no confirmed active exploitation (not listed in CISA KEV) at time of analysis. Only nodes actively catching up are affected - a fully synced node that is not syncing onward is not impacted.
Unauthenticated peer misbehavior-ban bypass in Zcash Foundation Zebra nodes before 6.3.0 lets any remote peer that can open a Zcash P2P connection repeatedly force block download and Equihash verification work while escaping the node's misbehavior scoring, degrading availability through resource exhaustion. The flaw is a type-cast error (CWE-704) in the inbound block cleanup path, where a RouterError is incorrectly downcast to VerifyBlockError so the accumulated misbehavior score is discarded instead of triggering a ban; it affects all Zebra releases from 0 through 6.3.0 in the ZcashFoundation:zebra CPE. CVSS 4.0 scores it 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N, with only low availability impact and no confidentiality or integrity impact), and the independent assessment rates it a medium-severity resource-consumption issue rather than a critical one. No public exploit code was identified at time of analysis and there is no CISA KEV listing, but a vendor fix is available in Zebra 6.3.0.
Peer-set erosion in Zcash Foundation's Zebra (zebrad) node software, versions 4.5.0 through releases prior to 6.3.0, lets a connected P2P peer turn a syncing node's own ban logic against honest peers: the node loses track of which peer supplied block hashes in FindBlocks responses, so when a requested block arrives more than 50,000 heights above its tip, the 100-point misbehavior threshold (the ban threshold) is charged to an innocent peer instead of the attacker. Unauthenticated remote attackers need only ordinary network peering (PR:N), but the victim must be actively mid-sync and well behind the chain tip and the far-ahead condition must be met, making exploitation conditions-dependent (AC:H, AT:P) rather than universally triggerable. The result is a degraded peer set and elevated eclipse risk for the affected node rather than a consensus break; no public exploit code was identified at time of analysis and active exploitation is not confirmed. This is a genuine but moderate-severity peer-to-peer integrity/availability issue, not a high-urgency emergency.
A vulnerability of authentication bypass has been found on a Zebra Technologies ZTC ZT410-203dpi ZPL printer. Rated medium severity (CVSS 4.3), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
An issue was discovered on Zebra (formerly Motorola Solutions) Fixed RFID Reader FX9500 devices. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Motorola FX9500 devices allow remote attackers to conduct absolute path traversal attacks, as demonstrated by PL/SQL Server Pages files such as /include/viewtagdb.psp. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Zebra Industrial Printers All Versions, Zebra printers are shipped with unrestricted end-user access to front panel options. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.