Multipath TCP (MPTCP) has recently drawn attention after a vulnerability was reported in its Linux implementation, identified as CVE-2026-98432. Rather than examining the vulnerability itself, this analysis focuses on how MPTCP works and how its use can be detected in network traffic.
Traditional TCP associates a connection with a specific pair of host IP addresses. That model can be problematic for mobile devices, which may move from Wi-Fi to cellular connectivity and otherwise need to re-establish connections. MPTCP addresses this limitation by allowing a connection to be split across, or transferred between, different IP addresses. It can also help servers use high-bandwidth links more effectively than a single TCP connection.
The most widely observed implementation is on iOS and iPadOS. IPv4 connections to Apple’s 17.0.0.0/8 address space often use MPTCP. The technology was initially used for Siri and was later extended to services including Apple Music.
Two MPTCP versions are currently defined and used: version 0 and version 1. MPTCP is identified by TCP option 30. The option includes a subtype and a version field, with several subtypes supporting connection negotiation and management.
MP_CAPABLE, subtype 0, indicates that both endpoints support MPTCP and must appear during the TCP handshake for the feature to be enabled. Each MP_CAPABLE option also carries an eight-byte key used later to identify and authenticate additional subflows.
MP_JOIN, subtype 1, allows another TCP connection to join the existing MPTCP connection. This subflow will usually be initiated by the client and may use a different IP address, although the specification also permits the server to initiate one. The ports are normally the same, but they do not have to be. DSS, or Data Sequence Signal, maps the sequence numbers of each individual TCP connection to the sequence numbers of the combined MPTCP connection.
The ADD_ADDR and REMOVE_ADDR subtypes advertise or withdraw additional addresses or ports that can be used for MPTCP subflows without directly establishing a new connection.
The most direct way to detect MPTCP is to search for TCP option 30. Wireshark supports this through its “mptcp” display filter. Tcpdump has no dedicated mechanism for matching TCP options, but MPTCP packets, especially SYN packets, often have large TCP headers; checking the TCP header length can therefore provide an indication, such as with the filter “tcp[12]>0xd0”.
Suricata can inspect TCP options with the “tcp.hdr” keyword. Option lengths vary, but an MP_CAPABLE message containing both sender and receiver keys should be 20 bytes long. Its first three bytes are “1e 14 00” for version 0 or “1e 14 01” for version 1.
Snort does not provide a keyword for inspecting TCP options and, according to the analysis, does not offer a specific way to filter for MPTCP. In Zeek, TCP options are not logged by default, but the tcp_option and tcp_options events can be used to record option 30 and identify communications that use MPTCP.
Sources: SANS Internet Storm Center.