DragonFly BSD EUVD-2026-101819

No special product configuration is required: the flaw is in the default ARP input path (arpintr()/in_arpinput() calling in_arpreply()) that processes every incoming ARP request on DragonFly BSD through 6.4.2 before commit 4bb22ff. The decisive limiting factor is network position - the attacker must be unauthenticated but on the adjacent Layer-2 broadcast domain (AV:A), as ARP is not routed across subnets, so remote off-link attackers cannot reach the vulnerable handler. A single crafted ARP request suffices, with no user interaction and no authentication, but impact is confined to disclosure of roughly 250 bytes each of kernel heap and stack memory per request.

This is a genuine but bounded risk. The CVSS 4.0 vector (AV:A/AC:L/AT:N/PR:N/UI:N) confirms an adjacent-network, low-complexity, unauthenticated attack requiring no user interaction, which is a reliable and repeatable primitive. However, impact is strictly confidentiality (VC:H, VI:N, VA:N) - an out-of-bounds read of up to ~250 bytes each of kernel heap and stack memory, notably including kernel pointers that can defeat KASLR and seed a follow-on exploit. The adjacent (AV:A) requirement is the dominant limiting factor: the attacker must share the Layer-2 broadcast domain, which rules out broad internet-scale automated exploitation and makes this far lower priority than a network-reachable (AV:N) RCE despite the 7.1 base score. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so exploitation status is 'no public exploit identified at time of analysis'; the only referenced artifact is the upstream fix commit, not weaponized exploit code. Note: the input supplies only a CVSS 4.0 vector and no CVSS 3.1 vector or SSVC decision data, so the real-world exploitation-probability and automatable signals cannot be cross-referenced - the assessment rests on the vector and the source-code evidence alone.

An attacker positioned on the same local network segment as a DragonFly BSD host sends a single crafted ARP request in which the hardware-address-length (ar_hln) and protocol-address-length (ar_pln) fields are set larger than the real 6-byte and 4-byte values. The kernel's in_arpreply() uses these attacker-controlled lengths as memcpy sizes, over-reading adjacent kernel heap and stack memory and returning it inside the ARP reply, leaking kernel pointers useful for bypassing KASLR. No public exploit code is identified at time of analysis, though the upstream fix commit publicly documents the vulnerable code path.