Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Skip to content
Check your stack
CVE-2026-19735

Predictable TCP initial sequence numbers when the RFC 6528 secret key generation fails silently in the Zephyr TCP stack

Products / packages zephyrproject zephyr

Published

Share

Severity and exploitation

Not in CISA KEV

KEV coverage does not rule out exploitation.

KEV checked 05/11/2026, 10:05:32 UTC
zephyr · CVSS:3.1 · 4.8
Assessment vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Severity

medium4.8

CVSS measures technical severity, not the likelihood of an attack.

Known exploitation

Not listed in the checked CISA KEV catalog

Absence from CISA KEV does not rule out attacks.

Public exploit

Not established by this record

Missing evidence does not mean no public exploit exists.

Remediation

Fix status not established

No structured fix or guidance is available here. Check the latest publisher advisory.

What this means

Zephyr TCP stack versions 3.7.0 to 4.3.2 and 4.4.0 to 4.5.0 have a predictable TCP initial sequence number when the RFC 6528 secret key generation fails silently, allowing an off-path attacker to compute the hash term offline and recover the shared time offset. A failure of the cryptographic random source is required to reach the weak state. This defeats the protection against blind TCP connection spoofing and blind data injection.

Summarized by @cf/meta/llama-3.3-70b-instruct-fp8-fast. Verify details against the original sources.

Attack conditions

No attack-condition excerpt has been identified here. Review the full source description and references for authentication, network access, and configuration requirements.

Review supporting sources →

Affected versions

Check the exact model, release, and any platform requirements against your installation.

zephyrproject · zephyr

zephyr

2 ranges

Compare with this publisher’s ranges. This does not inspect your installation.

affected

3.7.0 → before 4.3.2

semver versions

4.4.0 → before 4.5.0

semver versions

unaffected

unknown

Other versions: unaffected

Automatic dependency matching is unavailable for this record. Use the product evidence and publisher’s instructions to check your installation.

What to do

Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.

No structured fix or remediation guidance is available here. Check the full source description and vendor’s latest advisory for a patch or workaround; do not assume another version is safe.

cve.new guidance unless attributed to a publisher. This page does not inspect your installation.

Public exploit evidence

No public exploit reference is identified in the imported evidence. This is not a claim that no exploit exists.

Original source description

Read the full publisher description

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.

References

2 sources

Inside the record

Evidence available

Package identity · not supplied
Version evidence
Remediation guidance · not supplied
Weakness classification
Additional publishers

Describes the evidence in this view, not whether the product is safe.

Original records

CVE-2026-19735

View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.

cve.new JSON →

Underlying weaknesses

The source’s classification of what caused the vulnerability.

Contributing organizations · 2
zephyr

Assigning organization

2026-11-04
CISA-ADP

Additional data publisher

2026-10-16

Timeline

All times UTC
  1. Advisory published

    Publication date supplied by the source.

  2. Source updated

    Latest modification date supplied by the source.

  3. Last imported by cve.new

    Latest catalog import, not the date we first saw this advisory.

What changed

Follow changes
No substantive changes have been recorded here yet. History starts when cve.new observes a change after tracking is enabled; earlier edits are not reconstructed.

Large field values are marked as truncated previews. Original source snapshots remain retained.