CVE-2026-54332

What it actually does

gopacket version 1.6.0 and earlier contains an uncontrolled memory allocation flaw in the sFlow ExtendedGatewayFlow decoder. When parsing an sFlow datagram, the decoder trusts attacker-controlled 32-bit values for the BGP community count and AS path member count and uses those values to size Go slice allocations before validating that enough bytes remain in the packet. A small unauthenticated UDP packet can therefore cause a process using the vulnerable decoder to attempt a very large allocation, potentially up to approximately 16 GiB, leading to memory exhaustion, process termination, container restart, or host-level resource pressure.

Why it matters to the business

Applications, sensors, collectors, monitoring platforms, network analytics tools, and security products that parse untrusted sFlow traffic using vulnerable gopacket versions may be remotely crashed or degraded without authentication. The likely consequence is loss of network visibility or interruption of services that depend on packet decoding. The current EPSS score is low and there is no known CISA KEV listing or ransomware association, but the issue is recent, remotely reachable, and simple to trigger in exposed sFlow parsing services, so externally reachable or high-availability monitoring components should be prioritized.

How an attack unfolds

An attacker identifies a service, collector, appliance, or application that accepts sFlow UDP datagrams and uses gopacket 1.6.0 or earlier to decode them. The attacker sends a crafted sFlow datagram containing an ExtendedGatewayFlow structure with inflated count fields for communities or AS path members. During parsing, the vulnerable decoder allocates memory based on those counts before checking whether the datagram actually contains the corresponding data. The allocation request can exhaust available memory or trigger the Go runtime out-of-memory behavior, causing the affected process to crash or become unavailable. Repeated packets can sustain a denial-of-service condition until the service is patched, filtered, restarted with mitigations, or isolated from untrusted traffic.

How to fix it

Upgrade gopacket to version 1.6.1 or later in all applications, agents, collectors, appliances, and services that parse sFlow data. If gopacket is vendored or statically linked into Go binaries, rebuild and redeploy those binaries after updating the dependency. Where immediate upgrade is not possible, restrict sFlow ingestion to trusted network devices, block or filter untrusted UDP traffic to sFlow listeners, apply rate limits, and isolate collectors from the public internet and untrusted networks. Consider running affected parsers with memory limits and supervised restarts as a temporary containment measure, but do not treat resource limits as a full fix.

How to confirm the fix worked

Confirm dependency inventories, SBOMs, go.mod, go.sum, vendor manifests, and built artifact metadata show github.com/google/gopacket at version 1.6.1 or later. For statically linked Go applications, verify that the deployed binary was rebuilt after the dependency update rather than only updating source files. Confirm that exposed services only accept sFlow traffic from authorized network devices and that UDP port 6343, or any custom sFlow ingestion port, is not reachable from untrusted networks. In staging, validate that malformed or truncated sFlow datagrams are rejected without abnormal memory growth or process termination. Monitor memory use and restart counts after deployment to ensure the denial-of-service condition is no longer reproducible.

Typical attack path

1. Identify an exposed UDP service that receives or processes sFlow traffic, commonly on UDP port 6343 or an application-specific listener.
2. Confirm the target uses software built with gopacket version 1.6.0 or earlier, either through product versioning, software bill of materials, dependency disclosure, or behavioral testing.
3. Send a malformed sFlow datagram containing an ExtendedGatewayFlow record with excessively large attacker-controlled count fields.
4. Trigger excessive slice allocation in the vulnerable decoder before packet-length validation occurs.
5. Cause process memory exhaustion, crash, restart loop, degraded collector performance, or loss of packet-processing capability.
6. Optionally repeat the traffic to maintain service disruption until network filtering, rate limiting, or an upgrade is applied.

How to detect it

Review network telemetry, packet captures, firewall logs, load balancer logs, host logs, container runtime events, and application logs for crashes or memory exhaustion correlated with inbound sFlow UDP traffic. Focus on services receiving UDP sFlow traffic, commonly UDP/6343, and look for small malformed datagrams followed by abrupt memory growth, Go runtime out-of-memory messages, process exits, Kubernetes OOMKilled events, systemd restarts, or collector availability gaps. Because exploitation may leave no durable file artifact, correlation is important: suspicious inbound UDP datagrams to an sFlow listener immediately preceding memory exhaustion or process termination are the strongest signal. If packet captures are available, inspect for sFlow datagrams containing ExtendedGatewayFlow records with implausibly large community or AS path count fields relative to the packet length. Also review dependency and deployment logs to distinguish exploitation from ordinary crashes in services still using gopacket 1.6.0 or earlier.

• UDP/6343
• fatal error: runtime: out of memory
• runtime: out of memory
• signal: killed
• OOMKilled
• Out of memory: Killed process
• Memory cgroup out of memory
• github.com/google/gopacket v1.6.0
• github.com/google/gopacket v1.5
• layers/sflow.go
• ExtendedGatewayFlow
• sFlow
• sflow

What your security team should do

• Identify all products, internal services, agents, collectors, and Go binaries that include gopacket 1.6.0 or earlier, especially those that parse sFlow from a network socket.
• Prioritize remediation for internet-facing, cross-zone, or high-availability network monitoring and security telemetry components.
• Upgrade affected builds to gopacket 1.6.1 or later and redeploy statically linked binaries.
• Restrict sFlow ingestion to trusted exporter IP addresses and block unsolicited UDP traffic to sFlow listeners at firewalls, security groups, ACLs, and host firewalls.
• Add monitoring for sudden memory spikes, Go runtime out-of-memory crashes, container OOMKills, restart loops, and bursts of malformed or unusually small sFlow UDP datagrams.
• Review recent logs from the publication date onward for evidence of crashes or resource exhaustion correlated with inbound sFlow traffic.
• If exploitation is suspected, preserve packet captures, process logs, container runtime events, and host memory/OOM telemetry before restarting or redeploying affected services.