CVE-2026-65819: GoPacket Library DoS Vulnerability

CVE-2026-65819 Overview

CVE-2026-65819 affects gopacket, a widely used Go library that provides packet processing capabilities. Through version 1.7.0, multiple layer decoders consume attacker-controlled lengths, counts, and offsets before validating them against the underlying packet buffer. A crafted packet processed through DecodingLayerParser or DecodeFromBytes triggers an out-of-bounds read [CWE-125] that raises an unrecovered panic. Applications that rely on gopacket to parse untrusted network traffic can be crashed remotely without authentication. The maintainers published a patch in commit 210f25f.

Critical Impact
Remote attackers can send a single malformed packet to crash any Go service that decodes traffic with gopacket ≤ 1.7.0, producing a denial-of-service condition.

Affected Products

gopacket library versions up to and including 1.7.0
Go applications using DecodingLayerParser on untrusted packet data
Go applications calling DecodeFromBytes on affected layer decoders (including DHCPv4 and Diameter)

Discovery Timeline

2026-08-07 - CVE-2026-65819 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-65819

Vulnerability Analysis

The flaw is an out-of-bounds read [CWE-125] rooted in missing bounds checks across several gopacket layer decoders. Each affected decoder reads a length, count, or offset field from the packet header and then indexes into the packet slice using that value. When the attacker-supplied value exceeds the remaining buffer or violates protocol constraints, the Go runtime raises a panic. Because gopacket does not recover the panic inside DecodingLayerParser or DecodeFromBytes, the goroutine — and typically the whole process — terminates. The vulnerability requires no authentication and no user interaction, and it is reachable over the network wherever gopacket parses attacker-influenced frames.

Root Cause

The decoders trust protocol-supplied length fields. In layers/dhcpv4.go, the code read data[2] as HardwareLen and later indexed data[28:28+HardwareLen] without verifying the value fits in the fixed 16-byte BOOTP chaddr field. In layers/diameter.go, MessageLength is a 24-bit header field used to slice AVPs at data[20:MessageLength]; values below 20 produced out-of-order slice bounds. Similar unchecked arithmetic exists in additional layer decoders reachable through the same parser entry points.

Attack Vector

An attacker delivers a crafted packet to any endpoint whose Go application feeds bytes into gopacket. Typical exposure includes network intrusion detection sensors, flow collectors, cloud-native traffic mirrors, and Kubernetes CNI plugins. The panic propagates unless the caller has installed its own recover() around every decode call, which is not the documented pattern.

// Patch excerpt: layers/dhcpv4.go — validate HardwareLen before slicing chaddr
d.Operation = DHCPOp(data[0])
d.HardwareType = LinkType(data[1])
d.HardwareLen = data[2]
if d.HardwareLen > 16 {
    // The BOOTP chaddr field is fixed at 16 bytes (data[28:44]); a larger
    // hardware length would read past it (and 28+HardwareLen wraps in uint8).
    return fmt.Errorf("DHCPv4 hardware address length %d exceeds 16", d.HardwareLen)
}
d.RelayHops = data[3]
d.Xid = binary.BigEndian.Uint32(data[4:8])
d.Secs = binary.BigEndian.Uint16(data[8:10])

// Patch excerpt: layers/diameter.go — enforce minimum message length
d.MessageLength = uint32(data[1])<<16 | uint32(data[2])<<8 | uint32(data[3])
if d.MessageLength < 20 {
    // The length includes the 20-byte header; a smaller value would make
    // the data[20:MessageLength] AVP slice below have out-of-order bounds.
    return fmt.Errorf("diameter message length %d below 20-byte header", d.MessageLength)
}
if uint32(len(data)) < d.MessageLength {
    return fmt.Errorf("diameter message truncated: expected %d bytes, got %d", d.MessageLength, len(data))
}

Source: gopacket commit 210f25f

Detection Methods for CVE-2026-65819

Indicators of Compromise

Repeated runtime error: slice bounds out of range or index out of range panics in Go application logs originating from github.com/gopacket/gopacket/layers.
Sudden process restarts or crash loops on services that parse mirrored, captured, or ingested network traffic.
Malformed DHCPv4 frames with HardwareLen > 16 or Diameter messages with a header Message-Length below 20.

Detection Strategies

Inventory Go binaries for a dependency on github.com/google/gopacket or github.com/gopacket/gopacket at version v1.7.0 or earlier using go version -m or SBOM tooling.
Alert on process termination followed by immediate respawn for network-facing Go services, which is the observable signature of a decoder panic.
Deploy protocol validation at the network edge to drop DHCPv4 and Diameter frames whose length fields violate the protocol minimums shown in the patch.

Monitoring Recommendations

Forward stderr and panic traces from gopacket-based services to a centralized logging pipeline and match on the gopacket/layers stack frames.
Track packet-parser crash rate as a service-level indicator so a spike from a crafted packet flood is visible within minutes.
Baseline Diameter and DHCPv4 volumes on segments where those protocols are not expected, and alert on any appearance.

How to Mitigate CVE-2026-65819

Immediate Actions Required

Upgrade gopacket to the version containing commit 210f25f or later; rebuild and redeploy all Go binaries that link it.
Rebuild transitive dependents — many observability, IDS, and CNI projects vendor gopacket and require their own release to ship the fix.
Restrict which network segments can reach services that decode untrusted traffic until patched builds are in production.

Patch Information

The fix is available in gopacket upstream commit 210f25f and is tracked in GitHub Security Advisory GHSA-8mcr-459q-5mx2. Baseline release information is available at gopacket v1.7.0; users must move past this release to a build containing the merged patch.

Workarounds

Wrap all calls to DecodingLayerParser.DecodeLayers and DecodeFromBytes in a defer/recover block so a decoder panic is contained to the offending packet rather than the process.
Disable unused layer decoders (for example DHCPv4 or Diameter) in the parser configuration when those protocols are not expected on the wire.
Front the parser with a strict allowlist that validates protocol length fields before handing bytes to gopacket.

bash

# Verify the linked gopacket version in a compiled Go binary
go version -m ./your-service | grep gopacket

# Update to a patched revision and rebuild
go get github.com/gopacket/gopacket@210f25fb9b3ca1af2eb649936f78ad6991b6c9c5
go mod tidy
go build ./...