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.

zfnd

ZEBRA is a Zcash node written entirely in Rust. Prior to version 4.4.0, Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAX_BLOCK_SIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not. This issue has been patched in version 4.4.0.

zfnd

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0 and prior to zebra-script version 6.0.0, the fix for CVE-2026-41583 introduced a separate issue due to insufficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes. This issue has been patched in zebrad version 4.4.0 and zebra-script version 6.0.0.

zfnd

ZEBRA is a Zcash node written entirely in Rust. From zebrad versions 2.2.0 to before 4.3.1 and from zebra-rpc versions 1.0.0-beta.45 to before 6.0.2, a vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response. This issue has been patched in zebrad version 4.3.1 and zebra-rpc version 6.0.2.

zfnd

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-chain version 6.0.2, Orchard transactions contain a rk field which is a randomized validating key and also an elliptic curve point. The Zcash specification allows the field to be the identity (a "zero" value), however, the orchard crate which is used to verify Orchard proofs would panic when fed a rk with the identity value. Thus an attacker could send a crafted transaction that would make a Zebra node crash. This issue has been patched in zebrad version 4.3.1 and zebra-chain version 6.0.2.

zfnd

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.

zfnd

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.

zfnd

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.

zfnd

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.0 and zebra-consensus version 5.0.1, a logic error in Zebra's transaction verification cache could allow a malicious miner to induce a consensus split. By matching a valid transaction's txid while providing invalid authorization data, 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 would not allow invalid transactions to be accepted but could result in a consensus split between vulnerable Zebra nodes and invulnerable Zebra and Zcashd nodes. This issue has been patched in zebrad version 4.3.0 and zebra-consensus version 5.0.1.

zfnd

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.0 and zebra-chain version 6.0.1, a vulnerability in Zebra's transaction processing logic allows a remote, unauthenticated attacker to cause a Zebra node to panic (crash). This is triggered by sending a specially crafted V5 transaction that passes initial deserialization but fails during transaction ID calculation. This issue has been patched in zebrad version 4.3.0 and zebra-chain version 6.0.1.

zfnd

IDC SFX2100 Satellite Receiver firmware ships with multiple daemon configuration files for routing components (e.g., zebra, bgpd, ospfd, and ripd) that are owned by root but world-readable. The configuration files (e.g., zebra.conf, bgpd.conf, ospfd.conf, ripd.conf) contain hardcoded or otherwise insecure plaintext passwords (including “enable”/privileged-mode credentials). A remote actor is able to abuse the reuse/hardcoded nature of these credentials to further access other systems in the network, gain a foothold on the satellite receiver or potentially locally privilege escalate.

datacast

A vulnerability classified as problematic was found in Zebra ZTC GK420d 1.0. This vulnerability affects unknown code of the file /settings of the component Alert Setup Page. The manipulation of the argument Address leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-258868. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability of authentication bypass has been found on a Zebra Technologies ZTC ZT410-203dpi ZPL printer. This vulnerability allows an attacker that is in the same network as the printer, to change the username and password for the Web Page by sending a specially crafted POST request to the setvarsResults.cgi file. For this vulnerability to be exploitable, the printers protected mode must be disabled.

zebra

Two OS command injection vulnerabilities exist in the zebra vlan_name functionality of Milesight UR32L v32.3.0.5. A specially crafted network request can lead to command execution. An attacker can send a network request to trigger these vulnerabilities.This command injection is in the code branch that manages a new vlan configuration.

milesight

Two OS command injection vulnerabilities exist in the zebra vlan_name functionality of Milesight UR32L v32.3.0.5. A specially crafted network request can lead to command execution. An attacker can send a network request to trigger these vulnerabilities.This command injection is in the code branch that manages an already existing vlan configuration.

milesight

A stack-based buffer overflow vulnerability exists in the libzebra.so.0.0.0 security_decrypt_password functionality of Milesight UR32L v32.3.0.5. A specially crafted HTTP request can lead to a buffer overflow. An authenticated attacker can send an HTTP request to trigger this vulnerability.

milesight

An os command injection vulnerability exists in the libzebra.so change_hostname functionality of Milesight UR32L v32.3.0.5. A specially-crafted network packets can lead to command execution. An attacker can send a sequence of requests to trigger this vulnerability.

milesight

An OS command injection vulnerability exists in the libzebra.so bridge_group functionality of Milesight UR32L v32.3.0.5. A specially crafted network packet can lead to command execution. An attacker can send a sequence of requests to trigger this vulnerability.

milesight

An issue was discovered in Zebra Enterprise Home Screen 4.1.19. The device allows the administrator to lock some communication channels (wireless and SD card) but it is still possible to use a physical connection (Ethernet cable) without restriction.

zebra

An issue was discovered in Zebra Enterprise Home Screen 4.1.19. By using the embedded Google Chrome application, it is possible to install an unauthorized application via a downloaded APK.

zebra

An issue was discovered in Zebra Enterprise Home Screen 4.1.19. The Gboard used by different applications can be used to launch and use several other applications that are restricted by the admin.

zebra

Quagga Services on D-Link DIR-2640 less than or equal to version 1.11B02 are affected by an absolute path traversal vulnerability that allows a remote, authenticated attacker to set an arbitrary file on the router's filesystem as the log file used by either Quagga service (zebra or ripd). Subsequent log messages will be appended to the file, prefixed by a timestamp and some logging metadata. Remote code execution can be achieved by using this vulnerability to append to a shell script on the router's filesystem, and then awaiting or triggering the execution of that script. A remote, unauthenticated root shell can easily be obtained on the device in this fashion.

dlink