CVE-2026-19742 in Zephyr
Summary
by MITRE • 10/26/2026
The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (gen_stable_iid() in subsys/net/ip/ipv6.c) and RFC 8981 temporary interface identifiers (gen_temporary_iid() in subsys/net/ip/ipv6_pe.c) with sys_rand_get(). That API is documented as not cryptographically secure, while both RFCs require this key to be an unpredictable random value of at least 128 bits — the unpredictability of every generated IID rests entirely on it.
Depending on the platform, sys_rand_get() resolves either to a hardware entropy device or, on boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, to the non-cryptographic xoshiro128++ generator in subsys/random/random_xoshiro128.c, which keeps a single global 128-bit state shared with every other sys_rand_get() consumer. Many of those consumers put their output directly on the wire (ephemeral source ports, DNS query IDs, CoAP message IDs and tokens, DHCPv6 transaction IDs, WebSocket masking keys), and the xoshiro state transition is invertible, so an observer of a device's traffic can recover the generator state and reconstruct the IID secret key. Additionally, with the entropy-device backend sys_rand_get() silently falls back to k_cycle_get_32() samples when the entropy driver fails, and returns no error, so the key could be derived from the cycle counter without the caller noticing.
With the key known, stable IIDs become directly computable for any prefix (the remaining HMAC inputs — prefix, interface index, interface name, DAD counter — are guessable), and temporary IIDs become linkable after a cheap search over the mixed-in k_uptime_get_32() value. This defeats the properties both features exist to provide: an attacker can track a device across networks and prefixes, and can predict its address inside a /64 without scanning, removing the usual barrier to directly targeting the host. There is no memory-safety, integrity, or availability impact.
The fix generates the key with sys_csrand_get() and aborts IID generation with -EIO when no cryptographic randomness is available, instead of silently deriving addresses from a predictable key. Both CONFIG_NET_IPV6_IID_STABLE and CONFIG_NET_IPV6_PE are experimental and disabled by default; builds using CONFIG_TEST_RANDOM_GENERATOR remain predictable by design, as sys_csrand_get() is deliberately routed back to the test generator there.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability resides in the IPv6 stack implementation within Zephyr RTOS, specifically affecting the generation of both RFC 7217 stable interface identifiers and RFC 8981 temporary interface identifiers. The core technical flaw is that these critical cryptographic secrets were derived using sys_rand_get(), an API explicitly documented as non-cryptographically secure. According to RFC standards, the secret keys used for generating these identifiers must be unpredictable random values of at least one hundred twenty-eight bits. By relying on a pseudo-random number generator with predictable state transitions or low-entropy sources, the system fails to meet this fundamental security requirement, thereby compromising the privacy and anonymity features that stable and temporary IPv6 addresses are designed to provide.
The operational impact stems from how sys_rand_get() resolves depending on the platform configuration. On many boards where CONFIG_ENTROPY_NEEDS_PRNG is enabled, the function falls back to the xoshiro128++ generator found in subsys/random/random_xoshiro128.c. This generator maintains a single global one hundred twenty-eight-bit state that is shared among all consumers of sys_rand_get(). Because many other network protocols such as ephemeral source ports, DNS query IDs, CoAP message tokens, DHCPv6 transaction IDs, and WebSocket masking keys also utilize this same random number generator for their outputs, an attacker observing the device's network traffic can collect these public values. Given that the xoshiro128++ state transition is mathematically invertible, the observer can reverse-engineer the internal state of the generator. Once the global state is recovered, the secret key used for IPv6 interface identifier generation can be reconstructed with high certainty. Furthermore, when using an entropy device backend, sys_rand_get() silently falls back to samples from k_cycle_get_32 if the hardware entropy source fails or provides insufficient randomness. This fallback occurs without returning an error code, meaning the system continues to generate addresses based on predictable cycle counter values rather than true random data, a flaw that remains invisible to standard application logic.
The consequences of this vulnerability are severe regarding network privacy and host security. With knowledge of the secret key, stable interface identifiers become directly computable for any given prefix because the remaining inputs such as the IPv6 prefix, interface index, interface name, and duplicate address detection counter are either static or easily guessable by an attacker on the local link. Similarly, temporary interface identifiers can be linked to specific devices through a relatively cheap search over the mixed-in k_uptime_get_32 value used in their generation algorithm. This effectively defeats the primary purpose of these features, which is to prevent device tracking across different networks and prefixes. An attacker no longer needs to perform slow network scanning to discover active hosts; instead, they can predict valid IPv6 addresses within a subnet with high accuracy. This removes the traditional barrier that forces attackers to scan for targets, allowing them to directly target specific devices without detection through address enumeration techniques.
From a classification perspective, this vulnerability aligns with CWE-330: Use of Insufficiently Random Values and CWE-295: Improper Certificate Validation in terms of relying on weak randomness for security-critical operations. In the context of the MITRE ATT&CK framework, this relates to techniques involving network discovery and potentially reconnaissance phase activities where an adversary uses passive observation to infer internal network structures or track specific endpoints over time. The lack of unpredictability allows for long-term tracking which is a significant privacy violation in modern networking environments that rely on randomized identifiers for anonymity.
The mitigation implemented addresses these issues by replacing the insecure sys_rand_get() calls with sys_csrand_get(), which provides cryptographically secure random numbers suitable for generating secret keys. Additionally, the fix introduces strict error handling; if no cryptographic randomness is available during key generation, the system now aborts the interface identifier creation process and returns an I/O error rather than proceeding with a predictable or weakly derived key. This ensures that devices do not operate under false assumptions of security when entropy sources are compromised. It is important to note that this vulnerability primarily affects configurations where CONFIG_NET_IPV6_IID_STABLE and CONFIG_NET_IPV6_PE are enabled, as these features are experimental and disabled by default in most standard builds. Furthermore, development environments using CONFIG_TEST_RANDOM_GENERATOR will remain predictable by design since the cryptographic random generator is deliberately routed back to a test-specific pseudo-random implementation for reproducibility purposes during testing phases.