{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/zebrad--4.4.1/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["zebrad \u003c= 4.4.1","zebra-state \u003c= 6.0.0"],"_cs_severities":["medium"],"_cs_tags":["blockchain","denial-of-service","network","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Zebra"],"content_html":"\u003cp\u003eA high-severity vulnerability, CVE-2026-52736, affects Zebra's \u003ccode\u003ezebrad\u003c/code\u003e blockchain nodes, specifically versions up to \u003ccode\u003ev4.4.1\u003c/code\u003e, as well as \u003ccode\u003ezebra-state\u003c/code\u003e up to \u003ccode\u003ev6.0.0\u003c/code\u003e. This flaw allows a remote, unauthenticated attacker to conduct a denial-of-service attack against a target node by exploiting a caching issue in how \u003ccode\u003ezebrad\u003c/code\u003e handles block hashes. By leveraging coinbase scriptSig malleability (ZIP-244 \u003ccode\u003etxid_v5\u003c/code\u003e) to create a poisoned block body with the same header hash as a legitimate canonical block, an attacker can cause the node to cache the hash and then reject the actual valid block as a duplicate. This leads to the node permanently stalling at a specific block height, diverging from the network tip, and preventing downstream services like lightwalletd, wallets, and explorers from advancing. The attack requires winning a propagation race to deliver the poisoned block before honest peers deliver the canonical one, which a well-positioned attacker can reliably achieve.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker observes a new block header from any peer on the network.\u003c/li\u003e\n\u003cli\u003eAttacker constructs a poisoned block body that has an identical header hash to the observed block, achieved by mutating the coinbase \u003ccode\u003escriptSig\u003c/code\u003e extra-data section.\u003c/li\u003e\n\u003cli\u003eAttacker advertises the hash of this specially crafted block to the target Zebra node via an \u003ccode\u003einv\u003c/code\u003e (inventory) message over the P2P network.\u003c/li\u003e\n\u003cli\u003eThe target Zebra node requests the advertised block via a \u003ccode\u003egetdata\u003c/code\u003e message, and the attacker serves the poisoned body.\u003c/li\u003e\n\u003cli\u003eZebra adds the block hash to its \u003ccode\u003enon_finalized_block_write_sent_hashes\u003c/code\u003e cache before completing contextual validation of the block body.\u003c/li\u003e\n\u003cli\u003eThe write task within Zebra subsequently rejects the poisoned body due to an \u003ccode\u003eauth_data_root\u003c/code\u003e mismatch (specifically, \u003ccode\u003eblock_commitment_is_valid_for_chain_history\u003c/code\u003e fails), but the hash is not removed from the \u003ccode\u003enon_finalized_block_write_sent_hashes\u003c/code\u003e cache.\u003c/li\u003e\n\u003cli\u003eWhen the valid, canonical block later arrives from honest peers or an RPC connection, Zebra's \u003ccode\u003equeue_and_commit_to_non_finalized_state\u003c/code\u003e function sees the hash already in the cache and erroneously treats it as a duplicate, returning \u003ccode\u003eKnownBlock::WriteChannel\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe target Zebra node fails to advance past the affected block height (N-1), becoming permanently stalled until a manual restart (which clears the in-memory cache) or a rare chain reorg event occurs.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-52736 leads to a permanent denial of service for the targeted Zebra node, causing it to diverge from the main blockchain network. This renders the node unable to process new blocks, effectively stalling its operation. Downstream services and applications that rely on the affected node, such as lightwallets, block explorers, and potentially mining infrastructure, will experience service degradation or complete outages due to an inability to access up-to-date blockchain data. Recovery from this attack typically requires manual intervention, specifically restarting the \u003ccode\u003ezebrad\u003c/code\u003e process to clear the in-memory sent-hash cache, or waiting for an unlikely chain reorg at the stalled height. There is no information on specific victim counts or sectors, but any organization operating vulnerable Zebra nodes is at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately patch all \u003ccode\u003ezebrad\u003c/code\u003e nodes to version \u003ccode\u003ev4.4.2\u003c/code\u003e or later to remediate CVE-2026-52736, which includes a fix for removing stale entries from the sent-hash cache.\u003c/li\u003e\n\u003cli\u003eWhile not a complete solution for CVE-2026-52736, consider reducing the \u003ccode\u003enetwork.peerset_initial_target_size\u003c/code\u003e configuration to narrow the attack surface by limiting the number of inbound P2P connections.\u003c/li\u003e\n\u003cli\u003eBe prepared to restart \u003ccode\u003ezebrad\u003c/code\u003e nodes if they stall at a specific block height, as this is the primary recovery mechanism to clear the in-memory \u003ccode\u003enon_finalized_block_write_sent_hashes\u003c/code\u003e cache.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-03T11:34:34Z","date_published":"2026-07-03T11:34:34Z","id":"https://feed.craftedsignal.io/briefs/2026-07-zebra-block-suppression/","summary":"A remote unauthenticated attacker can exploit CVE-2026-52736 in Zebra's `zebrad` node (versions up to and including `v4.4.1`) to permanently stall a targeted blockchain node by poisoning its sent-hash cache, leading to a denial of service.","title":"Zebra Block Suppression Vulnerability (CVE-2026-52736) via P2P Body Poisoning","url":"https://feed.craftedsignal.io/briefs/2026-07-zebra-block-suppression/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["zebrad \u003c= 4.4.1","zebra-network \u003c= 6.0.0"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","vulnerability","linux","rust"],"_cs_type":"advisory","_cs_vendors":["Zebra"],"content_html":"\u003cp\u003eA high-severity vulnerability, CVE-2026-52829, affects Zebra \u003ccode\u003ezebrad\u003c/code\u003e nodes up to version \u003ccode\u003e4.4.1\u003c/code\u003e and \u003ccode\u003ezebra-network\u003c/code\u003e up to \u003ccode\u003e6.0.0\u003c/code\u003e, potentially allowing a remote denial-of-service. An address normalization mismatch occurs when a peer connects via IPv4 to a dual-stack IPv6 listener (the default \u003ccode\u003e[::]\u003c/code\u003e address on Linux with \u003ccode\u003enet.ipv6.bindv6only=0\u003c/code\u003e), and subsequently triggers a mempool misbehavior penalty by advertising an invalid transaction. The \u003ccode\u003ezebrad\u003c/code\u003e software stores the peer's address in a canonical IPv4 form during the initial handshake, but later attempts to update its misbehavior status using the raw IPv4-mapped IPv6 address from the transient socket. This inconsistency leads to a deterministic assertion panic after a 30-second delay, terminating the \u003ccode\u003ezebrad\u003c/code\u003e process. This issue is critical for any \u003ccode\u003ezebrad\u003c/code\u003e node synchronized near the chain tip in a production environment as it enables persistent downtime.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker initiates an IPv4 connection to a vulnerable \u003ccode\u003ezebrad\u003c/code\u003e node listening on a dual-stack IPv6 address (e.g., \u003ccode\u003e[::]\u003c/code\u003e on Linux with \u003ccode\u003enet.ipv6.bindv6only=0\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eDuring the P2P handshake, the \u003ccode\u003ezebrad\u003c/code\u003e node's address book canonicalizes the IPv4-mapped IPv6 address (e.g., \u003ccode\u003e::ffff:127.0.0.1\u003c/code\u003e) to a plain IPv4 address (e.g., \u003ccode\u003e127.0.0.1\u003c/code\u003e) and stores it.\u003c/li\u003e\n\u003cli\u003eThe attacker advertises an invalid mempool transaction, such as a coinbase transaction, which the \u003ccode\u003ezebrad\u003c/code\u003e node attempts to download.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ezebrad\u003c/code\u003e node identifies the transaction as invalid and queues a misbehavior penalty for the peer, forwarding the raw IPv4-mapped IPv6 transient socket address.\u003c/li\u003e\n\u003cli\u003eAfter a 30-second batch flush, the address book attempts to apply the misbehavior update to the stored peer entry.\u003c/li\u003e\n\u003cli\u003eAn internal assertion (\u003ccode\u003eprevious.addr == self.addr()\u003c/code\u003e) fails because the canonical IPv4 address originally stored does not match the raw IPv4-mapped IPv6 address received for the misbehavior update.\u003c/li\u003e\n\u003cli\u003eThis mismatch triggers a \u003ccode\u003epanic = \u0026quot;abort\u0026quot;\u003c/code\u003e, causing the \u003ccode\u003ezebrad\u003c/code\u003e process to terminate, resulting in a denial-of-service.\u003c/li\u003e\n\u003cli\u003eThe attacker can repeat this sequence after each node restart, leading to persistent downtime.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability allows any remote, unauthenticated peer to deterministically crash a synced Zebra node running in its default Linux dual-stack configuration. The attack requires no mining capability, RPC access, funds, or special privileges, making it highly accessible to adversaries. The \u003ccode\u003ezebrad\u003c/code\u003e process terminates abruptly, leading to service disruption. Since the attack can be repeated reliably after each restart, it poses a significant threat of persistent denial of service, impacting the availability and stability of the Zebra network. Nodes operating as part of critical infrastructure, such as those maintaining blockchain consensus, would face severe operational issues.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePatch CVE-2026-52829 by upgrading \u003ccode\u003ezebrad\u003c/code\u003e to version \u003ccode\u003e4.5.0\u003c/code\u003e or higher immediately.\u003c/li\u003e\n\u003cli\u003eAs a temporary workaround, configure \u003ccode\u003ezebrad\u003c/code\u003e's \u003ccode\u003elisten_addr\u003c/code\u003e to bind only to an IPv4-only address (e.g., \u003ccode\u003e0.0.0.0:8233\u003c/code\u003e) to prevent the use of IPv4-mapped IPv6 representations.\u003c/li\u003e\n\u003cli\u003eAlternatively, on Linux hosts, set the kernel parameter \u003ccode\u003enet.ipv6.bindv6only=1\u003c/code\u003e to disable dual-stack acceptance on IPv6 listeners, thus preventing the vulnerable condition described in CVE-2026-52829.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-03T11:25:58Z","date_published":"2026-07-03T11:25:58Z","id":"https://feed.craftedsignal.io/briefs/2026-07-zebra-mempool-panic/","summary":"A remote unauthenticated peer can exploit an address normalization mismatch in Zebra's address book when connecting via IPv4 to a dual-stack IPv6 listener on a Linux host, by then advertising an invalid mempool transaction, which triggers a deterministic assertion panic after a 30-second delay, causing the `zebrad` process to terminate, leading to persistent denial of service.","title":"Zebra Node Denial-of-Service via IPv4-Mapped Mempool Misbehavior Panic (CVE-2026-52829)","url":"https://feed.craftedsignal.io/briefs/2026-07-zebra-mempool-panic/"}],"language":"en","title":"CraftedSignal Threat Feed - Zebrad \u003c= 4.4.1","version":"https://jsonfeed.org/version/1.1"}