CWE-789

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T20:19:29Z",
    "nvd_published_at": "2026-04-09T22:16:32Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-4qwc-c7g9-4xcw. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.22 contains an unbounded memory allocation vulnerability in remote media HTTP error handling that allows attackers to trigger excessive memory consumption. Attackers can send crafted HTTP error responses with large bodies to remote media endpoints, causing the application to allocate unbounded memory before failure handling occurs.",
  "id": "GHSA-hm63-vwj4-mj2q",
  "modified": "2026-04-10T20:19:29Z",
  "published": "2026-04-10T00:30:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-4qwc-c7g9-4xcw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35633"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/81445a901091a5d27ef0b56fceedbe4724566438"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-unbounded-memory-allocation-via-remote-media-error-responses"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Remote media error responses could trigger unbounded memory allocation before failure",
  "withdrawn": "2026-04-10T20:19:29Z"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-28773"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-12T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Due to an uncontrolled recursion in SAP Web Dispatcher and SAP Internet Communication Manager, the application may crash, leading to denial of service, but can be restarted automatically.",
  "id": "GHSA-hq75-pvpq-98xx",
  "modified": "2022-04-21T00:00:52Z",
  "published": "2022-04-13T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28773"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3111293"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/navidrome/navidrome"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.60.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25579"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-04T00:14:02Z",
    "nvd_published_at": "2026-02-04T22:16:01Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAuthenticated users can crash the Navidrome server by supplying an excessively large `size` parameter to `/rest/getCoverArt` or to a shared-image URL (`/share/img/\u003ctoken\u003e`). When processing such requests, the server attempts to create an extremely large resized image, causing uncontrolled memory growth. This triggers the Linux OOM killer, terminates the Navidrome process, and results in a full service outage.\n\nIf the system has sufficient memory and survives the allocation, Navidrome then writes these extremely large resized images into its cache directory, allowing an attacker to rapidly exhaust server disk space as well.\n\n### Details\nBoth `/rest/getCoverArt` and `/share/img/\u003ctoken\u003e` accept a `size` parameter that is passed directly into the image processing routine without any upper bound validation. When a very large integer is provided, Navidrome attempts to generate a resized image of that size. This leads to excessive memory allocation inside the image resizing path.\n\nIn the `/rest/getCoverArt` handler, the value is read as:\n\n```go\nsize := p.IntOr(\"size\", 0)\nimgReader, lastUpdate, err := api.artwork.GetOrPlaceholder(ctx, id, size, square)\n```\n\nBecause no limit is enforced, the image subsystem receives the supplied value as-is. When the requested size is extremely large, the process consumes large amounts of RAM until it is killed by the kernel\u0027s OOM killer. If the system has enough available memory to complete the resize operation, the resulting oversized image is then written to Navidrome\u0027s cache directory, which can quickly fill the server\u0027s disk.\n\nThe same behavior is reachable through `/share/img/\u003ctoken\u003e` as long as the attacker possesses a valid sharing token.\n\n### PoC\n1. Authenticate normally to obtain access to `/rest/getCoverArt` or a valid sharing link containing a `/share/img/\u003ctoken\u003e` URL.\n2. Send a regular request with a small size value, for example:\n\n```\n/rest/getCoverArt?...\u0026size=300\u0026square=true\n```\n\n3. Replace the `size` parameter with a very large number, such as:\n\n```\n/rest/getCoverArt?...\u0026size=300000\u0026square=true\n```\n\n4. The server rapidly allocates memory while attempting to create an oversized image. This leads to the Navidrome process being terminated by the OOM killer.\n5. The same behavior can be reproduced with a valid shared-image link:\n\n```\n/share/img/\u003ctoken\u003e?size=300000\u0026square=true\n```\n\nIf the system does not run out of memory, the oversized resized image is written to the cache directory, causing disk usage to grow quickly.\n\n### Impact\nSupplying an excessively large `size` parameter to `/rest/getCoverArt` or `/share/img/\u003ctoken\u003e` allows any authenticated user to trigger a Denial of Service condition. During image resizing, the server attempts to allocate extremely large amounts of memory, which can cause not only Navidrome itself to be terminated by the OOM killer, but in some configurations may also destabilize or crash the entire host system.\n\nOn systems with sufficient memory, the oversized resized images are written to Navidrome\u0027s cache directory instead, allowing an attacker to rapidly consume all available disk space. This leads to a second form of Denial of Service, where the host becomes unable to write logs, operate dependent services, or perform basic system tasks due to storage exhaustion.",
  "id": "GHSA-hrr4-3wgr-68x3",
  "modified": "2026-02-05T00:37:07Z",
  "published": "2026-02-04T00:14:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/navidrome/navidrome/security/advisories/GHSA-hrr4-3wgr-68x3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25579"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/navidrome/navidrome"
    },
    {
      "type": "WEB",
      "url": "https://github.com/navidrome/navidrome/releases/tag/v0.60.0"
    }
  ],
  "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:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Navidrome affected by Denial of Service and disk exhaustion via oversized `size` parameter in `/rest/getCoverArt` and `/share/img/\u003ctoken\u003e` endpoints"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.21.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71314"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-400",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-05T20:59:04Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn unauthenticated attacker can crash a Nuxt server that renders any island / server component containing a `v-for` over a prop (for example `v-for=\"n in count\"` or a `\u003cslot v-for\u003e`). Because the island URL hash is a non-secret digest of the request, the attacker can compute a valid hash for arbitrary props and send the iterated prop as a large integer. The server then expands the `v-for` to that many nodes during SSR, allocating memory proportional to the attacker\u0027s number. Reporter figures: `count=8000000` produced a 142.9 MB response; `count=40000000` (and `items=4000000` on a slot list) produced an out-of-memory crash of the worker from a single ~130-byte request. Both the plain `v-for` path (Vue\u0027s `ssrRenderList`) and the slot path (`vforToArray`) are affected.\n\n### Patches\n\nFixed in `nuxt@4.5.1` and `nuxt@3.21.10`. Island/server-component `v-for` sources are now clamped to a maximum iteration count (`MAX_VFOR_LENGTH = 100000`) at the render boundary, covering the plain path, the `\u003cslot v-for\u003e` element, and the `vforToArray` slot-props helper. Combined with the body-size cap (GHSA-9pgf-384g-p7mv), a single island render can no longer allocate without bound regardless of which `v-for` path is used or whether the prop arrives as an integer or an array.\n\n### Workarounds\n\nAvoid `v-for` directly over an unclamped prop in server components, or clamp the count in the component (`v-for=\"n in Math.min(count, 1000)\"`). A body-size limit in front of `/__nuxt_island/` only mitigates array-shaped inputs, not the integer-amplification case.\n\n### References\n\n- Bound helper: `packages/nuxt/src/app/components/vfor.ts`\n- Transform: `packages/nuxt/src/components/plugins/islands-transform.ts`\n- Slot helper: `packages/nuxt/src/app/components/utils.ts` (`vforToArray`)",
  "id": "GHSA-hxcr-hm88-mpq6",
  "modified": "2026-08-05T20:59:04Z",
  "published": "2026-08-05T20:59:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/security/advisories/GHSA-hxcr-hm88-mpq6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/4e35ae9babd94be53246e31200232d48438bb34e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/commit/668cdfdfda41849ed11c1ee5e2067a11fc103b22"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nuxt/nuxt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/releases/tag/v3.21.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/releases/tag/v4.5.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nuxt: Unauthenticated out-of-memory crash via unbounded v-for expansion in island rendering"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.49.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@sveltejs/kit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.49.0"
            },
            {
              "fixed": "2.49.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-15T18:10:52Z",
    "nvd_published_at": "2026-01-15T19:16:06Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe experimental `form` remote function uses a binary data format containing a representation of submitted form data. A specially-crafted payload can cause the server to allocate a large amount of memory, causing DoS via memory exhaustion.\n\n## Details\n\nWhen a form is submitted to a remote function endpoint, the SvelteKit client encodes the data using a custom format, and POSTs it to the endpoint as a request with an `application/x-sveltekit-formdata` content type.\n\nThe first few bytes of the request body encode the length of the data. SvelteKit will attempt to read the request body up until the specified offset, but if the body is not yet available then an array buffer of that size will be created eagerly to accommodate it as it arrives.\n\nAn attacker can force this code path by sending a small payload that specifies a large data length, then stalling the connection. The resulting array buffer will be held in memory, potentially causing memory exhaustion.\n\n## Impact\n\n- Vulnerability type: Availability / memory exhaustion (memory amplification).\n- Who is impacted: SvelteKit apps with `experimental.remoteFunctions` enabled, and that expose a reachable Remote Form endpoint.\n- Attack: an unauthenticated attacker can repeatedly open connections, send only the 8-byte header/prefix (with large data_length), and stall the body to hold large allocations, exhausting memory.",
  "id": "GHSA-j2f3-wq62-6q46",
  "modified": "2026-01-15T22:33:44Z",
  "published": "2026-01-15T18:10:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/kit/security/advisories/GHSA-j2f3-wq62-6q46"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22803"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/kit/commit/8ed8155215b9a74012fecffb942ad9a793b274e5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sveltejs/kit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/kit/releases/tag/%40sveltejs%2Fkit%402.49.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/kit/releases/tag/@sveltejs%2Fadapter-node@5.5.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@sveltejs/kit has memory amplification DoS vulnerability in Remote Functions binary form deserializer (application/x-sveltekit-formdata)"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.6"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.19"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.8"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "0.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.2.4"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-43857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-405",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-28T14:17:32Z",
    "nvd_published_at": "2025-04-28T16:15:33Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThere is a possibility for denial of service by memory exhaustion when `net-imap` reads server responses.  At any time while the client is connected, a malicious server can send can send a \"literal\" byte count, which is automatically read by the client\u0027s receiver thread.  The response reader immediately allocates memory for the number of bytes indicated by the server response.\n\nThis should not be an issue when securely connecting to trusted IMAP servers that are well-behaved.  It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).\n\n### Details\n\nThe IMAP protocol allows \"literal\" strings to be sent in responses, prefixed with their size in curly braces (e.g. `{1234567890}\\r\\n`).  When `Net::IMAP` receives a response containing a literal string, it calls `IO#read` with that size.  When called with a size, `IO#read` immediately allocates memory to buffer the entire string before processing continues.  The server does not need to send any more data.  There is no limit on the size of literals that will be accepted.\n\n### Fix\n#### Upgrade\nUsers should upgrade to `net-imap` 0.5.7 or later.  A configurable `max_response_size` limit has been added to `Net::IMAP`\u0027s response reader.  The `max_response_size` limit has also been backported to `net-imap` 0.2.5, 0.3.9, and 0.4.20.\n\nTo set a global value for `max_response_size`, users must upgrade to `net-imap` ~\u003e 0.4.20, or \u003e 0.5.7.\n\n#### Configuration\n\nTo avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default `max_response_size` for `net-imap` 0.5.7 is _very high_ (512MiB), and the default `max_response_size` for `net-imap` ~\u003e 0.4.20, ~\u003e 0.3.9, and 0.2.5 is `nil` (unlimited).\n\nWhen connecting to untrusted servers or using insecure connections, a much lower `max_response_size` should be used.\n```ruby\n# Set the global max_response_size (only ~\u003e v0.4.20, \u003e 0.5.7)\nNet::IMAP.config.max_response_size = 256 \u003c\u003c 10 # 256 KiB\n\n# Set when creating the connection\nimap = Net::IMAP.new(hostname, ssl: true,\n                     max_response_size: 16 \u003c\u003c 10) # 16 KiB\n\n# Set after creating the connection\nimap.max_response_size = 256 \u003c\u003c 20 # 256 KiB\n# flush currently waiting read, to ensure the new setting is loaded\nimap.noop\n```\n\n_**Please Note:**_ `max_response_size` only limits the size _per response_.  It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash.  Users are responsible for adding response handlers to prune excessive unhandled responses.\n\n#### Compatibility with lower `max_response_size`\n\nA lower `max_response_size` may cause a few commands which legitimately return very large responses to raise an exception and close the connection.  The `max_response_size` could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible.  For example, to fetch message bodies:\n\n```ruby\nimap.max_response_size = 256 \u003c\u003c 20 # 256 KiB\nimap.noop # flush currently waiting read\n\n# fetch a message in 252KiB chunks\nsize = imap.uid_fetch(uid, \"RFC822.SIZE\").first.rfc822_size\nlimit = 252 \u003c\u003c 10\nmessage = ((0..size) % limit).each_with_object(\"\") {|offset, str|\n  str \u003c\u003c imap.uid_fetch(uid, \"BODY.PEEK[]\u003c#{offset}.#{limit}\u003e\").first.message(offset:)\n}\n\nimap.max_response_size = 16 \u003c\u003c 20 # 16 KiB\nimap.noop # flush currently waiting read\n```\n\n### References\n\n* PR to introduce max_response_size: https://github.com/ruby/net-imap/pull/444\n  * Specific commit: [0ae8576c1 - lib/net/imap/response_reader.rb](https://github.com/ruby/net-imap/pull/444/commits/0ae8576c1a90bcd9573f81bdad4b4b824642d105#diff-53721cb4d9c3fb86b95cc8476ca2df90968ad8c481645220c607034399151462)\n* Backport to 0.4: https://github.com/ruby/net-imap/pull/445\n* Backport to 0.3: https://github.com/ruby/net-imap/pull/446\n* Backport to 0.2: https://github.com/ruby/net-imap/pull/447",
  "id": "GHSA-j3g3-5qv5-52mj",
  "modified": "2025-11-21T22:18:03Z",
  "published": "2025-04-28T14:17:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-j3g3-5qv5-52mj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43857"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/442"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/444"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/444/commits/0ae8576c1a90bcd9573f81bdad4b4b824642d105#diff-53721cb4d9c3fb86b95cc8476ca2df90968ad8c481645220c607034399151462"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/pull/447"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2025-43857.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap rubygem vulnerable to possible DoS by memory exhaustion"
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-5371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-04T17:15:10Z",
    "severity": "MODERATE"
  },
  "details": "RTPS dissector memory leak in Wireshark 4.0.0 to 4.0.8 and 3.6.0 to 3.6.16 allows denial of service via packet injection or crafted capture file",
  "id": "GHSA-j7xf-pgw2-75mr",
  "modified": "2024-08-29T15:30:30Z",
  "published": "2023-10-04T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5371"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/wireshark/wireshark/-/issues/19322"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/34DBP5P2RHQ7XUABPANYYMOGV5KS6VEP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MADSCHKZSCKQ5NLIX3UMOIJD2JZ65L4V"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202402-09"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2023-27.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-1283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-20T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "\n A vulnerability in the logging subsystem of Cisco Data Center Network Manager (DCNM) could allow an authenticated, local attacker to view sensitive information in a system log file that should be restricted.\n The vulnerability exists because sensitive information is not properly masked before it is written to system log files. An attacker could exploit this vulnerability by authenticating to an affected device and inspecting a specific system log file. A successful exploit could allow the attacker to view sensitive information in the system log file. To exploit this vulnerability, the attacker would need to have valid user credentials.\n ",
  "id": "GHSA-j9g2-35f7-x39p",
  "modified": "2022-05-24T17:39:40Z",
  "published": "2022-05-24T17:39:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1283"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dcnm-info-disc-QCSJB6YG"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-72639"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:24Z",
    "severity": "MODERATE"
  },
  "details": "Elasticsearch does not enforce an upper bound on a user-supplied count accepted by a search highlighting option, and the allocation derived from that count is not accounted against any circuit breaker. An authenticated user holding only read privileges on a single searchable index can submit one small search request that causes the node to reserve an excessively large internal data structure. The allocation occurs before the existing highlighting safety limits are evaluated, so memory exhaustion raises a fatal error that terminates the Elasticsearch node process. This results in a denial of service for the affected node and degrades cluster routing and health. The defect is not volumetric and does not depend on the size of the indexed data, so a single request is sufficient.",
  "id": "GHSA-m2jm-f3w6-vg8c",
  "modified": "2026-08-13T21:36:07Z",
  "published": "2026-08-13T21:36:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72639"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-20-9-4-5-9-5-1-security-update-esa-2026-120/389503"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-10142"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-789"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-10T22:16:55Z",
    "severity": "HIGH"
  },
  "details": "kafka-python prior to 2.3.2 contains a denial-of-service vulnerability in the protocol parser that allows a malicious broker or machine-in-the-middle attacker to exhaust memory or hang connections by sending a crafted 4-byte frame length value without bounds validation. Attackers can send a specially crafted frame length through the receive_bytes() function to trigger either a multi-gigabyte memory allocation or an uncaught ValueError that leaves the connection in a broken state, causing requests to hang and consumers to stop heartbeating until restart.",
  "id": "GHSA-m3px-q5gj-j9x7",
  "modified": "2026-06-11T00:32:04Z",
  "published": "2026-06-11T00:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10142"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpkp/kafka-python/pull/3019"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpkp/kafka-python/pull/3026"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dpkp/kafka-python/commit/6e4831444f972d169cdd11f5c8d50333cea3f19b"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/kafka-python-prior-to-denial-of-service-via-protocol-parser-frame-length"
    }
  ],
  "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"
    }
  ]
}