IT SBIT Services
Schneeberger
DEEN
CVE tracker

Zephyr WireGuard: Peer endpoint hijack via unauthenticated transport-data messages

CVE-2026-79977High 8.2

← All vulnerabilities

Summary

The WireGuard VPN service in Zephyr RTOS overwrites the peer endpoint from an unauthenticated transport-data datagram whose receiver index matches no session. An off-path attacker who can send a single UDP datagram to the WireGuard port (default 51820) can redirect all subsequent handshakes and data packets to an address of their choosing. The tunnel then becomes persistently unusable and the attacker can sit in the traffic path to observe ciphertext metadata and drop packets; end-to-end encryption still prevents decryption or forgery.

Affected

  • Zephyr versions >= 4.4.0 to <= 4.4.2
  • Component: subsys/net/lib/wireguard (CONFIG_WIREGUARD, experimental, disabled by default)

Fixed in

  • Fixed on main, planned for Zephyr 4.5.0
  • Backport to v4.4 proposed (PR 117179); first fixed 4.4.x release unknown

Workaround

  • Disable CONFIG_WIREGUARD in firmware builds that do not need it
  • Restrict UDP 51820 at the network edge to known peer addresses

Exploitation

  • No evidence of exploitation in the wild found
  • Technical details are public; no exploit code published in the reviewed sources

Our recommendation

  • Check whether any Zephyr-based devices in your environment use WireGuard
  • If WireGuard is not needed, disable CONFIG_WIREGUARD in the firmware
  • If needed, limit UDP 51820 to known peer IP addresses
  • Ask device vendors for firmware built on a patched Zephyr version
  • Monitor for unexpected endpoint changes and tunnels that stop completing handshakes

Public exploits

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 1 Nov 2026, 15:06.

Original description (NVD)

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.

NVD references (2)

Sources

The tracker combines official, freely usable data sources – updated continuously:

This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.

Affected? We can help.

We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.