CVE-2026-104429

Executive Summary

CVE-2026-104429 is a resource consumption vulnerability in the Zebra (zebrad) Zcash full-node implementation affecting versions 5.0.0 through 6.0.0-rc.0. According to the NVD description, per-peer mempool admission caps are not enforced for transactions received as direct P2P transaction messages, because these messages are queued without the sending peer recorded as their source. A remote, unauthenticated inbound peer can therefore flood the node with unique transactions, consuming a disproportionate share of mempool admission slots and degrading transaction relay for honest peers.

Technical Analysis

Zebra (zebrad) is the Rust-based full-node implementation of the Zcash protocol. Nodes communicate peer-to-peer over the Zcash P2P protocol using version, inv, getdata, tx, and related messages. The NVD description states that Zebra 5.0.0 before 6.0.0-rc.0 "does not apply its per-peer mempool admission cap to transactions received as direct P2P tx messages, because these are queued without the sending peer recorded as their source."

The core flaw is a resource-management control gap classified as CWE-770 (Allocation of Resources Without Limits or Throttling). Node implementations typically enforce fairness by tracking, per connected peer, how many transactions that peer has contributed to the mempool within a time window. This "per-peer admission cap" limits the number of mempool slots a single peer can occupy. In the affected versions, when a peer sends a transaction as a direct P2P tx message (rather than announcing it via inv/getdata and having the local node solicit it), the queued item does not record the originating peer as its source. Because the source is absent, the admission logic cannot associate the inbound transaction with the sending peer's quota. Consequently the per-peer cap is bypassed: the transaction proceeds through admission without being charged against the sender's allocation.

This creates an asymmetry. Honest peers that fan out legitimate transactions compete for the same finite pool of mempool admission slots, but a single malicious or misbehaving inbound peer can consume many slots without limit. The mempool is a bounded resource; when admission slots fill, the node must evict or refuse transactions. Because the attacker's unsolicited tx messages are not attributable to a peer for throttling purposes, they can crowd out transactions relayed by honest peers.

The CVSS v3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) reflects a network-reachable, low-complexity, unauthenticated attack with no confidentiality or integrity impact and a low availability impact. The attack is not a memory-safety flaw: there is no remote code execution, no key compromise, and no consensus-breaking behavior described. It is a fairness and availability issue affecting transaction relay and mempool hygiene.

Key point for defenders: the vulnerability is specific to transactions delivered as direct P2P tx messages. The absence of the source peer in the queued record is the enabling condition, and the missing enforcement of the per-peer cap is the exploited weakness. No public proof-of-concept, exploit code, or Nuclei template is available, and the CVE has not been added to CISA KEV.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (CWE-770, unbounded/quota-bypassing resource allocation) and the mechanism described in the NVD description.

1. Reconnaissance / target identification. An attacker identifies reachable Zcash nodes running vulnerable Zebra versions. Zcash/Zebra nodes listen on the main P2P port (default 8233 for Zcash mainnet) and advertise their implementation in the version handshake. An adversary can enumerate nodes via open-port scanning (e.g., Shodan port:8233, product:"zebrad") and complete a P2P handshake to confirm the peer is accepting inbound connections.

2. Triggering the flaw. After establishing an inbound P2P connection, the attacker sends transactions as direct P2P tx messages rather than via the announce/request (inv/getdata) flow. Because the affected versions queue these messages without recording the sending peer as the source, the per-peer mempool admission cap is never applied. The attacker can push many unique transactions, each consuming an admission slot that is not charged against any single peer's quota.

3. Payload / execution method (vulnerability-class level). The exploit is volumetric/behavioral rather than code-injection based. The attacker generates a large volume of unique, valid-format transactions and delivers them over one or more P2P connections. The "payload" is the stream of transactions themselves; the enabling condition is the missing source attribution that defeats the cap. No specific function calls, parameters, or code paths are named in the available data, so implementation-level details cannot be asserted.

4. Post-exploitation impact. By occupying a disproportionate share of mempool admission slots, the attacker crowds out transactions relayed by honest peers. Affected nodes may reject or delay legitimate relayed transactions, reducing the quality and timeliness of transaction propagation for those nodes and their downstream peers. The attack is a denial-of-service/degradation scenario, not a compromise. It can be repeated or sustained across multiple connections to maintain pressure on the mempool, degrading relay availability for as long as the attacker sustains the flood.

Impact Assessment

This is an availability-focused vulnerability with low severity per CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L). There is no confidentiality or integrity impact: node keys, wallet material, and consensus state are unaffected, and the flaw does not enable double-spends or consensus divergence. The blast radius is the affected node's mempool and transaction-relay function.

Business and operational impact includes: degraded transaction relay for honest peers connected to the node; potential resource pressure (memory/CPU associated with mempool management) on nodes whose admission slots fill; and reputational/operational friction for node operators and services (wallets, exchanges, miners) that rely on timely inbound relay. Because the per-peer cap is the fairness mechanism that prevents any single peer from monopolizing admission, its bypass enables disproportionate resource consumption (CWE-770).

The low CVSS privilege requirement (PR:N) and network vector (AV:N) mean any party that can reach the P2P port can attempt the attack. Organizations running vulnerable Zebra nodes on public interfaces are most exposed. The limited availability impact (A:L) reflects degradation rather than total outage, and the scope is unchanged (S:U), so the effect is bounded to the vulnerable node's relay behavior rather than cross-component compromise.

Detection Guidance

Detection centers on anomalous inbound P2P transaction volume relative to peer count, mempool composition skew, and connections emitting unusually high rates of direct tx messages. Because no exploit strings or filenames are known, rules must key on protocol behavior and volume anomalies rather than signatures.

Sigma Rule

title: Anomalous Inbound Zcash P2P Transaction Message Volume (CVE-2026-104429)
id: 8f3a1c2e-5b7d-4e21-9a6f-zebra104429
status: experimental
description: Detects periods of abnormally high direct P2P tx message volume to a Zebra node, consistent with per-peer mempool admission cap bypass.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104429
author: valtersit.com
date: 2026-01-01
logsource:
  product: zebra
  service: node
detection:
  selection:
    event_type:
      - 'p2p_tx_received'
      - 'mempool_admission_rejected'
  timeframe: 1m
  condition: selection | count() by src_peer > 500
falsepositives:
  - Legitimate block/tx bursts during network-wide congestion
level: medium
tags:
  - attack.t1499
  - cve.2026.104429

YARA Rule

rule CVE_2026_104429_Zebra_Mempool_Abuse
{
    meta:
        description = "Detects anomalous high-volume P2P tx handling indicators in Zebra logs/memory dumps"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-104429"
        date = "2026-01-01"
        severity = "medium"
    strings:
        $p2p   = "peer" ascii wide nocase
        $txmsg = "tx" ascii wide nocase
        $mempool = "mempool" ascii wide nocase
        $cap   = "admission" ascii wide nocase
    condition:
        (uint16(0) == 0x5A4D or true) and
        all of ($p2p, $mempool) and any of ($txmsg, $cap)
}

Suricata IDS Rule

alert tcp any any -> any 8233 (msg:"CVE-2026-104429 Possible Zebra P2P tx flood - mempool admission abuse"; flow:established,to_server; threshold:type both, track by_src, count 500, seconds 60; classtype:attempted-dos; reference:cve,2026-104429; sid:104429001; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=1m
  [network where network.transport == "tcp" and destination.port == 8233]
  [network where network.transport == "tcp" and destination.port == 8233]

Note: correlate with Zeek/Suricata p2p_tx volume per source.ip; alert when a single source exceeds an admission-slot threshold within 60s.

Splunk SPL Query

index=network sourcetype=zeek_conn OR sourcetype=suricata
| where dest_port=8233
| stats count AS tx_events, dc(src_ip) AS peers BY src_ip
| where tx_events > 500
| table src_ip, tx_events, peers
| sort - tx_events

Wazuh OSSEC Rule

<group name="zebra,p2p,">
  <rule id="104429" level="10">
    <decoded_as>json</decoded_as>
    <field name="event_type">p2p_tx_received</field>
    <description>CVE-2026-104429: High-volume inbound P2P tx messages to Zebra node (possible mempool admission cap bypass)</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations. Restrict the exposed P2P surface by limiting inbound connections and applying firewall/ACL controls so only trusted networks reach the P2P port; deploy connection rate limiting and per-IP connection caps at the network edge. Where operationally feasible, apply mempool admission throttling at the node level (e.g., constraining mempool size and admission timeouts) to reduce the marginal value of slot flooding. Monitor inbound P2P tx rates and peer behavior, and disconnect abnormally high-volume peers.

2. Patch/upgrade steps. No official patch has been verified (confidence 0/4). The affected range is 5.0.0 through 6.0.0-rc.0. While NVD identifies 6.0.0-rc.0 as the first version outside the affected range, this release candidate is not confirmed as a security fix; operators should track the upstream Zebra project's advisories and release notes and upgrade only to a version explicitly designated as fixed once available. Do not assume 6.0.0-rc.0 resolves the issue without vendor confirmation.

3. Long-term hardening. Adopt a mempool admission model that attributes every inbound transaction to its source peer (or to an untrusted-queue that is quota-limited independently), so direct tx messages are capped identically to announce/request flows. Enforce defense-in-depth with connection limits, per-peer quotas, and monitoring. Maintain prompt node-upgrade cadence (N-1) and subscribe to upstream security advisories for Zebra.

References

• NVD — CVE-2026-104429: https://nvd.nist.gov/vuln/detail/CVE-2026-104429
• CWE-770 — Allocation of Resources Without Limits or Throttling: https://cwe.mitre.org/data/definitions/770.html
• MITRE ATT&CK — T1499 Endpoint Denial of Service: https://attack.mitre.org/techniques/T1499/
• Zebra (zebrad) upstream project & release notes: https://github.com/ZcashFoundation/zebra (consult for authoritative patch/version guidance)
• FIRST EPSS — not yet scored at time of writing; CISA KEV — not listed.

No public PoC, exploit code, Nuclei template, or known exploit-in-the-wild/thread-actor campaign is associated with CVE-2026-104429 based on available data.