CVE-2026-79977 in Zephyr
Summary
by MITRE • 10/23/2026
The WireGuard VPN service in subsys/net/lib/wireguard/wg.c updated the peer endpoint from a message it could not authenticate. In handle_transport_data(), when the 32-bit receiver index of an incoming transport-data message matched no session, the code both scheduled a new handshake and copied the datagram's source address into peer->endpoint with memcpy(&peer->endpoint, peer_addr, sizeof(peer->endpoint)). Because the receiver index is unknown, there is no key with which such a message could be verified, so the address written into peer->endpoint is entirely attacker-supplied. Every other endpoint update in the implementation happens only after authentication — after the Noise handshake in handle_handshake_init(), or after AEAD decryption plus the anti-replay check in wg_process_data_message().
The WireGuard listener is registered with net_udp_register() using no remote address or port filter and defaults to UDP port 51820 (CONFIG_WIREGUARD_PORT), and wg_ctrl_recv() resolves the peer by interface rather than by any cryptographic identity. Any host able to send a UDP datagram to that port can therefore reach the defect off-path, with no need to observe legitimate traffic: a 16-byte datagram carrying the transport-data type, zeroed reserved bytes and an arbitrary receiver index is sufficient. The vulnerable branch runs whenever the peer has neither a valid handshake nor a current keypair — the state at boot and after a session expires.
A single spoofed datagram redirects peer->endpoint to an address of the attacker's choosing, and all subsequent handshake initiations, keepalives and encrypted data packets are sent there. The legitimate peer never receives the initiations and so never re-authenticates, and nothing resets the endpoint afterwards, leaving the tunnel persistently unusable on devices whose peer does not initiate handshakes itself. The attacker can also relay the redirected initiations to the real peer to place itself in the path of the tunnel, observing ciphertext and traffic metadata and selectively dropping packets. WireGuard's end-to-end cryptography still prevents decryption or forgery of tunnel content, so the impact is loss of availability plus limited confidentiality, not key compromise.
The fix removes the endpoint learning from this path entirely: the stale-session recovery is kept, but the handshake is sent only to an endpoint learnt from an authenticated message, falling back to the configured cfg_endpoint, and the message is dropped when neither is known. CONFIG_WIREGUARD is marked experimental and is not enabled by default.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability in question resides within the WireGuard VPN implementation found in the subsys/net/lib/wireguard directory of certain embedded systems or operating system kernels, specifically affecting the handling of transport data messages during peer endpoint resolution. The core technical flaw occurs in the handle_transport_data function when processing incoming UDP datagrams that contain a receiver index not currently associated with any active session. In this specific state where no valid cryptographic context exists for the received packet, the code erroneously schedules a new handshake and simultaneously updates the peer's endpoint address by copying the source IP address from the unauthenticated datagram into the peer structure using memcpy. This behavior is fundamentally insecure because it trusts network-layer addressing information without verifying the authenticity of the message content. Since the receiver index is unknown to the system, there are no keys available to verify the integrity or origin of the packet, meaning the attacker can supply an arbitrary source address that will be blindly accepted as the legitimate peer's location. This contrasts sharply with other endpoint update mechanisms in the WireGuard implementation, which strictly require successful authentication through either a completed Noise handshake or valid AEAD decryption combined with anti-replay checks before allowing any modification to the peer's endpoint configuration.
The operational impact of this vulnerability is significant due to the specific network conditions under which it can be exploited and its effect on service availability and partial confidentiality. The WireGuard listener typically registers for UDP traffic without filtering by remote address or port, defaulting to standard VPN ports such as 51820. Furthermore, peer identification relies on interface resolution rather than cryptographic identity during the initial phases of connection establishment. This architecture allows an off-path attacker who can send a single spoofed UDP datagram to trigger the defect. The attack requires minimal payload complexity: a sixteen-byte datagram with transport-data type markers and zeroed reserved bytes is sufficient to cause the system to redirect its endpoint configuration. When this occurs, all subsequent handshake initiations, keepalives, and encrypted data packets are directed toward the attacker-controlled address rather than the legitimate peer. Because the legitimate peer never receives these initiation requests, it cannot re-authenticate or reset the connection state, leading to a persistent loss of availability for devices that do not independently initiate handshakes. Additionally, if an active man-in-the-middle scenario is established by relaying these redirected packets, the attacker can observe traffic metadata and ciphertext, although WireGuard's end-to-end encryption prevents actual decryption or content forgery.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to validate that unauthenticated network data should not influence critical state variables like peer endpoints. It also relates to CWE-697 Incorrect Comparison, where the logic incorrectly assumes that any packet claiming to be from a peer is valid enough to update connection parameters without prior cryptographic verification. In terms of attack vectors, this falls under MITRE ATT&CK techniques involving network manipulation and potentially T1048 which covers Exfiltration Over Alternative Protocol if used in conjunction with other attacks, though the primary impact here is availability disruption via endpoint hijacking. The vulnerability exploits a race-like condition where state transitions are not properly gated by authentication status, allowing an unauthenticated actor to manipulate routing logic within the VPN tunnel management layer.
Mitigation strategies focus on enforcing strict separation between untrusted network input and trusted configuration updates. The primary fix involves removing the automatic endpoint learning from the path that handles messages with unknown receiver indices. Instead of trusting the source address of any incoming packet, the system should only update peer endpoints after successful authentication events, such as completing a Noise handshake or successfully decrypting an authenticated message. If no valid endpoint is known through these trusted channels, the implementation should fall back to a statically configured endpoint rather than dynamically adopting one from unverified traffic. For administrators using this specific subsystem, it is crucial to note that CONFIG_WIREGUARD is often marked as experimental and may not be enabled by default in many distributions; however, where it is active, applying vendor-provided patches that enforce authenticated-only endpoint updates is essential to prevent denial-of-service attacks through connection hijacking.