CVE-2026-54345

What it actually does

In gopacket 1.6.0 and earlier, the Diameter AVP decoder trusts an attacker-controlled AVP Length value. When the AVP has the vendor-specific flag set but declares a Length smaller than the 12-byte vendor AVP header, unsigned integer subtraction underflows and produces a very large data length, leading the decoder to attempt an allocation of roughly 4 GiB. Repeated malformed Diameter messages can exhaust memory and cause packet collectors, analyzers, probes, or other Go services using the vulnerable decoder to be killed or restarted. The impact is unauthenticated remote denial of service; the issue does not directly provide code execution or data disclosure.

Why it matters to the business

Systems that inspect or process Diameter traffic using vulnerable gopacket versions can be taken offline by malformed network packets, causing loss of telecom/core-network visibility, monitoring gaps, degraded detection capability, or service instability. Although EPSS is currently low and there is no known CISA KEV listing or reported ransomware use, exploitation is simple, unauthenticated, and network-reachable where Diameter traffic can reach a vulnerable parser, so exposed collectors and monitoring pipelines should be updated promptly.

How an attack unfolds

An attacker sends a crafted Diameter packet to a service or sensor that parses Diameter traffic with gopacket 1.6.0 or earlier. The packet contains a vendor-flagged AVP whose declared Length is less than the required 12-byte header. During decoding, the parser subtracts the fixed header size from the supplied Length using an unsigned 32-bit value, causing an underflow to a very large number. The application then attempts to allocate memory based on that computed length. One malformed message can create severe memory pressure, and two consecutive messages may be enough to trigger the operating system OOM killer or crash/restart the process, interrupting packet processing or dependent service functionality.

How to fix it

Upgrade gopacket to version 1.6.1 or later in all applications, collectors, agents, and packet-processing tools that decode Diameter traffic. If gopacket is vendored or included transitively, rebuild and redeploy affected binaries after dependency updates. As interim mitigation, restrict Diameter traffic ingestion to trusted sources, filter malformed Diameter AVPs at network boundaries where feasible, enforce memory limits and supervised restarts for packet-processing services, and isolate monitoring components so a parser crash does not affect production control-plane services.

How to confirm the fix worked

Confirm that all built artifacts use gopacket 1.6.1 or later by checking Go module manifests, lock files, software bills of materials, and compiled binary dependency metadata where available. Run `go list -m all | grep github.com/google/gopacket` in source trees and verify the resolved version is not 1.6.0 or earlier. For vendored dependencies, inspect `vendor/modules.txt` and module checksums. Validate runtime exposure by identifying services that listen for, capture, mirror, or decode Diameter traffic, commonly over TCP or SCTP port 3868. Where safe and authorized, use a regression test with a malformed vendor-specific Diameter AVP Length below 12 bytes to confirm the service rejects the packet without excessive allocation, crash, restart, or OOM event.

Typical attack path

1. Identify a host, collector, probe, or application that receives Diameter traffic and uses gopacket for packet decoding.
2. Send a Diameter message containing a vendor-specific AVP with the vendor flag set and an AVP Length value smaller than 12 bytes.
3. Trigger the vulnerable unsigned length calculation in the Diameter AVP decoder.
4. Force the process to attempt an allocation of approximately 4 GiB.
5. Repeat the malformed message if needed to exhaust memory and cause an OOM kill, crash, or service restart.

How to detect it

Look for evidence of denial-of-service rather than data theft. Review system logs, container runtime events, supervisor logs, and application logs for OOM kills, abrupt restarts, memory allocation failures, or crashes in processes that use gopacket or decode Diameter traffic. Correlate these events with inbound Diameter traffic, especially TCP/SCTP port 3868, and inspect packet captures or flow logs for malformed Diameter AVPs where the vendor-specific flag is set and the AVP Length is less than 12 bytes. In Kubernetes or containerized environments, review pod termination reasons, restart counts, exit code 137, and node OOM events. In host environments, review kernel logs, journald, syslog, dmesg, and service manager logs for OOM-killer activity around packet collector processes. Because the exploit can be delivered as a small malformed packet and may not leave an application-level trace, packet capture, NetFlow, and memory/restart telemetry are the most useful evidence sources.

• Diameter traffic on TCP port 3868 immediately preceding process OOM or restart
• Diameter traffic on SCTP port 3868 immediately preceding process OOM or restart
• Vendor-specific Diameter AVP with AVP Length < 12
• Diameter AVP flags containing Vendor-Specific bit set with invalid short Length field
• Out of memory: Killed process
• oom-kill
• Memory cgroup out of memory
• Killed process
• exit code 137
• OOMKilled
• github.com/google/gopacket v1.6.0
• github.com/google/gopacket v1.5.
• github.com/google/gopacket v1.4.

What your security team should do

• Inventory all Go applications, network sensors, telecom probes, packet collectors, and monitoring tools that depend on gopacket or process Diameter traffic.
• Prioritize upgrading exposed Diameter parsers and high-availability monitoring components to gopacket 1.6.1 or later.
• Rebuild and redeploy statically linked Go binaries after updating the dependency; updating source alone is not sufficient.
• Add dependency/SBOM checks to CI to block gopacket 1.6.0 and earlier.
• Restrict Diameter packet ingestion to expected peers and management networks; block unsolicited Diameter traffic from untrusted networks.
• Monitor for OOM kills, unexpected restarts, memory spikes, and malformed Diameter parsing errors on packet-processing systems.
• Ensure affected services have resource limits, health checks, and restart policies so a denial-of-service attempt does not create prolonged monitoring blind spots.