OpenWrt odhcpd EUVD-2026-108968

odhcpd must be running with DHCPv6 server handling enabled on the target interface, and the attacker must be able to send DHCPv6 client traffic on the local IPv6 link (link-local adjacency, not internet-routable). The request must contain a valid Client Identifier so dhcpv6_ia_handle_IAs() processes IA options, and the final IA_NA or IA_PD option must be short enough (the repro uses olen==0) that the ia->iaid read crosses the 8192-byte receive-buffer boundary. The network path must deliver an 8192-byte UDP datagram; this does not require changing the target MTU because IPv6 fragmentation can reassemble before recvmsg(). Limiting factors that reduce real-world risk: requires same-link adjacency, DHCPv6 server mode must be enabled, and each request discloses only ~4 bytes (reflected as the reply IAID), so defeating ASLR/canary requires many probing requests.

This is a genuine but second-tier priority: a real, validated flaw whose impact is confined to information disclosure. The input CVSS 4.0 score is 8.7 (High) with vector AV:N/AC:L/AT:N/PR:N/UI:N and VC:H only (VI:N/VA:N), reflecting an unauthenticated, low-complexity read of high-value memory with no integrity or availability impact. Signals partly conflict on reachability: the scored vector uses AV:N (network), but the advisory and description repeatedly state the attacker must be 'network-adjacent' on the 'local IPv6 link' - DHCPv6 is link-local, so adjacency (AV:A) is the accurate attack vector and AV:N overstates internet-wide exposure; verify reachability assumptions before prioritizing. No EPSS score is provided in the input, so probabilistic exploitation likelihood cannot be weighed. The CVE is not listed in CISA KEV, so there is no evidence of active exploitation - treat as not-yet-exploited. The vuln.today Decision label is 'this_week' (not act_now/emergency), consistent with a serious-but-not-crisis item. A public PoC reference exists in the GHSA advisory as a detailed, maintainer-validated reproducer (ASAN stack-buffer-overflow report plus a native run leaking the stack canary 00cf9a87 and ~392 bytes of stack), though the input does not confirm it as independently published, working exploit code. The standalone impact is limited - roughly four bytes reflected per request as the reply IAID - so its true danger is as a mitigation-bypass primitive: leaking the stack canary and ASLR-useful stack/process pointers to enable a separate memory-corruption exploit. Net: patch on a near-term (this-week) cadence, especially on OpenWrt devices exposing DHCPv6 to untrusted link-local segments; this is not a drop-everything emergency absent KEV/EPSS evidence.

An unauthenticated attacker on the same IPv6 link sends odhcpd a DHCPv6 client request carrying a valid Client Identifier and a final IA_NA or IA_PD option with a zero-length body positioned at offset 8188 of an 8192-byte datagram. odhcpd casts the short option to struct dhcpv6_ia_hdr and reads ia->iaid from bytes 8192-8196 - past the receive buffer and into the stack frame - then reflects those bytes back as the reply IAID, disclosing the saved stack canary (and, via repeated boundary scans, further stack pointers). A maintainer-validated PoC reference in the GHSA advisory demonstrates this leak; attack complexity is low but requires link-local adjacency.