The vulnerability lies in the DHCPv4 client using a predictable, counter‑based transaction identifier rather than a random value per transaction. This identifier is reused across RENEWING and REBINDING exchanges and is only seeded once when the client starts. Because the client accepts a DHCP reply if the transaction ID and MAC address match, an attacker who learns a single identifier—by observing a broadcast DHCPDISCOVER or by having prior network access—can forge subsequent replies. Such forged packets can inject gateway or DNS options, reconfigure the device’s networking stack, and disrupt connectivity. The weakness is a misuse of cryptographic randomness (CWE‑340).

Devices running the Zephyr RTOS, particularly those using the DHCPv4 client implementation in subsys/net/lib/dhcpv4/dhcpv4.c. The vulnerability applies to any Zephyr build using the default DHCP client behavior before the recent update that introduces per‑transaction random identifiers.

The CVSS score is 5.6, indicating a moderate impact. The EPSS score is not available, so the current exploitation probability cannot be quantified from public data, and the vulnerability is not listed in the CISA KEV catalog. The likelihood of exploitation is facilitated by the fact that any host on the same broadcast domain can capture a DHCPDISCOVER and thus learn the transaction ID. No special privileges or credentials are required on the target device. An attacker can exploit the flaw by sending a single forged DHCPACK containing malicious gateway or DNS options; the client will accept it because the packet satisfies the existing validation checks. This can be performed repeatedly during RENEWING or REBINDING phases or by sending a DHCPNAK to force reconfiguration.