CVE-2026-52945

What it actually does

This is a Linux kernel WireGuard denial-of-service flaw caused by a problematic interaction with threaded NAPI processing. Under heavy network load, WireGuard receive-side packet processing for a specific peer can enter a permanently stalled state: packets are queued for decryption, but receive polling for that peer stops being invoked, the peer receive queue reaches its MAX_QUEUED_PACKETS limit, and subsequent encrypted packets for that peer cannot be processed. The failure affects decryption/receive handling for the impacted peer only; encryption/transmit may continue and other peers may remain healthy. The issue does not provide code execution, privilege escalation, or data disclosure, but it can break encrypted network connectivity until the affected interface, peer, node, or kernel path is reset or patched.

Why it matters to the business

Organizations using WireGuard in the Linux kernel, especially for Kubernetes or service-to-service encryption under high east-west traffic load, may experience rare but persistent connectivity failures between specific nodes or peers. This can disrupt application traffic, cause partial outages, break pod-to-pod communication, increase incident response time because the host may not crash or show obvious CPU or memory symptoms, and require node, interface, or workload remediation to restore traffic. The CVE is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so the main risk is availability impact in exposed or high-throughput WireGuard deployments rather than broad opportunistic exploitation.

How an attack unfolds

An attacker, or simply a high-volume workload, must be in a position to send traffic that is processed through an affected WireGuard peer. By creating sustained or bursty encrypted traffic under system pressure, packet decryption may complete out of order across worker threads while the in-order receive queue waits on an earlier packet that remains in an uncrypted state. The NAPI receive poll can then stop making forward progress for that peer. As additional packets arrive, the peer receive queue fills to the configured maximum, after which enqueue attempts fail and decrypted receive traffic from that peer remains stalled. The attacker does not need to execute code on the target; the practical effect is a peer-specific network denial of service that persists until the affected networking path is reset or a fixed kernel is deployed.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the WireGuard fix reverting threaded NAPI enablement for the affected path. Because fixed package versions were not provided in the input, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or Kubernetes node OS vendor. Prioritize systems using in-kernel WireGuard for production traffic, especially Kubernetes clusters using Cilium WireGuard encryption or similar high-throughput east-west encryption. Where immediate patching is not possible, mitigations include reducing traffic pressure on affected WireGuard peers, failing traffic over to unaffected nodes, restarting or recreating the affected WireGuard interface or node to clear the stuck peer state, and temporarily disabling WireGuard-based encryption only if an approved compensating network security control is in place.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems that use the in-kernel WireGuard module and comparing their kernel package/build against vendor advisories for this issue. Validate remediation by confirming the running kernel is the fixed vendor build, not only that a package is installed on disk. In functional testing, generate representative high-load encrypted WireGuard traffic between peers and verify that receive traffic continues to pass, peer-specific connectivity does not stall, and queue growth does not persist. On systems where advanced tracing is acceptable, use kernel tracing or eBPF to confirm that WireGuard receive polling continues for active peers and that receive queue enqueue failures are not accumulating under load.

Typical attack path

1. Identify a target that uses the in-kernel WireGuard driver for encrypted network traffic, such as node-to-node or pod-to-pod encryption.
2. Establish or leverage a network position that can send traffic through a WireGuard peer handled by an affected kernel.
3. Generate heavy or sustained encrypted traffic toward the affected peer to create receive-side queue pressure and worker scheduling contention.
4. Trigger the race/order condition where an early packet remains uncrypted while later packets complete decryption out of order.
5. Cause the WireGuard peer receive queue to stop being drained by NAPI polling and eventually reach the queue limit.
6. Maintain or repeat traffic pressure so newly initiated connections to that peer also fail while other peers may continue to operate normally.

How to detect it

To determine whether this has already occurred, review network monitoring, Kubernetes/Cilium telemetry, WireGuard peer health, and host observability for peer-specific receive failures rather than full host crashes. Look for one WireGuard peer or node pair where inbound encrypted traffic stopped while outbound traffic and other peers remained functional. Useful sources include Cilium agent logs and metrics, Kubernetes node and pod connectivity events, WireGuard interface statistics, kernel tracing data, flow logs, service mesh or application timeout logs, and incident timelines showing persistent failures that resolved after interface restart, node reboot, or workload relocation. Because this flaw is a kernel packet-processing stall and not a conventional intrusion, there may be no authentication logs, malware artifacts, files, registry keys, or command lines. Strong evidence consists of sustained peer-specific packet loss or timeouts correlated with high WireGuard traffic load and, where tracing was enabled, failed WireGuard receive queue enqueue activity or absence of receive polling for the affected peer.

• wg_prev_queue_enqueue
• wg_packet_rx_poll
• MAX_QUEUED_PACKETS
• PACKET_STATE_UNCRYPTED
• PACKET_STATE_CRYPTED
• wg_packet_decrypt_worker
• wg_queue_enqueue_per_peer_rx
• wg_queue_enqueue_per_device_and_peer
• cilium-agent
• wireguard

What your security team should do

• Prioritize patching Linux nodes that use WireGuard for production overlay, VPN, node-to-node, or pod-to-pod encryption under high traffic load.
• Coordinate with platform and SRE teams to identify Kubernetes environments using Cilium WireGuard encryption and schedule kernel or node image updates.
• Monitor for peer-specific WireGuard receive stalls, especially incidents where one peer stops receiving traffic while other peers remain healthy and host CPU/memory appear normal.
• Prepare an operational runbook to restore service by restarting the affected WireGuard interface, recycling the affected node, or failing workloads away from the impacted peer while awaiting permanent patching.
• Track vendor kernel advisories rather than relying only on upstream version numbers, because distributions may backport the fix into existing stable kernel package streams.
• Treat exploitation likelihood as currently low, but availability impact as meaningful for environments where encrypted east-west traffic is critical.