CVE-2026-13735: WireGuard keepalive transport-data messages accepted without Poly1305 authentication
Zephyr's WireGuard implementation in subsys/net/lib/wireguard/wgcrypto.c mishandled keepalive packets. In wgprocessdatamessage(), any type-4 transport-data message whose payload was exactly 16 bytes (an empty plaintext plus a bare Poly1305 tag, i.e. a keepalive) was accepted and returned immediately, before wgdecryptpacket() was ever called. The Poly1305 authentication tag was therefore never verified; the only preceding gates were a cleartext receiver-index lookup (getpeerkeypairforindex() on the attacker-supplied datahdr->receiver) and a non-cryptographic keypair validity/expiry check.
The path is reachable entirely from the network: inbound UDP on the WireGuard port is dispatched by wginput() to handletransportdata() and then wgprocessdatamessage(). The 32-bit receiver index is transmitted in cleartext in WireGuard handshake and data messages, so an on-path observer learns it directly and an off-path attacker can brute-force it against the UDP port. Given an active receiving-valid session for that index, an attacker could send a 16-byte garbage payload and have it accepted without possessing the session key.
On acceptance the unauthenticated message caused the management layer to observe a spoofed NETEVENTVPNCONNECTED signal (setting peer->firstvalid and notifying any netmgmt listener) and incremented the keepalive-RX statistic. The impact is limited to integrity of this status signal: no plaintext is decrypted or injected, no key is disclosed, and the early-return path did not update the peer endpoint or liveness timers, so there is no traffic-injection, session-takeover, or availability consequence.
The fix removes the pre-decrypt early return so a 16-byte payload flows through wgdecryptpacket(), which verifies the Poly1305 tag over the empty plaintext, followed by the existing anti-replay check; only an authenticated, non-replayed message is then recognised as a keepalive. Forged keepalives now fail the tag check and are counted as decrypt failures.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update Zephyr’s WireGuard implementation so that in wg_process_data_message(), type-4 transport-data keepalive messages with a payload length exactly 16 bytes are not accepted via a pre-decrypt early return; instead, route them through wg_decrypt_packet() so the Poly1305 tag is verified over the empty plaintext, followed by the existing anti-replay check. Only authenticated, non-replayed messages should be recognised as keepalives (spoofed NET_EVENT_VPN_CONNECTED should no longer be possible).
Zephyr WireGuard (subsys/net/lib/wireguard/wg_crypto.c) Remove pre-decrypt early return for keepalive/transport-data messages with payload exactly 16 bytes = wg_decrypt_packet() must be called so Poly1305 is verified (empty plaintext + bare Poly1305 tag)
Event History
Frequently Asked Questions
Which deployments are exposed to network exploitation?
Zephyr systems that accept inbound UDP traffic on a WireGuard port are reachable through the affected processing path. Exploitation also requires an active receiving-valid WireGuard session associated with the targeted receiver index.
Does an attacker need the WireGuard session key?
No. An attacker can have a 16-byte transport-data payload accepted without possessing the session key if they target a valid receiver index. An on-path attacker can observe the cleartext index directly, while an off-path attacker could attempt to brute-force the 32-bit index against the UDP port.