Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach SCTP-decoding gopacket consumer (IP proto 132)
-
ExploitSend crafted SCTP chunk segment
-
ExecutionTrigger out-of-bounds slice read in sub-decoder
-
ImpactPanic crashes non-recovering process (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that the victim application process SCTP traffic (IP protocol 132) through gopacket AND run with panic recovery disabled - specifically gopacket.DecodeOptions.SkipDecodeRecovery=true, DecodingLayerParser with IgnorePanic=true, or direct use of registered SCTP decoders without recovery - on an affected version (<= 1.7.1, including master 18c5805). Under these conditions a single crafted SCTP segment (as small as a 54-byte Ethernet→IPv4→SCTP frame with an 8-byte INIT chunk) panics and crashes the process with no authentication or user interaction. The key LIMITING factor is configuration: gopacket's two default entry points - gopacket.NewPacket with default options and DecodingLayerParser.DecodeLayers with IgnorePanic=false - install per-packet recovery and convert the same input into a harmless per-packet decode error, so default deployments do not crash. The complete fix is upgrading to v1.7.2 (go get github.com/gopacket/gopacket@v1.7.2); the advisory's only pre-patch workaround is to keep panic recovery enabled. |
| Impact | This is a medium-severity, availability-only denial-of-service issue (CWE-125 out-of-bounds read / CWE-129 improper validation of array index) in the gopacket SCTP chunk sub-decoders, and the real-world risk is strongly gated by victim configuration rather than by attacker capability. The input CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H = 5.9) aligns with the advisory: a single crafted SCTP segment (IP protocol 132) crashes the process, but ONLY for consumers that disable gopacket's built-in panic recovery (DecodeOptions.SkipDecodeRecovery=true, DecodingLayerParser with IgnorePanic=true, or direct registered decoders); the default recovery-enabled APIs convert the panic into a per-packet decode error and do NOT crash. The AC:H therefore reflects a non-default deployment condition outside the attacker's control, not a race or timing trigger. Signals are consistent but modest: not listed in CISA KEV (no confirmed active exploitation), no EPSS score was supplied in the input, and the vuln.today priority label is 'this_month' (not act_now/emergency). The GHSA advisory publishes concrete crafted-byte reproductions and regression tests. No formal SSVC decision record was provided beyond the 'this_month' label. Net: this is a legitimate remote DoS for the specific high-throughput packet-analysis deployments that set SkipDecodeRecovery (the advisory notes those were scored ~7.5), but a low-urgency, no-crash decode error for everyone on the default APIs - a genuine but configuration-dependent priority, not a drop-everything emergency. |
| Exploit ScenarioDerived | An attacker sends a single crafted SCTP segment (a 54-byte Ethernet→IPv4→SCTP frame with, e.g., an 8-byte INIT chunk suffices) to a network-monitoring, IDS, or packet-analysis service built on gopacket that runs with panic recovery disabled. A sub-decoder (decodeSCTPInit, decodeSCTPSack, decodeSCTPShutdown, decodeSCTPError, or decodeSCTPParameter) reads fixed fields, parameter TLVs, or count-driven loops past the chunk's real length, triggering an out-of-bounds or inverted-slice panic that terminates the process. The GHSA advisory includes exact crafted byte sequences and regression tests, so a public PoC reference exists, though it is not packaged as a standalone weaponized exploit. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 30, 2026
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.
RemediationAI
Vendor-released patch: v1.7.2 - upgrade with go get github.com/gopacket/gopacket@v1.7.2, which applies commit 508044327cc2c065b3db753c010a027e7d1ca621 (layers/sctp: bound chunk sub-decoders and parameters) and adds minimum lengths of 20 for INIT/INIT-ACK, 16 for SACK, 8 for SHUTDOWN and 4 for parameter TLVs, rejects SACK gap-ack and duplicate-TSN counts the chunk cannot hold, clamps final-parameter padding per RFC 9260 3.2, and returns decode errors instead of panicking; release notes at https://github.com/gopacket/gopacket/releases/tag/v1.7.2 and the advisory at https://github.com/gopacket/gopacket/security/advisories/GHSA-358w-w75h-x6rx. Before upgrading, the advisory's own workaround is to keep panic recovery enabled: use gopacket.NewPacket without SkipDecodeRecovery and DecodingLayerParser with IgnorePanic: false, in which case the crafted segment fails to decode rather than terminating the process - the trade-off is that every decode issue in that path, including ones you currently detect yourself, is swallowed into a per-packet error. If you set SkipDecodeRecovery specifically to observe decode failures, wrap your own recover around the decode call so a panic is converted to an error at your boundary, or pre-validate SCTP chunk lengths and TLV lengths before handing buffers to gopacket - both add per-packet overhead and duplicate logic the v1.7.2 patch already implements.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
gopacket walks the SCTP (IP protocol 132) chunk chain in layers/sctp.go and dispatches each chunk to a type-specific sub-decoder. The v1.7.1 hardening commit b772f56 added generic bounds to the dispatcher and decodeSCTPChunk - a chunk must exist, its declared length must be at least 4 and covered by real bytes - and applied a 16-byte minimum only to the DATA chunk, but left every other sub-decoder without a per-type minimum. The result is a CWE-125 out-of-bounds read (with an inverted-slice variant rooted in unsigned length arithmetic, CWE-129): decodeSCTPInit indexes up to data[16:20] and slices data[20:ActualLength] on chunks declared as short as 4 bytes; decodeSCTPShutdown reads a 4-byte TSN from a 4-byte chunk; decodeSCTPParameter slices Value as data[4:length] using an attacker-supplied TLV length with no check that length is at least 4 or within the buffer; and decodeSCTPSack drives loops from attacker-controlled NumGapACKs and NumDuplicateTSNs counts while repeatedly slicing the remainder, so the iteration counts - not the make() capacities, which are already capped against ActualLength - overrun the chunk. This is the SCTP sub-decoder residual that CVE-2026-65819 (GHSA-8mcr-459q-5mx2) named as still under confirmation while its metadata advertised v1.7.1 as the patched version. Any Go program importing the library is in scope; reachability is gated by the decoding configuration and by whether SCTP traffic is parsed at all.
Know when Gopacket gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Remote unauthenticated single-packet trigger (AV:N/PR:N/UI:N); AC:H captures the required non-default no-recovery configuration outside attacker control; impact is availability-only, so C:N/I:N/A:H.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
gopacket provides packet processing capabilities for Go. Prior to 1.7.2, the SCTP chunk chain in layers/sctp.go passes attacker-controlled declared lengths and counts to decodeSCTPInit, decodeSCTPShutdown, decodeSCTPError, decodeSCTPSack, and decodeSCTPParameter without checking that each chunk contains the fixed fields, parameter TLVs, gap acknowledgements, or duplicate TSNs those sub-decoders read. A crafted SCTP segment can therefore cause out-of-bounds or inverted slice panics; the panic can terminate applications that use gopacket.DecodeOptions.SkipDecodeRecovery, direct registered decoders, or DecodingLayerParser with IgnorePanic enabled, while the default recovery-enabled APIs convert it to a per-packet decode error. This is the SCTP sub-decoder residual named but not remediated by CVE-2026-65819, whose version 1.7.1 changes bounded the generic dispatcher but left these per-type reads and loops unchecked. The impact is availability only, with no data disclosure, modification, or allocation amplification. This issue is fixed in version 1.7.2.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
EUVD-2026-114192
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
Exploit-DB