OpenWrt odhcpd EUVD-2026-108969

Requires that odhcpd is actively serving DHCPv6 on the target interface with dynamic IA_NA allocation enabled and a usable IPv6 address configuration; no helper script or plugin is needed, but the attacker's client packet must include DHCPv6 RECONF_ACCEPT and the attacker must first seed/bind an IA_NA lease. The decisive limiting factor is network position: per the advisory the attacker must be able to send DHCPv6 client messages from the same local link or adjacent IPv6 network, so this is not an internet-wide unauthenticated attack despite the AV:N label - exposure is confined to on-link/adjacent attackers. No authentication or local account is required (unauthenticated DHCPv6 REQUEST), and no user interaction is needed. Devices where DHCPv6 server mode or dynamic leasing is disabled are not exploitable via this path.

This is a genuine but bounded priority. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:H) and 8.8 score indicate unauthenticated, low-complexity access with high availability impact and low integrity impact and no confidentiality impact - consistent with the validated outcome of an unauthenticated denial of service plus Reconfigure/ForceRenew key confusion. One conflict must be flagged: the CVSS vector encodes AV:N (network), but the description and GHSA advisory repeatedly scope the attacker to an 'adjacent-network'/'same local link' DHCPv6 client, which is AV:A in practice; this materially narrows real exposure to on-link/adjacent attackers rather than the public internet - verify reachability assumptions before treating it as internet-facing. No EPSS score and no KEV listing were provided, so there is no evidence of active exploitation; exploitation status is best described as a public PoC reference existing (the advisory documents a maintainer reproduction bundle with ASan/native-trace verification) rather than confirmed in-the-wild use. SSVC-style signals are partial: technical impact is a reliable crash (ASan-confirmed UAF, deterministic reclaim shown with PDBUF_UAF_GROOM=7), but arbitrary code execution is explicitly NOT proven for this UAF, so technical impact is 'partial', not 'total'. The vuln.today decision label is 'this_week', which aligns with a real-but-not-emergency priority: patch within the normal cycle, prioritizing internet- or untrusted-LAN-exposed odhcpd instances.

An attacker on the same IPv6 link or adjacent network sends a seed DHCPv6 REQUEST to bind an IA_NA lease, then a single crafted REQUEST carrying RECONF_ACCEPT and multiple IA_NA options so that one IA sets the per-message 'first' pointer, a later same-IAID IA fails the on-link check and frees that lease, and a final new-IAID IA copies from the now-dangling first->key - producing a 16-byte heap use-after-free. A public PoC reference exists (the odhcpd-uaf-first maintainer bundle with ASan and native-trace repro); it is not verified here as independently distributed working exploit code. The realistic result is a crash of the privileged odhcpd daemon (denial of service) and/or a zeroed/confused Reconfigure authentication key, consistent with the low attack complexity and no-authentication/no-user-interaction profile.