Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-52735 | 9.3 critical | 1.0% | no CPE yet | ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, Zebra can accept a block that zcashd rejects because the P2SH signature-operation counter undercounts redeem scripts containing a disabled opcode followed by signature opcodes. In zebra-script/src/lib.rs, p2sh_input_sigop_count used the pure-Rust script::Code::sig_op_count path, whose try_fold parser stops at disabled opcodes such as OP_CODESEPARATOR and returns only the partial count accumulated before the error. The zcashd reference implementation continues static signature-operation counting through disabled opcodes, so an attacker can broadcast P2SH spends that Zebra counts below MAX_BLOCK_SIGOPS while zcashd counts above the 20,000-operation limit. If a Zebra miner includes those transactions, Zebra validators accept the block while zcashd validators reject it, creating a consensus chain split that affects network integrity and availability without requiring the attacker to produce a block. This issue is fixed in version 4.5.0. | 22 Oct |
| CVE-2026-52736 | 8.7 high | 1.0% | no CPE yet | ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a remote unauthenticated P2P peer can stall a Zebra node by racing an invalid block body against the valid canonical body for the same block header hash. ZIP-244 permits the attacker to mutate coinbase scriptSig authentication data while retaining the transaction identifiers, merkle root, and block header hash, so the poisoned body fails later commitment validation but shares the canonical hash. In zebra-state/src/service.rs, queue_and_commit_to_non_finalized_state recorded the hash in non_finalized_block_write_sent_hashes before contextual validation completed and did not remove it when the write task rejected the body. When the honest body later arrived, the cached hash caused KnownBlock::WriteChannel duplicate handling to suppress it, leaving the node stuck one height behind until restart or reorganization. This issue is fixed in version 4.5.0. | 22 Oct |
| CVE-2026-52829 | 7.5 high | 1.0% | no CPE yet | ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, an unauthenticated IPv4 peer can deterministically terminate a synced Zebra node using the default Linux dual-stack listener configuration. The handshake path canonicalized an IPv4-mapped IPv6 PeerSocketAddr such as ::ffff:127.0.0.1 to plain IPv4 before storing it through MetaAddr::new_connected, but the mempool misbehavior path forwarded the raw transient address to MetaAddrChange::UpdateMisbehavior. In zebra-network/src/meta_addr.rs, apply_to_meta_addr then compared the canonical address-book entry with the raw update address and reached its unexpected address mismatch assertion. After the misbehavior batch flush, panic equals abort terminated zebrad; the peer only needed to complete a P2P handshake and advertise an invalid mempool transaction. This issue is fixed in version 4.5.0. | 22 Oct |
| CVE-2026-52732 | 5.3 medium | 1.0% | no CPE yet | ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, one unauthenticated P2P peer can monopolize all 25 MAX_INBOUND_CONCURRENCY slots in Zebra's inbound mempool download and verification pipeline. In zebrad/src/components/mempool/downloads.rs, the bounded queue was shared globally without per-peer accounting, while peer identity was not carried through Gossip and FullQueue responses were mapped to Response::Nil instead of reaching overload disconnection handling. An attacker can advertise fake transaction identifiers and remain silent so each task holds a slot until TRANSACTION_DOWNLOAD_TIMEOUT, then periodically refill the queue as slots expire. While saturated, honest peer transactions and local sendrawtransaction requests are rejected with MempoolError::FullQueue, although block validation and synchronization continue. This issue is fixed in version 4.5.0. | 22 Oct |
| CVE-2026-52734 | 5.3 medium | 1.0% | no CPE yet | ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, an unauthenticated P2P peer can cause the mempool download pipeline to retain transactions after verification reaches the outer RATE_LIMIT_DELAY timeout. In zebrad/src/components/mempool/downloads.rs, Downloads::poll_next removed cancel_handles entries after success and ordinary verification errors, but tokio::time::error::Elapsed did not carry the UnminedTxId needed to remove the timed-out entry. Each retained cancel_handles entry could hold a full Gossip::Tx(UnminedTx), while normal mined-transaction cleanup could not match attacker transactions and no periodic garbage collection or count cap existed. Sustained traffic therefore caused monotonic memory growth until swap pressure degraded the node or the operating system terminated the zebrad process for exhausting memory. This issue is fixed in version 4.5.0. | 22 Oct |
| CVE-2026-41583 | 9.3 critical | 0.00% | zfnd, zebra-script, zebrad | ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-script version 5.0.2, after a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes. In a similar vein, for V4 transactions, Zebra mistakenly used the "canonical" hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split. This issue has been patched in zebrad version 4.3.1 and zebra-script version 5.0.2. | Mon 26 Oct |
| CVE-2026-44499 | 8.7 high | 0.00% | no CPE yet | ZEBRA is a Zcash node written entirely in Rust. Prior to version 4.4.0, 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. This issue has been patched in version 4.4.0. | Mon 26 Oct |
| CVE-2026-109363 | 8.7 high | 0.00% | no CPE yet | ZcashFoundation Zebra 6.4.0 before 6.4.2 parses version 6 transactions carrying a pre-NU6.3 consensus branch ID, but the size computation during UnminedTx construction treats re-serialization of the Orchard bundle as infallible, so the resulting error trips an expect that aborts zebrad. Unauthenticated peers can send a single pre-handshake tx message to crash the node, and can repeat this after each restart. | 15 Oct |
| CVE-2026-40880 | 7.2 high | 0.00% | zfnd, zebra-consensus, zebrad | ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and zebra-consensus version 5.0.2, a logic error in Zebra's transaction verification cache could allow a malicious miner to induce a consensus split. By carefully submitting a transaction that is valid for height H+1 but invalid for H+2 and then mining that transaction in a block at height H+2, a miner could cause vulnerable Zebra nodes to accept an invalid block, leading to a consensus split from the rest of the Zcash network. This vulnerability is fixed in zebrad version 4.3.1 and zebra-consensus version 5.0.2. | Mon 26 Oct |
| CVE-2026-109364 | 6.9 medium | 0.00% | no CPE yet | Zebra 2.3.0 before 6.4.0 contains a protection mechanism failure that allows unauthenticated peers to evade bans because bans and misbehavior scores are keyed on exact IP addresses. Attackers can reconnect from fresh IPv6 addresses in their /64 allocation or flush the 20,000-entry FIFO ban list to restore access for banned peers. | 15 Oct |
| CVE-2026-104436 | 6.3 medium | 0.00% | zcashfoundation, zebra, zebra-chain | Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance. | Thu 29 Oct |
| CVE-2026-109366 | 6.3 medium | 0.00% | no CPE yet | Zebra before 6.4.0 contains an improper integrity validation vulnerability in the inbound gossip download path that allows unauthenticated peers to force dropping of new blocks without penalty. Attackers can serve a real block with a coinbase scriptSig rewritten to height 1, which keeps the ZIP-244 block hash, triggering a behind-tip drop before consensus validation and delaying tip discovery for mining backends. | Mon 26 Oct |
| CVE-2026-40881 | 6.3 medium | 0.00% | zfnd, zebra-network, zebrad | ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.0 and zebra-network version 5.0.1, when deserializing addr or addrv2 messages, which contain vectors of addresses, Zebra would fully deserialize them up to a maximum length (over 233,000) that was derived from the 2 MiB message size limit. This is much larger than the actual limit of 1,000 messages from the specification. Zebra would eventually check that limit but, at that point, the memory for the larger vector was already allocated. An attacker could cause out-of-memory aborts in Zebra by sending multiple such messages over different connections. This vulnerability is fixed in zebrad version 4.3.0 and zebra-network version 5.0.1. | Mon 26 Oct |
| CVE-2026-109365 | 6.3 medium | 0.00% | no CPE yet | Zebra before 6.4.0 contains an uncontrolled resource consumption vulnerability that allows unauthenticated peers to force full proof verification by serving forged block bodies with valid header hashes. Attackers can flip authorizing-only bytes such as a coinbase scriptSig, wasting Sapling, Orchard, and Ironwood proof verification without penalty and stalling sync for 67 seconds. | 15 Oct |
| CVE-2026-44500 | 5.3 medium | 0.00% | zfnd, zebra-chain, zebra-network, zebrad | ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0, prior to zebra-chain version 7.0.0, and prior to zebra-network version 6.0.0, 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. This issue has been patched in zebrad version 4.4.0, zebra-chain version 7.0.0, and zebra-network version 6.0.0. | Mon 26 Oct |
15 of 15
Download these 15 as CSV · subscribe to this list.
EPSS scores: 2026-10-31. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.