Zephyr's WireGuard implementation in subsys/net/lib/wireguard/wg_crypto.c mishandled keepalive packets. In wg_process_data_message(), 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 wg_decrypt_packet() was ever called. The Poly1305 authentication tag was therefore never verified; the only preceding gates were a cleartext receiver-index lookup (get_peer_keypair_for_index() on the attacker-supplied data_hdr->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 wg_input() to handle_transport_data() and then wg_process_data_message(). 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 NET_EVENT_VPN_CONNECTED signal (setting peer->first_valid and notifying any net_mgmt 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 wg_decrypt_packet(), 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 components
Affected versions
>= 4.4.0, < 4.4.2
Fix
Fixed in 4.4.2. Release lines that have not yet taken the backport remain affected — see the affected version range above.
Introduced by: a239800 (net: wireguard: Add initial implementation, 2026-03-23; first shipped in v4.4.0)
Evidence
- subsys/net/lib/wireguard/wg_crypto.c:1417-1424 — post-fix: keepalive (data_len==16) is recognised only AFTER wg_decrypt_packet() and wg_check_replay() succeed
- subsys/net/lib/wireguard/wg_crypto.c:1366-1382 — Poly1305 decrypt and anti-replay gate that the pre-fix keepalive path bypassed
- subsys/net/lib/wireguard/wg_crypto.c:1384-1387 — NET_EVENT_VPN_CONNECTED notify / first_valid set; pre-fix this also ran in the unauthenticated early return
- v4.4.0:subsys/net/lib/wireguard/wg_crypto.c:1327-1339 (git show) — vulnerable early return that fired before decryption, as shipped in v4.4.0
- subsys/net/lib/wireguard/wg.c:897,706-722 — dispatch: MESSAGE_TRANSPORT_DATA -> handle_transport_data() -> wg_process_data_message(), keyed on cleartext receiver index, confirming network reachability
- subsys/net/lib/shell/events.c:505-508 — NET_EVENT_VPN_CONNECTED is a consumed management event (the spoofed signal)
- git tag --contains a239800 includes v4.4.0 — vulnerable code shipped in a release (reportable)
Patches
For more information
If you have any questions or comments about this advisory:
embargo: 2026-08-28
Zephyr's WireGuard implementation in
subsys/net/lib/wireguard/wg_crypto.cmishandled keepalive packets. Inwg_process_data_message(), 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, beforewg_decrypt_packet()was ever called. The Poly1305 authentication tag was therefore never verified; the only preceding gates were a cleartext receiver-index lookup (get_peer_keypair_for_index()on the attacker-supplieddata_hdr->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
wg_input()tohandle_transport_data()and thenwg_process_data_message(). 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
NET_EVENT_VPN_CONNECTEDsignal (settingpeer->first_validand notifying anynet_mgmtlistener) 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
wg_decrypt_packet(), 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 components
subsys/net/lib/wireguardAffected versions
>= 4.4.0, < 4.4.2Fix
Fixed in 4.4.2. Release lines that have not yet taken the backport remain affected — see the affected version range above.
Introduced by: a239800 (net: wireguard: Add initial implementation, 2026-03-23; first shipped in v4.4.0)
Evidence
Patches
main87c520a55f0fv4.4-branchFor more information
If you have any questions or comments about this advisory:
embargo: 2026-08-28