Zephyr RTOS EUVD-2026-109973

Requires a Zephyr build with CONFIG_NET_IPV6_IID_STABLE (RFC 7217 stable IIDs) or CONFIG_NET_IPV6_PE (RFC 8981 privacy extensions) enabled - both are experimental and disabled by default - AND a platform where sys_rand_get() resolves to the non-cryptographic xoshiro128++ generator (boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, e.g. the NXP MCUX TRNG driver), or an entropy-device backend that silently falls back to k_cycle_get_32() on driver failure. The attacker must also be able to observe the device's network traffic to recover the shared PRNG state from on-wire values (ephemeral ports, DNS/CoAP/DHCPv6 IDs, WebSocket masking keys). Limiting factors: the two vulnerable features are default-off experimental options, the weakness only manifests on the PRNG-backed entropy platform class, and state recovery depends on passive traffic observation. Note that builds using CONFIG_TEST_RANDOM_GENERATOR remain predictable by design even after the fix, since sys_csrand_get() is deliberately routed back to the test generator there.

Signals converge on genuinely low real-world urgency despite a network-exploitable CWE-338 flaw. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N = 3.7, Low) correctly captures the shape: unauthenticated but high-complexity, confidentiality-only. The vuln.today Decision label is 'monitor', which aligns with the low score. No EPSS probability and no SSVC exploitation/automatable/technical-impact values were provided in the input, so those dimensions cannot be weighed - treat their absence as missing data, not as evidence of low risk. The vulnerability is NOT in CISA KEV and there is no confirmed working exploit; the reporter explicitly states 'I have not demonstrated a practical attack' and 'No runtime testing or exploit development was performed', so this is a source-level finding only. Exploitation is further gated by two experimental, default-off build options (CONFIG_NET_IPV6_IID_STABLE, CONFIG_NET_IPV6_PE) AND a platform whose entropy backend is the non-cryptographic xoshiro128++ PRNG, so the condition set is narrow. The impact is privacy/tracking and address-predictability, not memory-safety, integrity, or availability. Net: this is a legitimate, well-analyzed cryptographic-weakness defect worth patching on normal cadence, not a high-CVSS-masquerading-as-emergency issue - and not a low-CVSS-hiding-real-danger issue either. The main caveat is that AC:H understates how trivial address computation becomes once the key is recovered; the complexity lives entirely in the one-time state-recovery step.

On an affected board (experimental IID/PE feature enabled, entropy backend resolving to xoshiro128++), an attacker who can observe the device's network traffic captures on-wire values drawn from the same shared PRNG stream - ephemeral source ports, DNS query IDs, CoAP/DHCPv6 IDs - and inverts the generator's state transition to recover the 128-bit IID secret key. With the key known, the attacker computes the device's stable and temporary IPv6 interface identifiers for any prefix, enabling cross-network tracking and direct targeting of the host inside a /64 without scanning. No working exploit has been published; a public PoC reference exists but it is only a source-inspection reproduction procedure, not verified working exploit code.