CVE-2017-13766 is a protocol-parsing vulnerability in Wireshark: the Profinet I/O dissector can perform an out-of-bounds write when it processes a malformed packet, crashing the application. If you run Wireshark on the affected releases and open a capture containing hostile Profinet I/O traffic, the tool can be forced into a denial-of-service state. The flaw was disclosed on August 29, 2017 and carries a CVSS 3.0 base score of 5.9.
The reason this one is worth understanding is that it sits at the seam between a widely used network-analysis tool and an industrial control protocol. Wireshark is often the first thing an engineer reaches for when a plant network misbehaves, and Profinet is the exact traffic they would be inspecting. A parsing bug in that path is more than an abstract memory-safety note.
What the vulnerability actually is
Wireshark understands hundreds of protocols through code called dissectors. A dissector reads raw bytes off the wire and decodes them into the human-readable fields you see in the packet detail pane. The Profinet I/O dissector lives in plugins/profinet/packet-dcerpc-pn-io.c.
In the affected versions, that dissector did not fully validate a string field before writing to a buffer. A crafted packet could push the write past the end of the allocated space, an out-of-bounds write. In practice the observable result is a crash rather than reliable code execution, which is why the impact is classified as denial of service and the score lands at medium rather than critical. The upstream fix simply added string validation before the write.
Affected versions
The flaw affects:
- Wireshark 2.4.0
- Wireshark 2.2.0 through 2.2.8
If you are on the 2.2.x branch at 2.2.9 or later, or on the 2.4.x branch at 2.4.1 or later, you have the corrected dissector. Anything older on those lines is exposed. You can check your build quickly:
wireshark --version
# or, for the terminal capture tool
tshark --version
Do not assume a distribution package matches upstream numbering exactly. Long-term Linux distributions frequently backport the fix while keeping the old version string, so also check your vendor's advisory. Red Hat, SUSE, and Debian all tracked this CVE against their Wireshark packages.
How an attacker reaches it
The uncomfortable part of protocol-dissector bugs is that you often trigger them yourself. There are two realistic paths:
The first is live capture. If an analyst is sniffing a segment that carries Profinet I/O traffic and an attacker (or a broken device) injects a malformed frame, Wireshark parses it automatically and crashes. No click required.
The second is a saved capture file. Someone hands you a .pcap or .pcapng to analyze, it contains the crafted packet, and opening it triggers the write. This is the classic "analyze the evidence, become the victim" pattern that makes tooling bugs in incident-response software especially annoying.
Because Profinet is an industrial protocol, the blast radius is usually an OT or plant network. The direct consequence is that your visibility tool goes down at the exact moment you need it.
Fixing and mitigating it
The clean fix is an upgrade. Move to a patched build:
# Debian / Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade wireshark
# RHEL / Fedora
sudo dnf upgrade wireshark
# macOS (Homebrew)
brew upgrade wireshark
If you cannot upgrade immediately, you can reduce exposure by disabling the Profinet dissector so Wireshark does not attempt to parse that traffic. Under Analyze -> Enabled Protocols, clear the pn_io entry, or pass a disabled-protocols configuration to tshark. You lose Profinet decoding, but you close the specific path.
Treat capture files from untrusted sources the way you would any untrusted input. Analyzing them inside a disposable virtual machine is cheap insurance, and it contains the fallout of any dissector bug, not just this one.
Why dissector bugs keep happening
Wireshark parses attacker-controlled bytes across an enormous surface, much of it written in C, much of it contributed by volunteers who specialize in one protocol. That combination produces a steady stream of memory-safety advisories over the years. CVE-2017-13766 is one entry in a long list, and the pattern is almost always the same shape: a field is read from the wire, a length or bound is trusted that should not be, and a read or write steps outside its buffer.
The lesson for anyone shipping software that parses network protocols is that untrusted input validation cannot be an afterthought. If your own product embeds packet parsers, protocol codecs, or file-format readers, the same class of bug applies to you. Static and composition analysis help here: an SCA tool will tell you when a vulnerable version of a parsing library is pulled in transitively, and dynamic testing exercises the parser with malformed input. If you want a grounding in how these testing types differ, the Academy walks through it.
Tracking it in your environment
For an inventory-driven approach, map where Wireshark and tshark are installed. Analyst laptops, jump boxes, and OT monitoring appliances are the usual homes. Pin a minimum version in your configuration management, and add the version check to your patch-compliance scan so a stale build gets flagged automatically rather than discovered during an incident.
If Wireshark is bundled inside a larger appliance or container image, a software bill of materials makes the embedded version visible. Without an SBOM, a vulnerable dissector inside a vendor appliance is effectively invisible until someone finds it the hard way.
FAQ
Is CVE-2017-13766 remotely exploitable for code execution?
It is characterized as a denial-of-service issue. A crafted Profinet I/O packet triggers an out-of-bounds write that crashes Wireshark. The public record treats the practical impact as a crash rather than reliable remote code execution, which is reflected in its medium CVSS 3.0 score of 5.9.
Which Wireshark versions fix it?
Upgrade to 2.2.9 or later on the 2.2 branch, or 2.4.1 or later on the 2.4 branch. The fix added string validation in the Profinet I/O dissector.
I only open capture files, am I safe?
No. Opening a saved capture that contains the malformed packet triggers the same dissector path as live capture. Upgrade, and analyze untrusted captures in an isolated environment.
How do I check whether my build is affected?
Run wireshark --version or tshark --version. Compare against the patched versions, and also check your distribution's advisory, since long-term releases often backport the fix while keeping an older version string.