Unauthenticated Linux Kernel RCE via MPTCP Listeners: Defending Against the New Remote Root Flaw (2026)

Security researchers at Anthropic have demonstrated a working exploit for a critical vulnerability in the Linux kernel's Multipath TCP (MPTCP) implementation that allows an unauthenticated, remote attacker to execute arbitrary commands as root on any server exposing an MPTCP listener. Per the original reporting, this is not a theoretical weakness — a functional exploit exists, which collapses the window between disclosure and weaponization to near zero.

At the time of writing, a CVE identifier and final CVSS score have not been formally published alongside the disclosure. Based on the characteristics described — pre-authentication, network-reachable, kernel-space code execution with full root privileges — this sits firmly in critical (9.x) territory under any reasonable scoring. Do not wait for a score to begin remediation. Kernel-level remote code execution is the worst-case scenario for a defender: no user interaction, no credentials, no sandbox boundary — the attacker lands in ring 0.

Your immediate task is twofold: (1) determine which hosts in your environment actually have MPTCP listeners exposed — this is a much smaller population than "all Linux servers," and scoping it correctly will save you days — and (2) patch or mitigate those hosts before exploit code circulates broadly.

Technical Analysis

What is affected

Component: The MPTCP networking stack in the Linux kernel (mainline MPTCP support has existed since kernel 5.6; the in-kernel path manager and socket handling code is the affected surface).
Affected platforms: Linux systems where applications have created MPTCP listener sockets (IPPROTO_MPTCP). This is the critical scoping detail: MPTCP support being compiled into the kernel is not sufficient for exploitation — a process must be actively listening on an MPTCP socket. Common real-world sources of MPTCP listeners include applications explicitly opting into MPTCP, workloads launched via mptcpize (which LD_PRELOAD-intercepts socket calls to convert TCP sockets to MPTCP), hosts running mptcpd, and network functions/proxies built to leverage multipath for resilience.
Not affected as a direct target: Systems with no MPTCP listeners, and non-Linux systems. Client-side MPTCP (e.g., mobile devices initiating MPTCP connections) is a different exposure profile, but inventory it anyway.

How the attack works (defender's view)

MPTCP extends TCP so a single connection can traverse multiple network paths simultaneously — think a server that keeps a session alive across both its primary and backup interfaces. Negotiation happens via TCP options (the MP_CAPABLE option in the initial SYN handshake), after which the kernel MPTCP subsystem manages subflows, path management, and data scheduling.

Because the vulnerable code path is reachable during the MPTCP handshake/connection handling, the attacker only needs to deliver crafted network traffic to a listening MPTCP socket. There is no authentication stage to defeat — the kernel processes the malicious input before any application-layer logic runs. Successful exploitation corrupts kernel memory in a controlled way, yielding arbitrary code execution in kernel context, which trivially translates to root-level command execution on the host.

From an incident-response perspective, note the implications: kernel exploits of this class often either (a) crash the target on failed attempts — leaving kernel oops, BUG:, or general protection fault entries in logs — or (b) succeed silently and immediately hand the attacker a root shell or a staged payload channel. Both leave detectable artifacts if you're collecting the right telemetry.

Exploitation status

Proof of concept: Confirmed — the Anthropic research team developed and demonstrated the exploit.
In-the-wild exploitation: No confirmed mass exploitation at time of writing, but assume rapid weaponization. Kernel RCE PoCs historically get integrated into offensive tooling within days of publication.
CISA KEV: Not listed at time of writing. Monitor the CISA KEV catalog — if added, federal remediation deadlines will apply and every private-sector org should treat them as its own deadline.
CVE: Pending assignment per available reporting. Track the kernel.org and distro security trackers listed in the Remediation section for the formal identifier and fixed kernel versions.

Detection & Response

Detection strategy here is three-layered: (1) attack surface discovery — find MPTCP listeners before attackers do; (2) exploitation-attempt telemetry — kernel log anomalies caused by failed or noisy exploit attempts; (3) post-exploitation behavior — the root shell, reverse shell, or payload staging that follows a successful hit. The last layer is your most reliable catch, because it's behavior an attacker cannot avoid if they want to do anything useful with the access.

Sigma Rules

The first rule targets post-exploitation: a network-facing daemon spawning an interactive shell is almost never legitimate. The second catches the reverse-shell staging that typically follows a remote root landing. The third watches kernel logs for the crash artifacts that exploit attempts (successful or failed) frequently leave behind.

YAML

---
title: Network Daemon Spawning Interactive Shell
tid: 3f8a1c92-6d4b-4e7a-9b51-2c7f8e0a1d44
status: experimental
description: Detects network-facing service processes spawning shell interpreters, consistent with post-exploitation behavior after a remote code execution such as the MPTCP kernel flaw.
references:
  - https://www.bleepingcomputer.com/news/security/critical-linux-kernel-flaw-allows-remote-root-attacks-on-mptcp-servers/
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parents:
    ParentImage|endswith:
      - '/nginx'
      - '/apache2'
      - '/httpd'
      - '/haproxy'
      - '/envoy'
      - '/caddy'
      - '/mptcpd'
  selection_children:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
  condition: selection_parents and selection_children
falsepositives:
  - CGI scripts and legacy application plugins invoking shells
  - Configuration management agents running under a service account
level: high
---
title: Linux Reverse Shell Command Pattern
tid: 91c2e7b4-3a5f-4d68-8c1e-6b9d2f4a7e55
status: experimental
description: Detects common reverse shell command-line patterns used by attackers after gaining remote code execution on Linux hosts.
references:
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
  - attack.command_and_control
  - attack.t1571
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - 'bash -i'
      - '/dev/tcp/'
      - 'nc -e '
      - 'ncat -e '
      - 'nc -c /bin/'
      - 'socat exec'
      - 'mkfifo /tmp/'
  condition: selection
falsepositives:
  - Rare administrative use of /dev/tcp for connectivity testing
level: critical
---
title: Kernel Log Exploitation Artifacts
tid: 5d6e9a21-8f3c-4b7a-ae42-9c1d5f6b8e77
status: experimental
description: Detects kernel error signatures (oops, BUG, general protection fault, KASAN reports) that may indicate exploitation attempts against kernel memory corruption vulnerabilities such as the MPTCP flaw.
references:
  - https://www.bleepingcomputer.com/news/security/critical-linux-kernel-flaw-allows-remote-root-attacks-on-mptcp-servers/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  product: linux
  service: kern
detection:
  selection:
    Message|contains:
      - 'BUG:'
      - 'general protection fault'
      - 'kernel NULL pointer dereference'
      - 'KASAN:'
      - 'kernel panic'
      - 'Oops:'
  condition: selection
falsepositives:
  - Faulty hardware or unstable drivers on development systems
level: medium

KQL (Microsoft Sentinel / Defender)

These queries assume Linux syslog (including kernel logs) is flowing into Sentinel via the Syslog/CEF connector, and that Linux endpoints are onboarded to Defender for Endpoint. The first hunts kernel crash artifacts with MPTCP context; the second hunts daemon-spawned shells via Defender process telemetry.

KQL — Microsoft Sentinel / Defender

// Hunt 1: Kernel exploitation artifacts in Syslog, with MPTCP context
Syslog
| where TimeGenerated > ago(7d)
| where Facility == "kern"
| where SyslogMessage has_any ("BUG:", "general protection fault", "kernel NULL pointer", "KASAN:", "Oops:")
| extend MptcpContext = SyslogMessage has_any ("mptcp", "MPTCP", "subflow")
| project TimeGenerated, Computer, ProcessName, MptcpContext, SyslogMessage
| order by TimeGenerated desc;

// Hunt 2: Network daemons spawning shells on Linux endpoints (MDE)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("nginx", "apache2", "httpd", "haproxy", "envoy", "caddy", "mptcpd")
| where FileName has_any ("sh", "bash", "dash", "python", "python3", "perl")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;

// Hunt 3: Reverse shell staging patterns across Linux process telemetry
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where ProcessCommandLine has_any ("bash -i", "/dev/tcp/", "nc -e", "ncat -e", "socat exec")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, AccountName, InitiatingProcessFileName
| order by TimeGenerated desc;

Velociraptor VQL

This artifact does double duty: it enumerates the MPTCP attack surface on each endpoint (enabled sysctl + active MPTCP sockets) and surfaces root-owned shells spawned by network daemons. Run it across your Linux fleet as an emergency scoping hunt.

VQL — Velociraptor

-- Scope MPTCP attack surface and hunt post-exploitation shells
-- Part 1: Check whether MPTCP is enabled in the kernel
LET mptcp_enabled = SELECT * FROM execve(argv=["/sbin/sysctl", "-n", "net.mptcp.enabled"])

SELECT Fqdn,
       read_file(filename="/proc/sys/net/mptcp/enabled") AS MptcpEnabledRaw
FROM info()

-- Part 2: Enumerate active MPTCP sockets/listeners via ss
LET listeners = SELECT Stdout FROM execve(argv=["/usr/sbin/ss", "-MntapH"])
SELECT split(string=Stdout, sep="\n") AS MptcpSocket FROM listeners

-- Part 3: Hunt for shells parented by network daemons running as root
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ "^(sh|bash|dash|zsh)$"
  AND Username =~ "root"

If Part 1 returns 1 or the file read succeeds and Part 2 returns any sockets, that host is in the exploitation blast radius and jumps to the front of your patch queue. Part 3 results demand immediate triage — a root shell with a daemon lineage on an MPTCP-exposed host is a presumptive compromise until proven otherwise.

Emergency Scoping and Mitigation Script

Run this on every Linux host (or push it via your configuration management of choice). It inventories MPTCP exposure, applies the runtime mitigation, and stages the kernel update.

Bash / Shell

#!/bin/bash
# Emergency MPTCP kernel RCE scoping + mitigation script
# Security Arsenal — run as root on all Linux hosts

LOG=/var/log/mptcp_mitigation.log
echo "=== $(date) — MPTCP exposure assessment on $(hostname) ===" | tee -a "$LOG"

# 1. Check kernel version (record for patch baseline)
echo "[*] Kernel: $(uname -r)" | tee -a "$LOG"

# 2. Check if MPTCP is enabled in the running kernel
if [ -f /proc/sys/net/mptcp/enabled ]; then
  MPTCP_STATE=$(cat /proc/sys/net/mptcp/enabled)
  echo "[*] net.mptcp.enabled = $MPTCP_STATE" | tee -a "$LOG"
else
  echo "[*] net.mptcp.enabled sysctl not present (kernel < 5.19 or MPTCP not built)" | tee -a "$LOG"
fi

# 3. Enumerate active MPTCP sockets — any output here = exposed listener surface
echo "[*] Active MPTCP sockets:" | tee -a "$LOG"
ss -Mntap 2>/dev/null | tee -a "$LOG"

# 4. Identify processes using mptcpize or mptcpd
echo "[*] MPTCP-related processes:" | tee -a "$LOG"
ps aux | grep -Ei 'mptcpd|mptcpize' | grep -v grep | tee -a "$LOG"

# 5. RUNTIME MITIGATION: disable MPTCP socket creation immediately
if [ -f /proc/sys/net/mptcp/enabled ]; then
  sysctl -w net.mptcp.enabled=0 | tee -a "$LOG"
  echo 'net.mptcp.enabled=0' > /etc/sysctl.d/99-disable-mptcp.conf
  sysctl --system >/dev/null 2>&1
  echo "[+] MPTCP disabled persistently via /etc/sysctl.d/99-disable-mptcp.conf" | tee -a "$LOG"
fi

# 6. Check for kernel oops/BUG artifacts that may indicate exploitation attempts
echo "[*] Recent kernel error artifacts (potential exploit attempts):" | tee -a "$LOG"
journalctl -k --since "7 days ago" 2>/dev/null | grep -Ei 'BUG:|general protection fault|KASAN|Oops|NULL pointer' | tail -20 | tee -a "$LOG"
dmesg -T 2>/dev/null | grep -Ei 'BUG:|general protection fault|KASAN|Oops' | tail -10 | tee -a "$LOG"

# 7. Stage security kernel update (does NOT reboot — schedule that separately)
if command -v apt-get >/dev/null 2>&1; then
  apt-get update -qq && apt-get --only-upgrade install -y linux-image-$(uname -r) 2>>"$LOG" || \
  echo "[!] Check your distro security tracker for the fixed kernel version" | tee -a "$LOG"
elif command -v dnf >/dev/null 2>&1; then
  dnf update -y kernel --security 2>>"$LOG" || dnf update -y kernel 2>>"$LOG"
elif command -v zypper >/dev/null 2>&1; then
  zypper patch --category security -y 2>>"$LOG"
fi

echo "=== Done. Reboot required to load patched kernel: $(needs-restarting -r 2>/dev/null || echo 'verify manually') ===" | tee -a "$LOG"

Important caveat on the sysctl mitigation: setting net.mptcp.enabled=0 prevents new MPTCP sockets from being created — it does not tear down existing listeners, and it is only available on kernels 5.19+. If your applications genuinely depend on MPTCP, this mitigation will break them; in that case, your only safe path is the patched kernel plus network-level filtering (restrict which source IPs can reach the listener via host firewall or security groups) until the reboot completes.

Remediation

Patch the kernel — this is the only complete fix. Monitor and apply fixed kernel packages from your distribution's security channel the moment they ship:
- Kernel.org: https://www.kernel.org/ and the linux-stable mailing list
- Ubuntu Security Notices: https://ubuntu.com/security/notices
- Red Hat Security: https://access.redhat.com/security
- Debian Security Tracker: https://security-tracker.debian.org/
- Original reporting: BleepingComputer
Because the formal CVE assignment and fixed-version matrix are pending at time of writing, subscribe to your distro's security announce list today — do not rely on remembering to check back.
Disable MPTCP where it is not a business requirement. Most Linux servers have zero legitimate need for MPTCP listeners. Apply net.mptcp.enabled=0 persistently (see script above) and verify no mptcpize-wrapped workloads or mptcpd instances are in use before enforcing broadly.
Reduce network exposure of MPTCP listeners. Where MPTCP must remain enabled, restrict reachability to the listening ports via host firewall (nftables/iptables), security groups, or upstream ACLs so only known peers can complete the handshake. An unauthenticated flaw that can't be reached can't be exploited.
Reboot to the patched kernel and verify. A kernel update without a reboot leaves the vulnerable code running. Use needs-restarting -r (RHEL family) or check /var/run/reboot-required (Debian family) to confirm. If you use live patching (kpatch, kGraft, KernelCare, Ubuntu Livepatch), confirm your vendor has shipped a livepatch module covering this flaw — do not assume coverage.
Hunt retrospectively. Run the Sigma/KQL/VQL content above over at least the last 14 days of telemetry. Kernel RCEs with public PoCs get probed from the internet within hours of disclosure. Any host with both an exposed MPTCP listener and kernel error artifacts or daemon-spawned shells is a presumptive compromise — isolate it and start your IR process rather than patching in place.
Watch CISA KEV. If this vulnerability lands in the KEV catalog, treat the BOD 22-01 remediation deadline as your own, regardless of whether you're a federal agency. KEV listing means confirmed active exploitation — the patching conversation is over at that point.

The Bigger Lesson

This flaw is a reminder that kernel attack surface is a supply-and-configuration problem, not just a patching problem. MPTCP is exactly the kind of feature that ships enabled in modern kernels, gets exercised by a handful of niche workloads, and sits unexamined in the other 95% of the fleet — until a researcher demonstrates that it's remotely reachable and pre-auth. Every SOC should be able to answer, in under an hour: "Which of our hosts expose an MPTCP listener?" If you can't answer that today, you have an attack-surface inventory gap that will bite you on the next kernel CVE too. Build the query now; you'll use it again.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub