Linux WireGuard EUVD-2026-108725

Requires that the target run the in-kernel WireGuard driver (Linux 5.6 through the fixed stable versions) with an active peer handshake in progress. The attacker must cause one identical handshake response message to be consumed twice by concurrent threads at the exact moment a handshake initiation is queued and acquires the handshake write lock, resetting state back to waiting-for-response so the second thread re-derives the same session. Limiting factors are severe: the trigger is a narrow multi-threaded timing race (reflected in AC:H), it depends on an in-flight handshake rather than an idle tunnel, and the commit author explicitly judges it practically impossible to hit; it affects only deployments where WireGuard is actually configured, not Linux hosts generally.

This is a high-CVSS (7.7) issue that the available signals converge in classifying as LOW real-world priority. The CVSS vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L) pairs a network vector with high attack complexity (AC:H), and that AC:H is corroborated directly by the commit author, who states the race condition 'seems basically impossible to hit in a meaningful way in practice.' EPSS reinforces this: 0.21% (10th percentile) indicates very low predicted exploitation likelihood. The flaw is NOT in CISA KEV (no active exploitation), and no public exploit or PoC is present in the input - the only references are the vendor fix commits on git.kernel.org. The vuln.today 'this_week' decision label reflects routine stable-kernel patch hygiene rather than emergency urgency, and no SSVC exploitation/automatable fields were supplied. The one point worth flagging: the C:H/I:H impact rating is generous for what is described - a cryptographic session-derivation race that duplicates an already-established session - and the Tags claim 'Information Disclosure' while the description never demonstrates key or plaintext exposure, so the high confidentiality/integrity weighting is an upper-bound inference, not a demonstrated outcome. Net: a real correctness bug worth patching on the normal stable-update cadence, not a widespread-exploitation emergency.

An on-path or peer attacker interacting with a WireGuard tunnel causes an identical handshake response message to be delivered and processed twice by concurrent kernel threads while a handshake initiation is simultaneously queued; the intermediate initiation resets the handshake state mid-flight, letting the second thread derive a duplicate session from stale ephemeral key material. Exploitation is network-reachable but gated by an extremely tight timing window - the author assesses it as basically impossible to trigger meaningfully in practice. No public exploit identified at time of analysis.