Cloudanix VulnDB

CVE-2026-99059

High · 7.7

CVSS

7.7

EPSS

0.4%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A rare timing problem in encrypted connection setup could theoretically let someone interfere with secure network sessions, but it is considered nearly impossible to exploit in real conditions.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in WireGuard handshake state machine allows two threads to consume the same response message and derive duplicate sessions by overwriting peer crypto state after an intervening initiation resets the state to waiting-for-response.

Why it matters to the business

Low practical risk of session confusion or traffic decryption on WireGuard-protected links; the flaw is described as extremely difficult to trigger under normal conditions and carries no known exploitation.

How an attack unfolds

An attacker would need to deliver identical response messages concurrently while relying on precise thread interleaving during slow cryptographic operations and writer-lock contention to cause one thread to accept a stale state copy; the described scenario is considered practically impossible to weaponize.

How to fix it

Apply the upstream kernel patch that adds an ephemeral private-key comparison before accepting a response; rebuild and deploy the fixed WireGuard module or upgrade to a distribution kernel containing the fix once released.

How to confirm the fix worked

Confirm the patch is present by inspecting the noise.c source for the added ephemeral-key equality check before state transition; recompile and test handshake concurrency under load to verify single-session derivation.

Typical attack path

  1. Deliver duplicate handshake response packets to the same peer
  2. Trigger concurrent processing threads that read handshake state under read lock
  3. Force writer-lock contention while a queued initiation resets state
  4. Allow the second thread to copy and apply its stale crypto material
  5. Cause both threads to derive sessions from the duplicated state

How to detect it

Examine kernel logs and WireGuard debug output for repeated handshake state transitions or duplicate session keys originating from the same peer within a short window; no public indicators of active exploitation exist.

What your security team should do

  • Monitor upstream Linux kernel and distribution advisories for the WireGuard noise fix
  • Prioritize patching on systems where WireGuard carries high-value traffic once a fixed kernel is available
  • Review WireGuard deployment logs for any anomalous handshake retry patterns as a general hygiene measure

The record

In the Linux kernel, the following vulnerability has been resolved: wireguard: noise: reject response consumption after intermediate initiation Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on down_write(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same down_write(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls up_write(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire down_write(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A. Thread A Thread B Thread C down_read() sA = handshake->state memcpy(cA, handshake->crypto) up_read() if (sA != 1) goto fail slow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB) down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail memcpy(handshake->crypto, cB) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() This seems basically impossible to hit in a meaningful way in practice, but ensure that it absolutely cannot happen by comparing the ephemeral private key that's on the stack with the latest one that the peer's handshake state has.

Affected packages

Ecosystem Package Introduced Fixed