Gopacket
Monthly
Remote denial of service in gopacket through version 1.7.0 can crash any Go application that processes untrusted network packets via DecodingLayerParser or direct DecodeFromBytes calls. Eleven protocol decoders - including TLS, DHCPv4, GTPv1U, IPSec AH, Diameter, and RadioTap - consume attacker-controlled length, count, or offset fields from raw packet headers before verifying them against the actual buffer size, causing an unrecovered Go runtime panic that terminates the processing goroutine or application. No active exploitation has been confirmed (not listed in CISA KEV), but the zero-privilege network attack surface makes this a credible operational risk for Go-based network monitoring, packet capture, and security tooling.
Decoding crafted SCTP segments with gopacket through v1.7.1 (and master 18c5805) can panic the host process, giving an availability-only denial of service, but only when the application has disabled gopacket's per-packet panic recovery - that is, with gopacket.DecodeOptions.SkipDecodeRecovery=true, DecodingLayerParser with IgnorePanic=true, or direct use of the registered SCTP decoders. A single segment as small as a 54-byte Ethernet/IPv4/SCTP frame carrying an 8-byte INIT chunk is enough; the default entry points (gopacket.NewPacket with default options, DecodingLayerParser with IgnorePanic=false) convert the same input into an ordinary per-packet decode error and do not crash. There is no data disclosure, modification, or allocation amplification, the trigger requires that the victim actually process IP protocol 132, and no public exploit identified at time of analysis (the advisory itself documents reproduction steps and regression tests); the flaw is fixed in v1.7.2.
Remote denial of service in gopacket through version 1.7.0 can crash any Go application that processes untrusted network packets via DecodingLayerParser or direct DecodeFromBytes calls. Eleven protocol decoders - including TLS, DHCPv4, GTPv1U, IPSec AH, Diameter, and RadioTap - consume attacker-controlled length, count, or offset fields from raw packet headers before verifying them against the actual buffer size, causing an unrecovered Go runtime panic that terminates the processing goroutine or application. No active exploitation has been confirmed (not listed in CISA KEV), but the zero-privilege network attack surface makes this a credible operational risk for Go-based network monitoring, packet capture, and security tooling.
Decoding crafted SCTP segments with gopacket through v1.7.1 (and master 18c5805) can panic the host process, giving an availability-only denial of service, but only when the application has disabled gopacket's per-packet panic recovery - that is, with gopacket.DecodeOptions.SkipDecodeRecovery=true, DecodingLayerParser with IgnorePanic=true, or direct use of the registered SCTP decoders. A single segment as small as a 54-byte Ethernet/IPv4/SCTP frame carrying an 8-byte INIT chunk is enough; the default entry points (gopacket.NewPacket with default options, DecodingLayerParser with IgnorePanic=false) convert the same input into an ordinary per-packet decode error and do not crash. There is no data disclosure, modification, or allocation amplification, the trigger requires that the victim actually process IP protocol 132, and no public exploit identified at time of analysis (the advisory itself documents reproduction steps and regression tests); the flaw is fixed in v1.7.2.