CVE-2026-63867

What it actually does

This is a race condition in the Linux kernel Multipath TCP (MPTCP) output path. The kernel reads the MPTCP-level acknowledgement sequence value without locking and may use different values when building the DSS acknowledgement option and when calculating the advertised receive window for the same outgoing packet. That time-of-check/time-of-use inconsistency can create invalid or confusing MPTCP state on the peer side, potentially causing connection disruption, incorrect protocol behavior, or denial of service. The CVSS vector indicates remote, unauthenticated network exploitability with primary impact to availability and limited integrity impact, with no expected confidentiality impact.

Why it matters to the business

Systems that expose or use MPTCP may be vulnerable to remotely triggered connection failures or service disruption without requiring attacker credentials. The most likely operational effect is instability or outage for services relying on Linux MPTCP-capable network paths, especially high-availability, mobile, proxy, gateway, or multi-homed networking use cases. Although it is not currently listed in CISA KEV, has no reported ransomware association, and has low EPSS at this time, the high availability impact means internet-facing or critical network infrastructure should still be patched through normal priority kernel update processes.

How an attack unfolds

An attacker needs network reachability to a Linux system where MPTCP is enabled and reachable. The attacker initiates or interacts with MPTCP traffic and attempts to create packet timing and acknowledgement patterns that exercise the kernel output path while the MPTCP-level acknowledgement sequence is changing. Because the vulnerable code reads that state multiple times without a consistent snapshot, one outgoing packet can carry DSS acknowledgement information derived from one value while its advertised receive window is computed from another. The peer may then observe inconsistent MPTCP control information, which can cause protocol confusion, connection stalls, resets, degraded throughput, or resource-consuming retry behavior. Successful exploitation is expected to manifest as service instability or denial of service rather than data disclosure.

How to fix it

Apply the vendor-provided Linux kernel update that includes the MPTCP fix for CVE-2026-63867. Because no product-specific fixed versions were provided, use the relevant distribution or appliance security advisory to identify the corrected kernel package for each platform. Reboot into the updated kernel after installation; patching the package alone is not sufficient if the running kernel remains vulnerable. If MPTCP is not required, reduce exposure by disabling it using the supported platform configuration, commonly via the Linux sysctl setting `net.mptcp.enabled=0`, and make the setting persistent through the distribution’s normal sysctl configuration mechanism. Where disabling MPTCP is not possible, restrict network reachability to MPTCP-enabled services and monitor for abnormal MPTCP connection failures until patching is complete.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, contains the vendor fix. Validate with `uname -r`, package manager metadata, and the applicable Linux distribution security advisory. Check whether MPTCP is enabled with `sysctl net.mptcp.enabled`; a value of `1` indicates the feature is enabled, while `0` indicates it is disabled. Where supported, inspect MPTCP usage with `ss -M`, `ip mptcp endpoint show`, or equivalent distribution tools. After remediation, reboot if required and re-check the active kernel version. For mitigation validation, confirm `net.mptcp.enabled=0` after reboot if MPTCP was intentionally disabled. Functional validation should include representative network testing for services that use MPTCP to ensure connections remain stable after the kernel update or mitigation.

Typical attack path

1. Identify a Linux host or service that supports Multipath TCP and is reachable over the network.
2. Establish MPTCP-capable connections or interact with existing MPTCP paths.
3. Generate traffic patterns that rapidly change acknowledgement state and receive-window conditions.
4. Trigger the race in the kernel MPTCP output path so a packet is emitted with inconsistent DSS acknowledgement and receive-window information.
5. Cause the MPTCP peer or connection state machine to misbehave, resulting in degraded connectivity, connection resets, stalls, or denial of service.

How to detect it

There are no public, vulnerability-specific exploitation artifacts or known threat actor indicators provided for this issue. Retrospective detection should focus on evidence of abnormal MPTCP behavior and denial-of-service symptoms. Review kernel logs, system journals, network telemetry, firewall logs, load balancer logs, and packet captures for unusual spikes in MPTCP connection failures, resets, retransmissions, stalled sessions, or sudden service degradation. On Linux systems, correlate timestamps of service instability with MPTCP activity from tools such as `ss -M` or packet captures showing MPTCP DSS options. Look for repeated connection attempts from the same external sources that coincide with kernel networking warnings, high softirq CPU usage, backlog exhaustion, or abrupt MPTCP subflow churn. Because successful exploitation may leave no durable host artifact, absence of logs does not prove absence of exploitation.

What your security team should do

• Inventory Linux systems with MPTCP enabled, prioritizing internet-facing servers, network appliances, gateways, proxies, mobile-network components, and multi-homed hosts.
• Apply vendor kernel updates that include the fix and reboot affected systems into the patched kernel.
• If MPTCP is not business-required, disable it as a compensating control and verify the setting persists after reboot.
• Prioritize critical availability systems even though EPSS is currently low and the vulnerability is not in CISA KEV.
• Add monitoring for unusual MPTCP connection resets, stalls, retransmission spikes, and kernel networking errors until patching is complete.
• Track distribution advisories for exact fixed kernel package versions and ensure downstream appliances or container hosts inherit the corrected kernel.
• Document any systems where MPTCP must remain enabled and apply network access controls to limit who can initiate MPTCP sessions.