Skip to main content
Vulnerability Database/CVE-2026-19735

CVE-2026-19735: TCP ISN Information Disclosure Vulnerability

CVE-2026-19735 is an information disclosure flaw in TCP ISN generation that allows attackers to predict sequence numbers when entropy initialization fails. This article covers the technical details, impact, and mitigation strategies.

Published:

CVE-2026-19735 Overview

CVE-2026-19735 is a weak random number generation flaw [CWE-330] in the Zephyr RTOS TCP stack. The RFC 6528 initial sequence number (ISN) implementation in subsys/net/ip/tcp.c discards the return value of sys_csrand_get() when seeding its 128-bit secret key. If the entropy driver returns an error, the destination buffer is left as all-zero BSS content, and the once-only guard still latches to true. Every TCP ISN for the remainder of the boot is then derived from a known-constant key, making ISNs predictable from the connection four-tuple.

Critical Impact

An off-path attacker can predict TCP ISNs for all connections on an affected device, enabling blind connection spoofing, data injection, and reset attacks against TCP peers that trust source addresses.

Affected Products

  • Zephyr RTOS builds using CONFIG_NET_TCP_ISN_RFC6528
  • Devices whose entropy source can return -ENODEV or -EIO during early boot
  • Zephyr targets backed by psa_generate_random() where PSA crypto or the Bluetooth-HCI entropy device is not yet initialised

Discovery Timeline

  • 2026-10-11 - CVE-2026-19735 published to NVD
  • 2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-19735

Vulnerability Analysis

The Zephyr TCP stack computes each ISN as SHA-256(unique_key || four-tuple) plus an uptime-derived offset. The 128-bit unique_key is intended to be filled once by sys_csrand_get(). The patched code shows the original call ignored the return value and marked the key as initialised regardless of success.

Because sys_csrand_get() leaves the destination buffer untouched on failure, a single failed call leaves unique_key as its all-zero BSS content for the rest of the boot. No retry, log, or fallback occurs. The first TCP connection triggers key generation, so a remote peer reaching a listening port immediately after boot has indirect influence over whether generation hits the weak window.

With a zero key, the ISN becomes a public function of the four-tuple plus a device-wide time offset. An attacker computes the hash offline for any four-tuple, recovers the shared time offset from a single observed ISN, then predicts every subsequent ISN the device will issue.

Root Cause

The root cause is unchecked cryptographic API failure in tcp_init_isn(). The function treated sys_csrand_get() as infallible and latched the one-time initialisation flag unconditionally. Entropy driver errors such as -ENODEV from subsys/random/random_entropy_device.c, or psa_generate_random() failures in subsys/random/random_psa.c, silently poison the ISN secret for the remainder of the boot.

Attack Vector

Exploitation requires network reachability to the target device and a prior entropy failure during boot. An off-path attacker observes one ISN from any TCP exchange, solves for the device-wide time offset, then predicts ISNs for arbitrary four-tuples. This defeats the RFC 6528 protection against blind TCP spoofing, blind data injection, and blind connection reset.

c
 }
 
 static uint8_t unique_key[16]; /* MD5 128 bits as described in RFC6528 */
+static bool unique_key_valid;
+
+/* The secret key must not be known to an off-path attacker, otherwise the
+ * ISN can be computed from the four-tuple alone. RFC 6528 ch 3
+ */
+static int tcp_init_isn_key(void)
+{
+	int ret = 0;
+
+	k_mutex_lock(&tcp_lock, K_FOREVER);
+
+	if (!unique_key_valid) {
+		ret = sys_csrand_get(unique_key, sizeof(unique_key));
+		if (ret == 0) {
+			unique_key_valid = true;
+		} else {
+			NET_ERR("Cannot generate secret key for TCP ISN");
+		}
+	}
+
+	k_mutex_unlock(&tcp_lock);
+
+	return ret;
+}
 
 static uint32_t tcpv6_init_isn(struct net_in6_addr *saddr,
 			       struct net_in6_addr *daddr,

Source: Zephyr Project patch 700888e3. The patch introduces a unique_key_valid flag that only latches on a successful sys_csrand_get() call and logs an error on failure, allowing tcp_init_isn() to fall back to sys_rand32_get().

Detection Methods for CVE-2026-19735

Indicators of Compromise

  • Unexpected TCP RST floods or injected payloads on connections to Zephyr-based devices with no corresponding on-path traffic.
  • Boot-time entropy driver errors in device logs that precede any TCP listener coming online.
  • Observed ISNs on sequential connections that correlate linearly with device uptime after fixing the four-tuple.

Detection Strategies

  • Capture multiple TCP SYN or SYN-ACK packets from the device across distinct four-tuples and test whether ISNs are predictable under a zero-key RFC 6528 model.
  • Audit firmware builds for CONFIG_NET_TCP_ISN_RFC6528 combined with entropy sources that can return -ENODEV or -EIO at boot.
  • Review bootloader and early-init logs for suppressed sys_csrand_get() or psa_generate_random() failures.

Monitoring Recommendations

  • Monitor network segments containing embedded Zephyr devices for anomalous TCP sessions with mismatched sequence state.
  • Alert on repeated reboots of IoT devices that could coincide with the entropy-failure window.
  • Track firmware inventory to confirm patched Zephyr versions are deployed across the fleet.

How to Mitigate CVE-2026-19735

Immediate Actions Required

  • Apply the upstream Zephyr fix from commit 700888e3ecff8474f4fe7dfa8782b8869053222b and rebuild affected firmware images.
  • Validate that the entropy driver on each target is operational before the networking subsystem accepts connections.
  • Restrict exposure of Zephyr TCP listeners to trusted network segments until patched firmware is deployed.

Patch Information

The fix is tracked in GHSA-37mc-2q9v-fp64. It moves key generation into a guarded helper tcp_init_isn_key() that only latches unique_key_valid on success, emits a NET_ERR on failure, and causes tcp_init_isn() to fall back to sys_rand32_get() instead of hashing with a known-constant key.

Workarounds

  • Disable CONFIG_NET_TCP_ISN_RFC6528 so the stack uses the sys_rand32_get() path already used by non-RFC-6528 builds.
  • Harden the entropy source so it cannot return errors during boot, for example by delaying network stack initialisation until the hardware RNG reports ready.
  • Place affected devices behind network equipment that enforces strict TCP state tracking and rejects spoofed source addresses.
bash
# Confirm the vulnerable configuration in a Zephyr build
grep -R "CONFIG_NET_TCP_ISN_RFC6528" build/zephyr/.config

# Temporary mitigation: disable RFC 6528 ISN generation in prj.conf
echo "CONFIG_NET_TCP_ISN_RFC6528=n" >> prj.conf
west build -p auto -b <board>

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.