CVE-2026-68118: WSL 2 Kernel Predates Linux TCP Fix

The National Vulnerability Database added the record on August 10, 2026, with kernel.org as its source. Its description is unusually precise: Linux’s

path accepted a TCP RST while a server-side connection was in

so long as the packet fell inside the receive window. It did not require the reset packet’s sequence number to match

, the next sequence value the server expected.

That difference is the vulnerability. A reset with the exact expected sequence number is supposed to abort the pending connection. A reset whose sequence number is merely somewhere inside the receive window is supposed to receive a challenge ACK and be discarded. Linux instead removed the pending request.

This is a connection-disruption bug, not a remote-code-execution issue. An attacker able to inject a suitably crafted packet at the right point in a TCP handshake can cause an inbound connection attempt to fail. The requirement to hit the receive window means this is not equivalent to sending arbitrary RST packets at a server; the attacker needs enough knowledge or network position to make the packet plausible. But for exposed services and hostile or untrusted network paths, that is exactly the class of TCP hardening RFC 5961 and RFC 9293 were written to provide.

The bug lives before a TCP connection is established​

The affected state is

, the server-side halfway point of a conventional TCP handshake. A client sends SYN, the server returns SYN-ACK, and the server maintains a lightweight request socket while waiting for the client’s final ACK. Only after that ACK is validated does Linux promote the request into a fully established TCP socket.

This matters operationally because the vulnerable object is in the listener’s pending connection queue, rather than a normal established application session. A web server, SSH daemon, VPN gateway, database listener, or development service can be affected if it accepts inbound TCP handshakes through the Linux kernel in question. A valid-looking but non-exact RST can delete that pending request and make a legitimate client’s connection appear to have failed or timed out.

RFC 9293, the current TCP specification, lays out the required ordering: validate the sequence number, process RST, then validate ACK fields. For implementations using the RFC 5961 reset hardening, an in-window RST is only accepted when its sequence number exactly equals

. A non-exact RST inside the window must trigger an ACK containing the expected sequence number, then be dropped without further processing.

The NVD description confirms Linux was doing the later ACK validation before applying that stricter RST check in the request-socket path. That ordering error is what made the reset effective when it should have been challenged.

The upstream change does more than add a sequence comparison. It moves the check ahead of ACK-field validation and extends the challenge-ACK rate controls to request sockets. That implementation detail is important: blindly sending an ACK for every suspect packet could create an amplification or ACK-loop problem. The patch shares the per-network-namespace challenge-ACK quota and uses the request socket’s own out-of-window ACK timestamp to rate-limit replies.

In practical terms, patched kernels retain the pending connection, issue a controlled challenge ACK, and wait for the legitimate peer to prove it can continue the handshake correctly.

The CVE record’s affected-version data needs careful reading​

CVE-2026-68118 traces the bug to Linux commit

, labeled “tcp: implement RFC 5961 3.2.” The NVD record marks Linux versions from 3.6 onward as affected by default, while also listing several older stable-version ranges. That is a broad upstream lineage statement, not a claim that every currently shipped enterprise or consumer distribution has identical exposure.

Linux distributions commonly carry security backports without changing the visible upstream version number. A kernel reporting

, for example, may include a networking security fix originally committed to a later upstream branch. Conversely, a kernel version that looks newer than an old advisory can still lack a fix if the distributor has not backported it.

At publication, however, the CVE record gives explicit upstream clean points only for these release lines:

• Linux 6.18.42 and later in the 6.18 series are listed as unaffected.
• Linux 7.1.6 and later in the 7.1 series are listed as unaffected.
• Linux 7.2-rc5 and later development snapshots include the original fix.

The Linux Kernel Archives currently list

as the current longterm release and

as the current stable release, both released on August 9. Those builds are beyond the CVE’s stated fixed cutoffs.

The same cannot be said from the public CVE record for still-maintained longterm branches such as

,

,

,

, and

. As of August 11, the record does not identify fixed versions for those lines. Administrators should not infer safety from an apparently mature LTS kernel alone; they need their distribution’s advisory or changelog confirming that this specific patch was backported.

That gap is the material issue in the disclosure. The CVE says the vulnerability “has been resolved,” which is correct for the relevant upstream branches. It does not establish that every supported Linux distribution, appliance kernel, cloud image, container host, or managed WSL kernel has received the correction.

WSL 2 is presently inside the unresolved window​

WSL 1 does not run the Linux kernel networking stack in the same way and is outside this particular kernel issue. WSL 2 is different: Microsoft documents that it runs an actual Linux kernel inside a lightweight managed virtual machine, which makes the upstream TCP behavior directly relevant.

Microsoft’s public

repository identifies

, released May 28, 2026, as its latest listed kernel release. That is below the upstream

fix threshold. Microsoft’s WSL release material and the Microsoft Security Response Center search results reviewed for this report do not yet identify CVE-2026-68118 or announce a backport.

That does not prove every installed WSL 2 machine is exploitable. Some users run custom kernels, organizations can deploy their own kernel image through

, and Microsoft could ship a quiet servicing update or backport before publishing an advisory. It does establish a more useful operational conclusion: a fully updated Windows installation is not, by itself, evidence that its WSL 2 Linux kernel contains this fix.

The exposure also depends on whether WSL is accepting inbound TCP connection attempts. A developer running an isolated local service has a different risk profile from a WSL instance hosting SSH, a web application, a reverse proxy, Docker-published ports, or a service reachable through mirrored networking, port forwarding, a VPN, or a corporate LAN configuration.

The vulnerable interval is short, but it is exactly when Internet-facing and automation-heavy services receive constant unsolicited connection attempts. Connection failures caused by such a packet would be easy to misdiagnose as a proxy timeout, flaky Wi-Fi, load-balancer behavior, NAT state loss, or an application that never saw the request.

Administrators should verify kernel provenance, not just uname -r​

For ordinary Linux servers, the correct response is to install the distributor’s kernel security update once it includes CVE-2026-68118, then reboot into that kernel. Checking the running build remains useful, but the package changelog or vendor advisory is the decisive evidence for backported kernels.

For WSL 2, start in elevated PowerShell:

wsl --status
wsl --version
wsl --update
wsl --shutdown

Then, inside each WSL 2 distribution that runs an inbound service, check the active kernel:

is Microsoft’s supported mechanism for retrieving the current WSL servicing package and kernel.

matters because it stops the managed VM so the next launch uses the newly installed kernel. Merely updating packages inside Ubuntu, Debian, Fedora, or another WSL distribution does not normally replace the Microsoft-managed WSL kernel.

Do not treat a version comparison alone as a permanent verdict. If the reported WSL release remains based on

, it is below the NVD’s upstream fixed point, but Microsoft could incorporate the patch under a Microsoft-specific version string. The confirmation to watch for is a Microsoft WSL release note, kernel-repository commit, or security advisory naming CVE-2026-68118 or the upstream patch “tcp: challenge ACK for non-exact RST in SYN-RECEIVED.”

Until then, systems with no need to accept inbound connections in WSL should avoid exposing development listeners beyond localhost. Systems deliberately running WSL-hosted network services should place them behind controls that reduce unsolicited direct TCP access and plan to update as soon as Microsoft publishes a patched kernel.

The key date for Windows administrators is not the August 10 NVD publication date; it is the date Microsoft ships a WSL kernel at or above the relevant backport. As of August 11, the public record shows the upstream fix is available, while the current Microsoft WSL kernel release still predates it.