CVE-2026-19735
What it is
The RFC 6528 initial-sequence-number implementation in subsys/net/ip/tcp.c derived every TCP ISN from SHA-256(unique_key || four-tuple) plus a uptime-derived offset, where unique_key is a 128-bit secret filled once by sys_csrand_get(). The return value of that call was discarded and the once guard was latched to true even when the call failed. Because sys_csrand_get() leaves the destination buffer untouched on failure (it deliberately propagates the entropy-driver error rather than filling the buffer), a single failed call left unique_key as its all-zero BSS content for the remainder of the boot, with no retry, no log message and no fallback. A failure of the cryptographic random source is required to reach the weak state — for example -ENODEV/-EIO from the entropy driver in subsys/random/random_entropy_device.c (the in-tree comment notes that the hardware RNG "might still be gathering entropy during early boot situations"), or psa_generate_random() failing in subsys/random/random_psa.c when PSA crypto is not initialised or is backed by a Bluetooth-HCI entropy device that is not yet up. The first TCP connection is what triggers key generation, so a remote peer that reaches a listening port immediately after boot, or that can provoke a reboot, has indirect influence over whether generation coincides with that window. tcp_init_isn() is called for every passive open in tcp_conn_new() and every active open in net_tcp_connect(), so the poisoned key governs all TCP connections for that boot. With an all-zero key the ISN becomes a public function of the connection four-tuple plus a device-wide time offset. An off-path attacker can compute the hash term offline for any four-tuple and recover the shared time offset from a single observed ISN, after which the ISN the device will pick for other four-tuples is predictable. That defeats exactly the protection RFC 6528 provides: blind TCP connection spoofing against peers that trust the source address, and blind data injection into or reset of connections whose four-tuple can be guessed. Devices whose entropy source never errors were never in the weak state. The fix moves key generation into a single guarded helper that latches only on success, logs the error otherwise, and makes tcp_init_isn() fall back to sys_rand32_get() — the behaviour already used when CONFIG_NET_TCP_ISN_RFC6528 is disabled — instead of hashing with a known-constant key.
At a glance
- Exploitability
- Can be exploited over the network without logging in. Limited direct impact.
- Exploit odds
- 0.2% chance of exploitation in the next 30 days (EPSS).
- Fix
- A patch, advisory or fixed version is referenced. Upgrade or apply it.
Timeline
- PublishedDisclosed publicly on CVE.org and NVD
- Last updatedMost recent change to the record
Why it ranks here
- Exploited in the wild: no, CISA does not list it.
- Exploit odds: 0.2% in the next 30 days (EPSS).
- Severity: 4.8 MEDIUM (CVSS).
- Fix: a patch or advisory is linked.
Details
- Published
- Last modified
- Exploit probability
- 0.2% · EPSS, next 30 days
- Weakness
- CWE-330
- Record status
- Awaiting Analysis
Attack profile CVSS 3.1 · 4.8
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- Low
- Availability
- None
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Is it in your code?
Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.
Read https://cve-list.com/agent/cve/CVE-2026-19735.md and follow it. Check whether this project is affected by CVE-2026-19735. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.
Fix and advisories
- https://github.com/zephyrproject-rtos/zephyr/commit/700888e3ecff8474f4fe7dfa8782b8869053222b
- https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-37mc-2q9v-fp64