Common Weakness Enumeration

CWE-248

Allowed

Uncaught Exception

Abstraction: Base · Status: Draft

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

602 vulnerabilities reference this CWE, most recent first.

GHSA-QFW8-CR83-3H6J

Vulnerability from github – Published: 2026-07-20 18:32 – Updated: 2026-08-24 12:31
VLAI
Details

A flaw was found in libcupsfilters and cups-filters. The PNG image reading function creates a libpng reader without installing an error recovery handler, causing the CUPS image filter process to abort when processing a malformed PNG file. An unauthenticated attacker could exploit this by submitting a specially crafted PNG print job, leading to denial of service of the in-flight print job.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64612"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-20T18:16:56Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in libcupsfilters and cups-filters. The PNG image reading function creates a libpng reader without installing an error recovery handler, causing the CUPS image filter process to abort when processing a malformed PNG file. An unauthenticated attacker could exploit this by submitting a specially crafted PNG print job, leading to denial of service of the in-flight print job.",
  "id": "GHSA-qfw8-cr83-3h6j",
  "modified": "2026-08-24T12:31:37Z",
  "published": "2026-07-20T18:32:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OpenPrinting/libcupsfilters/security/advisories/GHSA-7mxj-cfq5-84ch"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64612"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:56965"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57451"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:58560"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-64612"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2502801"
    }
  ],
  "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-QH8J-HQJV-7M4X

Vulnerability from github – Published: 2026-09-30 23:29 – Updated: 2026-09-30 23:29
VLAI
Summary
Astro: Malformed port in the Host header can crash the Node adapter
Details

Summary

In the Astro Node adapter, a request whose Host header contains a malformed port (for example example.com:65536 or example.com:8080:8080) produced an invalid request URL. The fallback intended to recover from an unparseable URL reused the same malformed host, so it failed again and raised an uncaught TypeError: Invalid URL while the request was being built, before any route ran.

Impact

The effect depends on the adapter configuration:

  • Default configuration (standalone): the request returns 500 Internal Server Error and the server continues running.
  • With the opt-in staticHeaders: true option: the throw reaches a synchronous HTTP handler that does not catch it, becoming an uncaughtException that terminates the process.

This is an availability-only issue. It does not expose data or allow code execution. Triggering it requires sending a hand-crafted Host header, and many proxies and CDNs reject malformed hosts before they reach the origin.

Affected versions

@astrojs/node <= 11.1.2.

Patches

Fixed in @astrojs/node 11.1.3. When the incoming host cannot be parsed, the request URL now degrades to a host the server controls, so the request is handled instead of throwing. Hosts carrying more than a single hostname:port pair are also rejected during host validation.

Workarounds

Upgrade to @astrojs/node 11.1.3 or later. Deployments that terminate malformed Host headers at a reverse proxy or CDN are not reachable through this path.

Credits

Reported by @Celggar.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.1.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@astrojs/node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102984"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T23:29:40Z",
    "nvd_published_at": "2026-09-30T15:22:23Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nIn the Astro Node adapter, a request whose `Host` header contains a malformed port (for example `example.com:65536` or `example.com:8080:8080`) produced an invalid request URL. The fallback intended to recover from an unparseable URL reused the same malformed host, so it failed again and raised an uncaught `TypeError: Invalid URL` while the request was being built, before any route ran.\n\n## Impact\n\nThe effect depends on the adapter configuration:\n\n- Default configuration (`standalone`): the request returns `500 Internal Server Error` and the server continues running.\n- With the opt-in `staticHeaders: true` option: the throw reaches a synchronous HTTP handler that does not catch it, becoming an `uncaughtException` that terminates the process.\n\nThis is an availability-only issue. It does not expose data or allow code execution. Triggering it requires sending a hand-crafted `Host` header, and many proxies and CDNs reject malformed hosts before they reach the origin.\n\n## Affected versions\n\n`@astrojs/node` \u003c= 11.1.2.\n\n## Patches\n\nFixed in `@astrojs/node` 11.1.3. When the incoming host cannot be parsed, the request URL now degrades to a host the server controls, so the request is handled instead of throwing. Hosts carrying more than a single `hostname:port` pair are also rejected during host validation.\n\n## Workarounds\n\nUpgrade to `@astrojs/node` 11.1.3 or later. Deployments that terminate malformed `Host` headers at a reverse proxy or CDN are not reachable through this path.\n\n## Credits\n\nReported by @Celggar.",
  "id": "GHSA-qh8j-hqjv-7m4x",
  "modified": "2026-09-30T23:29:40Z",
  "published": "2026-09-30T23:29:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-qh8j-hqjv-7m4x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102984"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/pull/17572"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/2066f39c60707a100531b4ef4bb5dab8feafa7f2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/releases/tag/@astrojs/node@11.1.3"
    }
  ],
  "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": "Astro: Malformed port in the Host header can crash the Node adapter"
}

GHSA-QJ59-CXRX-FR36

Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2026-05-29 15:30
VLAI
Details

A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause denial of service when an invalid private command parameter is sent to the controller over Modbus.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-7852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-22T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause denial of service when an invalid private command parameter is sent to the controller over Modbus.",
  "id": "GHSA-qj59-cxrx-fr36",
  "modified": "2026-05-29T15:30:21Z",
  "published": "2022-05-24T16:46:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7852"
    },
    {
      "type": "WEB",
      "url": "https://www.schneider-electric.com/en/download/document/SEVD-2019-134-11"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0763"
    }
  ],
  "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-QJRV-V6QP-X99X

Vulnerability from github – Published: 2024-10-08 22:20 – Updated: 2024-10-08 22:20
VLAI
Summary
SurrealDB has an Uncaught Exception Handling Parsing Errors on Empty Strings
Details

The error rendering code from the parser would panic when handling failed parsing of queries where the error occurred when converting an empty string to a SurrealDB value. This would be the case when casting an empty string to a record, duration or datetime, as well as potentially when parsing an empty string to JSON or providing an empty string to the type::field and type::fields functions.

Impact

A client that is authorized to run queries in a SurrealDB server would be able to execute a malformed query which would fail to parse when converting an empty string and cause a panic in the error rendering code. This would crash the server, leading to denial of service.

Patches

  • Version 2.0.4 and later are not affected by this issue.

Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-08T22:20:02Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The error rendering code from the parser would panic when handling failed parsing of queries where the error occurred when converting an empty string to a SurrealDB value. This would be the case when casting an empty string to a `record`, `duration` or `datetime`, as well as potentially when parsing an empty string to JSON or providing an empty string to the `type::field` and `type::fields` functions.\n\n### Impact\n\nA client that is authorized to run queries in a SurrealDB server would be able to execute a malformed query which would fail to parse when converting an empty string and cause a panic in the error rendering code. This would crash the server, leading to denial of service.\n\n### Patches\n\n- Version 2.0.4 and later are not affected by this issue.\n\n### Workarounds\n\nAffected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.",
  "id": "GHSA-qjrv-v6qp-x99x",
  "modified": "2024-10-08T22:20:02Z",
  "published": "2024-10-08T22:20:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-qjrv-v6qp-x99x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/pull/4923"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/709d6efe901dbf3e207b4fc2ebc30775595efc16"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SurrealDB has an Uncaught Exception Handling Parsing Errors on Empty Strings"
}

GHSA-QP34-X42W-4GFQ

Vulnerability from github – Published: 2025-12-02 03:31 – Updated: 2025-12-02 15:30
VLAI
Details

In Modem, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01689252; Issue ID: MSV-4841.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20753"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-02T03:16:16Z",
    "severity": "MODERATE"
  },
  "details": "In Modem, there is a possible system crash due to an uncaught exception. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01689252; Issue ID: MSV-4841.",
  "id": "GHSA-qp34-x42w-4gfq",
  "modified": "2025-12-02T15:30:30Z",
  "published": "2025-12-02T03:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20753"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/December-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.