Back to Intelligence

ZDI-26-898: Wireshark LoRaWAN Decryption Vulnerability — Detection and Mitigation Guide for Security Teams

SA
Security Arsenal Team
November 10, 2026
12 min read

The Zero Day Initiative has published ZDI-26-898, a numeric truncation vulnerability in Wireshark's LoRaWAN decryption dissector that enables network-adjacent attackers to execute arbitrary code — no authentication required. With a CVSS score of 7.1, this vulnerability sits squarely in the "high" band and warrants immediate action from any organization whose analysts, incident responders, or IoT security teams use Wireshark to inspect LoRaWAN traffic.

Wireshark holds a uniquely privileged position in most security operations. Analysts run it with elevated privileges to capture traffic. It processes untrusted network data by design. And in environments where IoT/OT security assessments are routine — manufacturing floors, smart building deployments, utility telemetry — LoRaWAN dissection is a common workflow. That combination makes this vulnerability a meaningful risk, not a theoretical one.

The exploitation scenario is straightforward: an attacker on an adjacent network segment crafts malicious LoRaWAN packets. If a target system running Wireshark has LoRaWAN decryption enabled and processes that traffic — whether from a live capture or a crafted capture file — the numeric truncation error is triggered, and arbitrary code executes in the context of the Wireshark process. No user interaction beyond opening the capture or enabling decryption is required.

Technical Analysis

Affected Product and Component

  • Product: Wireshark (the open-source network protocol analyzer)
  • Affected Component: LoRaWAN protocol dissector with decryption enabled
  • Advisory: ZDI-26-898
  • CVSS 3.1 Score: 7.1 (High)
  • Attack Vector: Network-adjacent (AV:A)
  • Authentication Required: None
  • User Interaction: Required — the target must be running Wireshark with LoRaWAN decryption enabled and must process attacker-controlled traffic

Vulnerability Class: Numeric Truncation Error (CWE-197)

A numeric truncation error occurs when a value is stored or processed in a data type that is too small to represent it, causing the value to be silently truncated. In the context of a protocol dissector, this typically manifests during length calculations, buffer allocations, or offset arithmetic when parsing variable-length protocol fields.

In LoRaWAN, the decryption process involves handling cryptographic payloads with length fields that can vary depending on the MAC layer version, frame type, and payload encoding. If the dissector reads a length value from the packet into a data type with insufficient width — for example, casting a 32-bit value to a 16-bit integer — the truncated value may be used for a subsequent buffer allocation or copy operation. The result is a heap-based buffer overflow or out-of-bounds read/write condition, which a skilled attacker can leverage for code execution.

Attack Chain

  1. Attacker positions on an adjacent network segment — this could be a shared wireless network, a corporate LAN, or any segment where the target analyst's Wireshark instance might capture traffic.
  2. Attacker crafts malicious LoRaWAN frames — specifically constructed to trigger the numeric truncation condition in the dissector's decryption logic.
  3. Target analyst opens a capture or processes live traffic — the crafted packets must pass through the LoRaWAN dissector with decryption enabled. This can occur via live capture on the adjacent network or by tricking the analyst into opening a crafted .pcap or .pcapng file.
  4. Numeric truncation triggers memory corruption — the truncation error causes the dissector to miscalculate buffer boundaries, enabling arbitrary code execution in the context of the Wireshark process.

Why "LoRaWAN Decryption Enabled" Matters

The vulnerability is not in the base LoRaWAN dissector — it is specifically in the decryption path. Wireshark's LoRaWAN dissector supports decrypting AES-128 encrypted payloads when session keys (AppSKey/NwkSKey) are provided in the protocol preferences. This decryption code path is only executed when:

  • LoRaWAN decryption is enabled in Wireshark preferences
  • Appropriate session keys have been configured

This significantly narrows the attack surface. Standard LoRaWAN dissection without decryption enabled is not affected. However, any team performing IoT security assessments, LoRaWAN penetration testing, or OT network monitoring where decryption is configured is directly in the blast radius.

Exploitation Status

As of this writing, there are no confirmed reports of in-the-wild exploitation. The vulnerability was disclosed through the Zero Day Initiative's coordinated disclosure process, which means the vendor (the Wireshark Foundation) was given time to develop a patch before public disclosure. No public proof-of-concept exploit has been published. The vulnerability is not currently listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

That said, ZDI advisories include enough technical detail for skilled researchers to develop working exploits. The window between public disclosure and weaponization is consistently shrinking. Organizations should treat this as a pre-weaponization vulnerability and act accordingly.

Detection & Response

Sigma Rules

The detection strategy for this vulnerability focuses on two observable behaviors: Wireshark spawning unexpected child processes (a strong indicator of successful exploitation) and the presence of suspicious capture files in common analyst locations.

YAML
---
title: Wireshark Process Spawning Unexpected Child Process
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: Detects Wireshark or tshark spawning unexpected child processes, which may indicate successful exploitation of a dissector vulnerability such as ZDI-26-898.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-898/
author: Security Arsenal
date: 2026/02/11
tags:
  - attack.execution
  - attack.t1203
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\wireshark.exe'
      - '\tshark.exe'
      - '\dumpcap.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\msiexec.exe'
      - '\wmic.exe'
      - '\schtasks.exe'
      - '\net.exe'
      - '\net1.exe'
      - '\curl.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Wireshark extcap plugins that legitimately invoke scripts
  - Custom dissector development environments
level: high
---
title: Tshark or Dumpcap Execution from Unusual Parent Process
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: Detects tshark or dumpcap being invoked by a parent process other than Wireshark GUI, which may indicate post-exploitation use of packet capture tools or lateral movement.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-898/
author: Security Arsenal
date: 2026/02/11
tags:
  - attack.discovery
  - attack.t1040
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\tshark.exe'
      - '\dumpcap.exe'
  filter_legitimate:
    ParentImage|endswith:
      - '\wireshark.exe'
      - '\explorer.exe'
      - '\cmd.exe'
  condition: selection and not filter_legitimate
falsepositives:
  - Automated network monitoring scripts
  - CI/CD pipeline network validation
level: medium
---
title: Suspicious Capture File Dropped in User Directory
id: c3d4e5f6-a7b8-9012-cdef-123456789012
status: experimental
description: Detects creation of packet capture files in user directories by non-Wireshark processes, which may indicate delivery of a crafted capture file designed to exploit ZDI-26-898.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-898/
author: Security Arsenal
date: 2026/02/11
tags:
  - attack.initial_access
  - attack.t1566
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|endswith:
      - '.pcap'
      - '.pcapng'
      - '.cap'
  filter_legitimate:
    Image|endswith:
      - '\wireshark.exe'
      - '\tshark.exe'
      - '\dumpcap.exe'
      - '\tcpdump.exe'
  condition: selection and not filter_legitimate
falsepositives:
  - Network management tools exporting capture files
  - SIEM agents collecting network artifacts
level: medium

KQL (Microsoft Sentinel / Defender)

The following query hunts for Wireshark or tshark spawning child processes that are commonly associated with post-exploitation activity. This is the highest-fidelity behavioral indicator for successful dissector exploitation.

KQL — Microsoft Sentinel / Defender
// Hunt for Wireshark/tshark spawning suspicious child processes
// Relevant to ZDI-26-898 exploitation detection
let suspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe", "msiexec.exe", "wmic.exe", "schtasks.exe", "net.exe", "curl.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("wireshark.exe", "tshark.exe", "dumpcap.exe")
| where FileName has_any (suspiciousChildren)
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256, FolderPath
| order by TimeGenerated desc

For organizations ingesting Syslog from Linux endpoints where Wireshark or tshark is used (common in SOC environments), the following query covers the same behavior:

KQL — Microsoft Sentinel / Defender
// Hunt for tshark/dumpcap spawning shells or interpreters on Linux
// Requires Syslog ingestion into Sentinel
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("tshark", "dumpcap", "wireshark")
| where SyslogMessage has_any ("bash", "sh -c", "python", "perl", "nc ", "ncat", "socat", "wget", "curl")
| project TimeGenerated, HostName, ProcessName, SyslogMessage
| order by TimeGenerated desc

Velociraptor VQL

This VQL artifact hunts for Wireshark-related processes with unexpected child processes across the fleet, providing a forensic sweep capability for IR teams.

VQL — Velociraptor
-- Hunt for Wireshark/tshark processes with suspicious child processes
-- Relevant to ZDI-26-898 post-exploitation detection

LET wireshark_procs = SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)wireshark|tshark|dumpcap'

LET suspicious_children = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM wireshark_procs)
  AND Name =~ '(?i)cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|certutil|bash|sh|python|perl'

SELECT Pid AS ChildPid,
       Ppid AS ParentPid,
       Name AS ChildName,
       Exe AS ChildPath,
       CommandLine AS ChildCmdLine,
       Username AS ChildUser,
       CreateTime AS ChildStartTime
FROM suspicious_children

Remediation Script

The following PowerShell script audits Windows endpoints for Wireshark installations, checks whether LoRaWAN decryption preferences are configured, and provides guidance on disabling decryption as an interim mitigation.

PowerShell
#Requires -RunAsAdministrator
# ZDI-26-898: Wireshark LoRaWAN Decryption Vulnerability Audit Script
# Run on endpoints to identify at-risk Wireshark installations

Write-Host "[+] ZDI-26-898 Wireshark LoRaWAN Vulnerability Audit" -ForegroundColor Cyan
Write-Host "=======================================================" -ForegroundColor Cyan

# Check for Wireshark installation
$wiresharkPaths = @(
    "$env:ProgramFiles\Wireshark\wireshark.exe",
    "${env:ProgramFiles(x86)}\Wireshark\wireshark.exe"
)

$wiresharkInstalled = $false
$wiresharkVersion = $null

foreach ($path in $wiresharkPaths) {
    if (Test-Path $path) {
        $wiresharkInstalled = $true
        $fileInfo = Get-Item $path
        $wiresharkVersion = $fileInfo.VersionInfo.ProductVersion
        Write-Host "`n[!] Wireshark found: $path" -ForegroundColor Yellow
        Write-Host "    Version: $wiresharkVersion" -ForegroundColor Yellow
        break
    }
}

if (-not $wiresharkInstalled) {
    Write-Host "`n[+] Wireshark not detected on this system." -ForegroundColor Green
    exit 0
}

# Check for LoRaWAN decryption configuration in preferences
$prefPaths = @(
    "$env:APPDATA\Wireshark\preferences",
    "$env:APPDATA\Wireshark\profiles\*\preferences"
)

$lorawanFound = $false

foreach ($prefPath in $prefPaths) {
    $files = Get-ChildItem -Path $prefPath -ErrorAction SilentlyContinue
    foreach ($file in $files) {
        $content = Get-Content $file.FullName -Raw -ErrorAction SilentlyContinue
        if ($content -match 'lorawan') {
            Write-Host "`n[!] LoRaWAN configuration found in: $($file.FullName)" -ForegroundColor Red
            $lorawanLines = ($content -split "`n") | Where-Object { $_ -match 'lorawan' }
            foreach ($line in $lorawanLines) {
                Write-Host "    $($line.Trim())" -ForegroundColor Red
            }
            $lorawanFound = $true
        }
    }
}

if (-not $lorawanFound) {
    Write-Host "`n[+] No LoRaWAN decryption configuration detected in preferences." -ForegroundColor Green
} else {
    Write-Host "`n[!] ACTION REQUIRED: LoRaWAN decryption is configured on this system." -ForegroundColor Red
    Write-Host "    This system is potentially vulnerable to ZDI-26-898." -ForegroundColor Red
    Write-Host "    Mitigation steps:" -ForegroundColor Yellow
    Write-Host "      1. Update Wireshark to the latest patched version immediately." -ForegroundColor Yellow
    Write-Host "      2. If patching is not possible, disable LoRaWAN decryption:" -ForegroundColor Yellow
    Write-Host "         Edit > Preferences > Protocols > LoRaWAN > Uncheck decryption options" -ForegroundColor Yellow
    Write-Host "      3. Avoid opening untrusted capture files until patched." -ForegroundColor Yellow
}

# Check for running Wireshark processes
$wiresharkProcs = Get-Process -Name "wireshark","tshark","dumpcap" -ErrorAction SilentlyContinue
if ($wiresharkProcs) {
    Write-Host "`n[!] Wireshark processes currently running:" -ForegroundColor Yellow
    foreach ($proc in $wiresharkProcs) {
        Write-Host "    $($proc.ProcessName) (PID: $($proc.Id)) - Started: $($proc.StartTime)" -ForegroundColor Yellow
    }
}

Write-Host "`n[+] Audit complete." -ForegroundColor Cyan

For Linux systems where tshark or Wireshark CLI tools are deployed (common on network monitoring sensors):

Bash / Shell
#!/usr/bin/env bash
# ZDI-26-898: Wireshark LoRaWAN Vulnerability Audit for Linux
# Checks for Wireshark/tshark installation and LoRaWAN decryption configuration

echo "[+] ZDI-26-898 Wireshark LoRaWAN Vulnerability Audit"
echo "======================================================="

# Check for tshark/wireshark installation
if command -v tshark &>/dev/null; then
    TSHARK_VERSION=$(tshark --version 2>/dev/null | head -1)
    echo ""
    echo "[!] tshark found: $(which tshark)"
    echo "    Version: $TSHARK_VERSION"
else
    echo "[+] tshark not detected on this system."
    exit 0
fi

if command -v wireshark &>/dev/null; then
    echo "[!] wireshark GUI found: $(which wireshark)"
fi

# Check user preference files for LoRaWAN configuration
FOUND=0
for userhome in /root /home/*; do
    PREF_FILE="$userhome/.config/wireshark/preferences"
    if [ -f "$PREF_FILE" ]; then
        LORAWAN_LINES=$(grep -i 'lorawan' "$PREF_FILE" 2>/dev/null)
        if [ -n "$LORAWAN_LINES" ]; then
            echo ""
            echo "[!] LoRaWAN configuration found in: $PREF_FILE"
            echo "$LORAWAN_LINES" | while IFS= read -r line; do
                echo "    $line"
            done
            FOUND=1
        fi
    fi
done

if [ "$FOUND" -eq 0 ]; then
    echo ""
    echo "[+] No LoRaWAN decryption configuration detected."
else
    echo ""
    echo "[!] ACTION REQUIRED: LoRaWAN decryption is configured."
    echo "    Update Wireshark to the latest patched version immediately."
    echo "    If patching is not possible, remove or comment out LoRaWAN"
    echo "    key/decryption entries from the preferences file."
fi

echo ""
echo "[+] Audit complete."

Remediation

Immediate Actions

  1. Update Wireshark to the latest patched release. The Wireshark Foundation typically releases patched versions alongside or shortly after ZDI disclosure. Check the official Wireshark security advisories page at https://www.wireshark.org/security/ for the specific patched version number. Upgrade all instances — analyst workstations, jump boxes, network monitoring sensors running tshark — without exception.

  2. Disable LoRaWAN decryption as an interim mitigation. If patching cannot be performed immediately, disable LoRaWAN decryption in Wireshark: navigate to Edit > Preferences > Protocols > LoRaWAN and remove any configured session keys or disable decryption options. This eliminates the vulnerable code path entirely. The base LoRaWAN dissector (without decryption) is not affected.

  3. Restrict Wireshark privileges. Wireshark should never run as root on Linux or with elevated privileges on Windows beyond what is strictly necessary for packet capture. Use dumpcap with appropriate capabilities (setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap) on Linux and Npcap's restricted capture driver mode on Windows. If exploitation succeeds, the impact is constrained by the privilege context of the process.

  4. Implement network segmentation for IoT/OT environments. The attack requires network adjacency. Ensure that LoRaWAN gateway traffic and the analyst workstations used for IoT security assessment are on separate, controlled network segments. Use dedicated capture appliances or SPAN ports rather than running Wireshark directly on analyst workstations connected to general-purpose networks.

  5. Treat capture files as untrusted input. Establish and enforce a policy that .pcap and .pcapng files from external sources — vendor submissions, threat intel feeds, email attachments — are opened only in isolated environments (dedicated VMs with no network access) until the Wireshark installation is confirmed patched.

Medium-Term Hardening

  • Deploy application allowlisting on analyst workstations to prevent unauthorized child processes from executing under the Wireshark process context, even if a dissector vulnerability is exploited.
  • Enable exploit mitigations — ensure ASLR, DEP/NX, and stack canaries are active on all systems running Wireshark. On Windows, verify that Wireshark binaries are compiled with /DYNAMICBASE and /NXCOMPAT (use Get-PEHeader or similar tools to verify).
  • Add Wireshark version tracking to your asset inventory. Wireshark's dissector model means it will continue to be a recurring source of vulnerabilities. Your vulnerability management program should track Wireshark versions across all endpoints and flag any instance more than one minor release behind.
  • Subscribe to Wireshark security announcements at https://www.wireshark.org/lists/ and ZDI's upcoming advisories feed to receive early notification of future dissector vulnerabilities.

Related Resources

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

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.