GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-789

Allowed

Memory Allocation with Excessive Size Value

Abstraction: Variant · Status: Draft

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

437 vulnerabilities reference this CWE, most recent first.

GHSA-8VVH-6WQM-9FPW

Vulnerability from github – Published: 2022-01-26 00:01 – Updated: 2022-02-01 00:00
VLAI
Details

This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13672.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-34867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 16.1.3-49160. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper validation of user-supplied data, which can result in an uncontrolled memory allocation. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13672.",
  "id": "GHSA-8vvh-6wqm-9fpw",
  "modified": "2022-02-01T00:00:49Z",
  "published": "2022-01-26T00:01:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34867"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-1055"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8WMX-4C83-GCJF

Vulnerability from github – Published: 2026-05-10 15:31 – Updated: 2026-05-10 15:31
VLAI
Details

memono Notepad 4.2 contains a denial of service vulnerability that allows attackers to crash the application by pasting excessively long character buffers into note fields. Attackers can generate a payload containing 350000 repeated characters and paste it twice into a new note to trigger an application crash on iOS devices.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-10T13:16:30Z",
    "severity": "HIGH"
  },
  "details": "memono Notepad 4.2 contains a denial of service vulnerability that allows attackers to crash the application by pasting excessively long character buffers into note fields. Attackers can generate a payload containing 350000 repeated characters and paste it twice into a new note to trigger an application crash on iOS devices.",
  "id": "GHSA-8wmx-4c83-gcjf",
  "modified": "2026-05-10T15:31:20Z",
  "published": "2026-05-10T15:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47944"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/49977"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/memono-notepad-denial-of-service-via-buffer-overflow"
    }
  ],
  "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"
    },
    {
      "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-947V-GCQQ-82HV

Vulnerability from github – Published: 2026-08-06 15:32 – Updated: 2026-08-06 15:32
VLAI
Details

Sonic 3 A.I.R. before commit 2492d18 contains an unbounded memory allocation vulnerability in ReceivedPacketCache::enqueuePacket() that allows unauthenticated remote attackers to crash the server process by sending a crafted UDP packet with mUniquePacketID set to the maximum uint32 value. The mUniquePacketID field is read directly from the UDP wire-format packet header without bounds checking, causing the server to allocate one CacheItem per missing packet ID gap, exhausting available host memory and propagating an uncaught std::bad_alloc exception to std::terminate().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-66733"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-06T13:18:21Z",
    "severity": "HIGH"
  },
  "details": "Sonic 3 A.I.R. before commit 2492d18 contains an unbounded memory allocation vulnerability in ReceivedPacketCache::enqueuePacket() that allows unauthenticated remote attackers to crash the server process by sending a crafted UDP packet with mUniquePacketID set to the maximum uint32 value. The mUniquePacketID field is read directly from the UDP wire-format packet header without bounds checking, causing the server to allocate one CacheItem per missing packet ID gap, exhausting available host memory and propagating an uncaught std::bad_alloc exception to std::terminate().",
  "id": "GHSA-947v-gcqq-82hv",
  "modified": "2026-08-06T15:32:43Z",
  "published": "2026-08-06T15:32:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66733"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Eukaryot/sonic3air/commit/2492d1882cd2cf1cc1d7415729ce5c4fd686cd4f"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/sonic-3-a-i-r-unbounded-memory-allocation-dos-via-receivedpacketcache"
    }
  ],
  "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"
    },
    {
      "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9566-65PP-GHQG

Vulnerability from github – Published: 2025-05-12 18:31 – Updated: 2025-05-12 18:31
VLAI
Details

IBM 4769 Developers Toolkit 7.0.0 through 7.5.52 could allow a remote attacker to cause a denial of service in the Hardware Security Module (HSM) due to improper memory allocation of an excessive size.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-3632"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-12T17:15:46Z",
    "severity": "HIGH"
  },
  "details": "IBM 4769 Developers Toolkit 7.0.0 through 7.5.52 could allow a remote attacker to cause a denial of service in the Hardware Security Module (HSM) due to improper memory allocation of an excessive size.",
  "id": "GHSA-9566-65pp-ghqg",
  "modified": "2025-05-12T18:31:46Z",
  "published": "2025-05-12T18:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3632"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7233139"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-97VP-PWQJ-46QC

Vulnerability from github – Published: 2026-03-17 17:48 – Updated: 2026-03-30 14:04
VLAI
Summary
Sliver Vulnerable to Authenticated OOM via Memory Exhaustion in mTLS/WireGuard Transports
Details

Summary

A Remote OOM (Out-of-Memory) vulnerability exists in the Sliver C2 server's mTLS and WireGuard C2 transport layer. The socketReadEnvelope and socketWGReadEnvelope functions trust an attacker-controlled 4-byte length prefix to allocate memory, with ServerMaxMessageSize allowing single allocations of up to ~2 GiB. A compromised implant or an attacker with valid credentials can exploit this by sending fabricated length prefixes over concurrent yamux streams (up to 128 per connection), forcing the server to attempt allocating ~256 GiB of memory and triggering an OS OOM kill. This crashes the Sliver server, disrupts all active implant sessions, and may degrade or kill other processes sharing the same host. The same pattern also affects all implant-side readers, which have no upper-bound check at all.


Root Cause Analysis

The C2 envelope framing protocol uses a 4-byte little-endian length prefix to delimit protobuf messages on the wire:

[raw_signature (74 bytes)] [uint32 length] [protobuf data]

In socketReadEnvelope, after reading the length prefix, the server immediately allocates a buffer of the attacker-specified size:

// server/c2/mtls.go
const ServerMaxMessageSize = (2 * 1024 * 1024 * 1024) - 1  // ~2 GiB

dataLength := int(binary.LittleEndian.Uint32(dataLengthBuf))
if dataLength <= 0 || ServerMaxMessageSize < dataLength {
    return nil, errors.New("[pivot] invalid data length")
}
dataBuf := make([]byte, dataLength)  // ← Allocates up to ~2 GiB

// ... data is read into buffer ...

// Envelope signature verification happens AFTER allocation and read:
if !ed25519.Verify(pubKey, dataBuf, signature) {
    return nil, errors.New("[mtls] invalid signature")
}

Key issues:

  1. Excessive limit: ServerMaxMessageSize is set to (2 * 1024 * 1024 * 1024) - 12 GiB, far exceeding any legitimate protobuf envelope (large payloads like screenshots and downloads are chunked at the RPC layer).
  2. Allocation before envelope verification: While the TLS handshake validates the client certificate, the per-envelope ed25519 signature check (ed25519.Verify) occurs after the buffer allocation and io.ReadFull. Once the TLS connection is established, no further cryptographic proof is needed to trigger the allocation.
  3. Yamux amplification: The yamux session allows up to mtlsYamuxMaxConcurrentStreams = 128 concurrent streams. Each stream processes socketReadEnvelope independently, so a single connection can trigger 128 parallel ~2 GiB allocations.
  4. Implant-side exposure: The implant-side readers (ReadEnvelope in mTLS/WireGuard, read() in pivots) have no upper-bound check at all — they accept any dataLength > 0.

The same pattern exists in socketWGReadEnvelope for the WireGuard transport.

Note: The same unbounded allocation pattern is also present in implant-side readers, though it poses no immediate risk to the server 1, 2, 3, 4.


Proof of Concept

PoC Links: mtls_poc.go or Gist Version 1. Establish mTLS connection: Complete a valid TLS 1.3 handshake presenting a valid implant client certificate. 2. Negotiate yamux: Send the MUX/1 preface to enter multiplexed stream mode. 3. Open concurrent streams: Open multiple yamux streams (up to 128). 4. Send malicious length prefix: On each stream, send a 74-byte raw signature buffer followed by a 4-byte length prefix claiming 0x7FFFFFFF (2,147,483,647 bytes ≈ 2 GiB). No actual data needs to follow. 5. Result: Each stream triggers a make([]byte, 0x7FFFFFFF) allocation. With 128 concurrent streams, the server process attempts to allocate up to ~256 GiB of memory, causing the OS OOM killer to terminate the process.

Impact

  • Server availability: The Sliver server process is killed. Active implant sessions are disrupted until the operator manually restarts the server.
  • Host degradation: On hosts with swap enabled, the OOM event may cause swap thrashing and degrade other services sharing the same host before the process is killed.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/bishopfox/sliver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T17:48:45Z",
    "nvd_published_at": "2026-03-20T04:16:49Z",
    "severity": "MODERATE"
  },
  "details": "# Summary\nA Remote OOM (Out-of-Memory) vulnerability exists in the Sliver C2 server\u0027s mTLS and WireGuard C2 transport layer. The\u00a0`socketReadEnvelope`\u00a0and `socketWGReadEnvelope`\u00a0functions trust an attacker-controlled 4-byte length prefix to allocate memory, with\u00a0`ServerMaxMessageSize`\u00a0allowing single allocations of up to\u00a0**~2 GiB**. A compromised implant or an attacker with valid credentials can exploit this by sending fabricated length prefixes over concurrent yamux streams (up to 128 per connection), forcing the server to attempt allocating\u00a0**~256 GiB**\u00a0of memory and triggering an OS OOM kill. This crashes the Sliver server, disrupts all active implant sessions, and may degrade or kill other processes sharing the same host. The same pattern also affects all implant-side readers, which have\u00a0**no**\u00a0upper-bound check at all.\n\n---\n# Root Cause Analysis\n\nThe C2 envelope framing protocol uses a 4-byte little-endian length prefix to delimit protobuf messages on the wire:\n\n```\n[raw_signature (74 bytes)] [uint32 length] [protobuf data]\n```\n\nIn [socketReadEnvelope](https://github.com/BishopFox/sliver/blob/master/server/c2/mtls.go#L337-L392), after reading the length prefix, the server immediately allocates a buffer of the attacker-specified size:\n\n```go\n// server/c2/mtls.go\nconst ServerMaxMessageSize = (2 * 1024 * 1024 * 1024) - 1  // ~2 GiB\n\ndataLength := int(binary.LittleEndian.Uint32(dataLengthBuf))\nif dataLength \u003c= 0 || ServerMaxMessageSize \u003c dataLength {\n    return nil, errors.New(\"[pivot] invalid data length\")\n}\ndataBuf := make([]byte, dataLength)  // \u2190 Allocates up to ~2 GiB\n\n// ... data is read into buffer ...\n\n// Envelope signature verification happens AFTER allocation and read:\nif !ed25519.Verify(pubKey, dataBuf, signature) {\n    return nil, errors.New(\"[mtls] invalid signature\")\n}\n```\n\n**Key issues:**\n\n1. **Excessive limit**: `ServerMaxMessageSize` is set to `(2 * 1024 * 1024 * 1024) - 1` \u2248 **2 GiB**, far exceeding any legitimate protobuf envelope (large payloads like screenshots and downloads are chunked at the RPC layer).\n2. **Allocation before envelope verification**: While the TLS handshake validates the client certificate, the per-envelope ed25519 signature check (`ed25519.Verify`) occurs **after** the buffer allocation and `io.ReadFull`. Once the TLS connection is established, no further cryptographic proof is needed to trigger the allocation.\n3. **Yamux amplification**: The yamux session allows up to `mtlsYamuxMaxConcurrentStreams = 128` concurrent streams. Each stream processes `socketReadEnvelope` independently, so a single connection can trigger **128 parallel ~2 GiB allocations**.\n4. **Implant-side exposure**: The implant-side readers ([ReadEnvelope](https://github.com/BishopFox/sliver/blob/master/implant/sliver/transports/mtls/mtls.go#L184) in mTLS/WireGuard, [read()](https://github.com/BishopFox/sliver/blob/master/implant/sliver/pivots/pivots.go#L478) in pivots) have **no upper-bound check at all** \u2014 they accept any `dataLength \u003e 0`.\n\nThe same pattern exists in [socketWGReadEnvelope](https://github.com/BishopFox/sliver/blob/master/server/c2/wireguard.go#L428-L487) for the WireGuard transport.\n\n\n_Note: The same unbounded allocation pattern is also present in implant-side readers, though it poses no immediate risk to the server [1](https://github.com/BishopFox/sliver/blob/master/implant/sliver/transports/mtls/mtls.go#L185), [2](https://github.com/BishopFox/sliver/blob/master/implant/sliver/transports/wireguard/wireguard.go#L178), [3](https://github.com/BishopFox/sliver/blob/master/implant/sliver/pivots/pivots.go), [4](https://github.com/BishopFox/sliver/blob/master/implant/sliver/transports/pivotclients/pivotclient.go)._\n\n\n---\n\n# Proof of Concept\nPoC Links: [mtls_poc.go](https://github.com/skoveit/Sliver-OOM-DoS-PoC/) or [Gist Version](https://gist.github.com/skoveit/08f3ec08ffbf3deeff189a83ef827dcf)\n1. **Establish mTLS connection**: Complete a valid TLS 1.3 handshake presenting a valid implant client certificate.\n2. **Negotiate yamux**: Send the `MUX/1` preface to enter multiplexed stream mode.\n3. **Open concurrent streams**: Open multiple yamux streams (up to 128).\n4. **Send malicious length prefix**: On each stream, send a 74-byte raw signature buffer followed by a 4-byte length prefix claiming `0x7FFFFFFF` (2,147,483,647 bytes \u2248 2 GiB). No actual data needs to follow.\n5. **Result**: Each stream triggers a `make([]byte, 0x7FFFFFFF)` allocation. With 128 concurrent streams, the server process attempts to allocate **up to ~256 GiB** of memory, causing the OS OOM killer to terminate the process.\n\n# Impact\n- **Server availability**: The Sliver server process is killed. Active implant sessions are disrupted until the operator manually restarts the server.\n- **Host degradation**: On hosts with swap enabled, the OOM event may cause swap thrashing and degrade other services sharing the same host before the process is killed.",
  "id": "GHSA-97vp-pwqj-46qc",
  "modified": "2026-03-30T14:04:02Z",
  "published": "2026-03-17T17:48:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/security/advisories/GHSA-97vp-pwqj-46qc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32941"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/skoveit/08f3ec08ffbf3deeff189a83ef827dcf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BishopFox/sliver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Sliver Vulnerable to Authenticated OOM via Memory Exhaustion in mTLS/WireGuard Transports"
}

GHSA-9HHJ-2JWX-R87P

Vulnerability from github – Published: 2026-07-22 00:32 – Updated: 2026-07-22 00:32
VLAI
Details

Ollama (HEAD f0078ae) contains an uncontrolled memory allocation vulnerability in the GGUF metadata parser that allows remote attackers to crash the server by supplying a crafted GGUF file with attacker-controlled length and count fields in string lengths, tensor dimension counts, and metadata array counts that are used as allocation sizes without validation against remaining file size. Attackers can upload a sub-1KB crafted GGUF file via the blob upload and model create or pull API endpoints to trigger unrecoverable Go runtime out-of-memory fatal errors or makeslice panics that bypass recovery middleware and crash the entire server process.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-65315"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:19:10Z",
    "severity": "HIGH"
  },
  "details": "Ollama (HEAD f0078ae) contains an uncontrolled memory allocation vulnerability in the GGUF metadata parser that allows remote attackers to crash the server by supplying a crafted GGUF file with attacker-controlled length and count fields in string lengths, tensor dimension counts, and metadata array counts that are used as allocation sizes without validation against remaining file size. Attackers can upload a sub-1KB crafted GGUF file via the blob upload and model create or pull API endpoints to trigger unrecoverable Go runtime out-of-memory fatal errors or makeslice panics that bypass recovery middleware and crash the entire server process.",
  "id": "GHSA-9hhj-2jwx-r87p",
  "modified": "2026-07-22T00:32:34Z",
  "published": "2026-07-22T00:32:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65315"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ollama/ollama/issues/17042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ollama/ollama"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/ollama-remote-denial-of-service-via-attacker-controlled-allocation-in-gguf-metadata-parser"
    }
  ],
  "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"
    },
    {
      "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9M3W-2GGJ-2VQW

Vulnerability from github – Published: 2023-09-27 18:30 – Updated: 2024-01-25 18:30
VLAI
Details

A vulnerability in the Wireless Network Control daemon (wncd) of Cisco IOS XE Software for Wireless LAN Controllers could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition.

This vulnerability is due to improper memory management. An attacker could exploit this vulnerability by sending a series of network requests to an affected device. A successful exploit could allow the attacker to cause the wncd process to consume available memory and eventually cause the device to reload, resulting in a DoS condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-27T18:15:11Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the Wireless Network Control daemon (wncd) of Cisco IOS XE Software for Wireless LAN Controllers could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition.\n\n This vulnerability is due to improper memory management. An attacker could exploit this vulnerability by sending a series of network requests to an affected device. A successful exploit could allow the attacker to cause the wncd process to consume available memory and eventually cause the device to reload, resulting in a DoS condition.",
  "id": "GHSA-9m3w-2ggj-2vqw",
  "modified": "2024-01-25T18:30:44Z",
  "published": "2023-09-27T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20202"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wlc-wncd-HFGMsfSD"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9MMJ-J2R4-96MP

Vulnerability from github – Published: 2026-08-03 03:31 – Updated: 2026-08-28 15:30
VLAI
Details

In Bouncy Castle for Java before 1.85, BKS/UBER keystore allocates from untrusted lengths before integrity check. This issue also affects Bouncy Castle for Java LTS before 2.73.12.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-12185"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-03T01:16:42Z",
    "severity": "HIGH"
  },
  "details": "In Bouncy Castle for Java before 1.85, BKS/UBER keystore allocates from untrusted lengths before integrity check. This issue also affects Bouncy Castle for Java LTS before 2.73.12.",
  "id": "GHSA-9mmj-j2r4-96mp",
  "modified": "2026-08-28T15:30:25Z",
  "published": "2026-08-03T03:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/commit/7bbd7fe5f44132e5b6140a2914435c12430eeb3d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9012185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE-2026-12185"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9MV9-GW4X-7XW4

Vulnerability from github – Published: 2025-11-15 09:30 – Updated: 2025-11-15 09:30
VLAI
Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.9 before 18.3.6, 18.4 before 18.4.4, and 18.5 before 18.5.2 that could have allowed an authenticated attacker to cause a denial of service condition by submitting specially crafted markdown content with nested formatting patterns.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-12983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-15T09:15:41Z",
    "severity": "LOW"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.9 before 18.3.6, 18.4 before 18.4.4, and 18.5 before 18.5.2 that could have allowed an authenticated attacker to cause a denial of service condition by submitting specially crafted markdown content with nested formatting patterns.",
  "id": "GHSA-9mv9-gw4x-7xw4",
  "modified": "2025-11-15T09:30:25Z",
  "published": "2025-11-15T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12983"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3419588"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2025/11/12/patch-release-gitlab-18-5-2-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/296257"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2GW-4533-C2W3

Vulnerability from github – Published: 2026-09-09 15:35 – Updated: 2026-09-09 15:35
VLAI
Details

A user could provide an expression whose string length is longer than the ParserExpressionSizeLimit() configured on the CEL environment, and a memory allocation would occur proportional to the size of the input before the limit would be checked / enforced.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-83530"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T15:17:12Z",
    "severity": "MODERATE"
  },
  "details": "A user could provide an expression whose string length is longer than the ParserExpressionSizeLimit() configured on the CEL environment, and a memory allocation would occur proportional to the size of the input before the limit would be checked / enforced.",
  "id": "GHSA-c2gw-4533-c2w3",
  "modified": "2026-09-09T15:35:16Z",
  "published": "2026-09-09T15:35:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83530"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cel-expr/cel-go/pull/1302"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation
Implementation Architecture and Design

Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.

Mitigation
Operation

Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

No CAPEC attack patterns related to this CWE.