Common Weakness Enumeration

CWE-248

Allowed

Uncaught Exception

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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

610 vulnerabilities reference this CWE, most recent first.

GHSA-85XF-C7HM-WHQW

Vulnerability from github – Published: 2026-10-05 23:42 – Updated: 2026-10-05 23:42
VLAI
Summary
vLLM: Structured-output request errors escape the request boundary and terminate the shared EngineCore — engine-fatal denial of service (3 sites)
Details

Affected

  • Ecosystem / package: pip / vllm
  • Affected versions: vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit 752a3a504485). The lower bound predates 0.25.1; maintainers can confirm how far back each path reaches.

Summary

Three structured-output request paths let an ordinary request reach a condition that raises an uncaught, engine-fatal exception instead of a per-request validation error. The failure is not confined to the request that caused it: it escapes into EngineCore's busy loop and triggers a fatal _send_engine_dead(), so one malformed structured-output request denies service to all concurrent and subsequent tenants of that engine. The requests are ordinary API calls; the client does not need any privileged configuration beyond the (often default) structured-output feature.

The shared root cause is the absence of a per-request exception boundary around structured-output grammar/token handling: a value that should fail as a request-scoped validation error instead propagates as an uncaught exception (or bypasses frontend validation entirely) and reaches the scheduler/engine loop, which treats the failure as fatal.

These sites are distinct from the published fixes for GHSA-6qc9-v4r8-22xg and GHSA-8wr5-jm2h-8r4f: GHSA-6qc9 (PR #17623) added frontend json-schema/regex/type validation but the completion check on v0.25.1 still catches only TimeoutError, so Site 1's valid duplicate-root EBNF via the latched xgrammar backend still re-raises and kills EngineCore; GHSA-8wr5 (PR #44744) fixes recovered-token state in the eagle spec-decode path and explicitly does not treat trailing -1 padding as the fault, so Site 2's -1 reaching backend_guidance.validate_tokens() via ngram_gpu survives it.

Affected code

Links pinned to the confirmed commit 752a3a504485 (v0.25.1). The three sites are:

Site 1 — latched-backend compile exception escapes. StructuredOutputManager permanently latches one backend on the first structured-output request and always compiles through it, ignoring the per-request auto backend selection. A grammar that auto accepts only via a fallback backend (e.g. a duplicate-root EBNF) then makes the latched xgrammar compiler raise; the exception is stored in the grammar Future, and the completion check catches only TimeoutError, so Future.result() re-raises during scheduler promotion and kills EngineCore.

The escaping-exception sink: the completion check only handles TimeoutError, so any compile exception stored in the Future re-raises out of result() during scheduler promotion.

# vllm/v1/structured_output/request.py Lines 48-59
    def _check_grammar_completion(self) -> bool:
        # NOTE: We have to lazy import to gate circular imports
        from vllm.v1.request import RequestStatus

        if isinstance(self._grammar, Future):
            try:
                # We will check whether the future is ready within 100 us
                self._grammar = self._grammar.result(timeout=0.0001)
                self.status = RequestStatus.WAITING
            except TimeoutError:
                return False
        return True

Site 2 — guidance treats ngram_gpu -1 padding as a token id. The ngram_gpu proposer pads a fixed-width draft-token row with -1 and separately records num_valid_draft_tokens, but the scheduler forwards the untrimmed padded row into GuidanceGrammar.validate_tokens(), which passes -1 to the native llguidance matcher; the matcher cannot convert a negative value to its unsigned token type and raises an OverflowError, uncaught and fatal.

The sink passes the padded row straight to the native matcher with no lower-bound check on token ids:

# vllm/v1/structured_output/backend_guidance.py Lines 181-196
    def validate_tokens(self, tokens: list[int]) -> list[int]:
        """Checks if the list of tokens are accepted by the parser in sequence.
        Will not advance the parser.

        Returns the prefix list of tokens that are accepted by the parser.
        """
        if len(tokens) == 0:
            return []
        if self.ll_matcher.is_stopped():
            return []

        num_tokens = self.ll_matcher.validate_tokens(tokens)

        self.check_error()

        return tokens[:num_tokens]

Site 3 — Rust frontend accepts an empty structured-output value the Python frontend rejects. The opt-in Rust frontend admits an empty structured_outputs.json / structured_outputs.grammar string that the Python frontend rejects; the empty value passes through the wire-params conversion without validation, reaches the engine, and marks EngineCore dead.

The conversion maps each field to a constraint with no non-empty check, so an empty json/grammar string is forwarded unchanged:

// rust/src/engine-core-client/src/protocol/structured_outputs.rs Lines 135-162
impl TryFrom<WireStructuredOutputsParams> for StructuredOutputsParams {
    type Error = Error;

    fn try_from(raw: WireStructuredOutputsParams) -> Result<Self> {
        use StructuredOutputConstraint::*;

        let mut constraint = None;

        macro_rules! insert_constraint {
            ($name:literal, $value:expr) => {
                if let Some(value) = $value {
                    if let Some((existing, _)) = constraint {
                        return Err(Error::InvalidStructuredOutputsParams {
                            message: format!(
                                "multiple structured output constraints specified: {existing}, {}",
                                $name
                            ),
                        });
                    }
                    constraint = Some(($name, value));
                }
            };
        }

        insert_constraint!("json", raw.json.map(Json));
        insert_constraint!("regex", raw.regex.map(Regex));
        insert_constraint!("choice", raw.choice.map(Choice));
        insert_constraint!("grammar", raw.grammar.map(Grammar));

Impact

Any client able to send an ordinary structured-output request (two requests for Site 1) can terminate the shared EngineCore, denying service to all tenants of that engine instance. Availability only; no code execution, memory corruption, or data disclosure.

  • Site 1 affects the default "auto" structured-output backend; no speculative decoding or non-default configuration is required.
  • Site 2 requires a deployment using the guidance backend together with ngram_gpu speculative decoding; the -1 sentinel is produced by the proposer itself, so an ordinary constrained request suffices — the client does not craft the negative token.
  • Site 3 requires the opt-in Rust frontend; a single request with an empty constraint value is enough. API-key middleware narrows the attacker from unauthenticated to authenticated but does not restore the missing validation.

Suggested Fix

Convert structured-output failures into request-scoped errors at the boundary. Each site is a distinct fix shape; the core hunk for each is below.

Site 1 — resolve the backend per request instead of latching one process-wide, so a grammar is always compiled with the backend that auto actually selected for it (and a compile failure is that request's error, not the engine's):

# vllm/v1/structured_output/__init__.py — grammar_init(), replacing the latched-backend path
backend = self._get_or_create_backend(request.structured_output_request.backend)
if self._use_async_grammar_compilation:
    grammar = self.executor.submit(self._create_grammar, request, backend)
else:
    grammar = self._create_grammar(request, backend)

Site 2 — drop negative sentinels before handing the row to the native matcher, inside validate_tokens():

# vllm/v1/structured_output/backend_guidance.py — validate_tokens(), before the ll_matcher call
for i, token in enumerate(tokens):
    if token < 0:
        tokens = tokens[:i]
        break
if len(tokens) == 0:
    return []

Site 3 — reject empty json/grammar strings in the Rust wire-params conversion, matching the Python frontend, before the value reaches the engine:

// rust/src/engine-core-client/src/protocol/structured_outputs.rs — try_from(), before constraint mapping
if matches!(&raw.json, Some(Value::String(value)) if value.trim().is_empty()) {
    return Err(Error::InvalidStructuredOutputsParams {
        message: "structured_outputs.json cannot be an empty string".to_string(),
    });
}
if matches!(&raw.grammar, Some(value) if value.trim().is_empty()) {
    return Err(Error::InvalidStructuredOutputsParams {
        message: "structured_outputs.grammar cannot be an empty string".to_string(),
    });
}

The three sites share one root cause and the same fix shape (bound the failure to the request), so they are filed as a single advisory; happy to split into per-component advisories if the maintainers prefer. Each fix carries a regression test.

Credit

Reported by: Patch the Planet (Trail of Bits + OpenAI collaboration)

These vulnerabilities were discovered using GPT-5.5-Cyber as part of the Patch the Planet security initiative.

Proposed fix: a fix for this issue is proposed in a public pull request: https://github.com/vllm-project/vllm/pull/51450

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-105757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-248",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T23:42:44Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Affected\n\n- **Ecosystem / package:** pip / `vllm`\n- **Affected versions:** vLLM \u2264 0.25.1 (confirmed on 0.25.1, commit [`752a3a504485`](https://github.com/vllm-project/vllm/tree/752a3a504485790a2e8491cacbb35c137339ad34)). The lower bound predates 0.25.1; maintainers can confirm how far back each path reaches.\n\n## Summary\n\nThree structured-output request paths let an ordinary request reach a condition that raises an **uncaught, engine-fatal** exception instead of a per-request validation error. The failure is not confined to the request that caused it: it escapes into `EngineCore`\u0027s busy loop and triggers a fatal `_send_engine_dead()`, so one malformed structured-output request denies service to all concurrent and subsequent tenants of that engine. The requests are ordinary API calls; the client does not need any privileged configuration beyond the (often default) structured-output feature.\n\nThe shared root cause is the absence of a per-request exception boundary around structured-output grammar/token handling: a value that should fail as a request-scoped validation error instead propagates as an uncaught exception (or bypasses frontend validation entirely) and reaches the scheduler/engine loop, which treats the failure as fatal.\n\nThese sites are distinct from the published fixes for [GHSA-6qc9-v4r8-22xg](https://github.com/vllm-project/vllm/security/advisories/GHSA-6qc9-v4r8-22xg) and [GHSA-8wr5-jm2h-8r4f](https://github.com/vllm-project/vllm/security/advisories/GHSA-8wr5-jm2h-8r4f): GHSA-6qc9 (PR #17623) added frontend json-schema/regex/type validation but the completion check on v0.25.1 still catches only `TimeoutError`, so Site 1\u0027s valid duplicate-root EBNF via the latched xgrammar backend still re-raises and kills EngineCore; GHSA-8wr5 (PR #44744) fixes recovered-token state in the eagle spec-decode path and explicitly does not treat trailing `-1` padding as the fault, so Site 2\u0027s `-1` reaching `backend_guidance.validate_tokens()` via `ngram_gpu` survives it.\n\n## Affected code\n\nLinks pinned to the confirmed commit [`752a3a504485`](https://github.com/vllm-project/vllm/tree/752a3a504485790a2e8491cacbb35c137339ad34) (v0.25.1). The three sites are:\n\n**Site 1 \u2014 latched-backend compile exception escapes.** `StructuredOutputManager` permanently latches one backend on the first structured-output request and always compiles through it, ignoring the per-request `auto` backend selection. A grammar that `auto` accepts only via a fallback backend (e.g. a duplicate-root EBNF) then makes the latched xgrammar compiler raise; the exception is stored in the grammar `Future`, and the completion check catches only `TimeoutError`, so `Future.result()` re-raises during scheduler promotion and kills EngineCore.\n\n- Backend defaults to `\"auto\"`: [`vllm/config/structured_outputs.py#L21`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/config/structured_outputs.py#L21).\n- The `auto` validator tries xgrammar and silently falls back, recording the resolved backend on the request: [`vllm/sampling_params.py#L1004-L1035`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/sampling_params.py#L1004-L1035) (fields at [`#L85-L88`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/sampling_params.py#L85-L88)).\n- The manager latches one backend and always compiles through it: [`vllm/v1/structured_output/__init__.py#L127-L159`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/__init__.py#L127-L159) and `_create_grammar()` at [`#L173-L184`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/__init__.py#L173-L184).\n- The xgrammar sink calls the native compiler unguarded: [`vllm/v1/structured_output/backend_xgrammar.py#L78-L110`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/backend_xgrammar.py#L78-L110) (grammar path at [`#L90`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/backend_xgrammar.py#L90)).\n- The completion check catches only `TimeoutError`: [`vllm/v1/structured_output/request.py#L48-L63`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/request.py#L48-L63) (`result(timeout=0.0001)` at [`#L55`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/request.py#L55), `except TimeoutError` at [`#L57`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/request.py#L57)).\n- Scheduler promotion dereferences the grammar with no exception boundary: [`vllm/v1/core/sched/scheduler.py#L2441-L2460`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/core/sched/scheduler.py#L2441-L2460) (reached from [`schedule()` at #L396](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/core/sched/scheduler.py#L396)).\n- The uncaught exception is treated as fatal: [`vllm/v1/engine/core.py#L1229-L1234`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/engine/core.py#L1229-L1234) (`_send_engine_dead()` at [`#L1470`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/engine/core.py#L1470)).\n\nThe escaping-exception sink: the completion check only handles `TimeoutError`, so any compile exception stored in the `Future` re-raises out of `result()` during scheduler promotion.\n\n```python\n# vllm/v1/structured_output/request.py Lines 48-59\n    def _check_grammar_completion(self) -\u003e bool:\n        # NOTE: We have to lazy import to gate circular imports\n        from vllm.v1.request import RequestStatus\n\n        if isinstance(self._grammar, Future):\n            try:\n                # We will check whether the future is ready within 100 us\n                self._grammar = self._grammar.result(timeout=0.0001)\n                self.status = RequestStatus.WAITING\n            except TimeoutError:\n                return False\n        return True\n```\n\n**Site 2 \u2014 guidance treats `ngram_gpu` `-1` padding as a token id.** The `ngram_gpu` proposer pads a fixed-width draft-token row with `-1` and separately records `num_valid_draft_tokens`, but the scheduler forwards the untrimmed padded row into `GuidanceGrammar.validate_tokens()`, which passes `-1` to the native `llguidance` matcher; the matcher cannot convert a negative value to its unsigned token type and raises an `OverflowError`, uncaught and fatal.\n\n- The proposer fills with `-1` and computes `num_valid_draft_tokens`: [`vllm/v1/spec_decode/ngram_proposer_gpu.py#L189-L209`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/spec_decode/ngram_proposer_gpu.py#L189-L209).\n- `_get_draft_token_ids_cpu()` materializes the full padded row, not trimmed to the valid count: [`vllm/v1/worker/gpu_model_runner.py#L4835-L4849`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/worker/gpu_model_runner.py#L4835-L4849).\n- Two scheduler call sites pass the padded row into `validate_tokens(...)`: [`vllm/v1/core/sched/scheduler.py#L1967`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/core/sched/scheduler.py#L1967) and [`#L1997`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/core/sched/scheduler.py#L1997).\n- The sink has no negative-value filter: [`vllm/v1/structured_output/backend_guidance.py#L181-L192`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/backend_guidance.py#L181-L192) (`validate_tokens(tokens)` at [`#L192`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/structured_output/backend_guidance.py#L192)).\n- The uncaught `OverflowError` is treated as fatal: [`vllm/v1/engine/core.py#L1229-L1234`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/engine/core.py#L1229-L1234).\n\nThe sink passes the padded row straight to the native matcher with no lower-bound check on token ids:\n\n```python\n# vllm/v1/structured_output/backend_guidance.py Lines 181-196\n    def validate_tokens(self, tokens: list[int]) -\u003e list[int]:\n        \"\"\"Checks if the list of tokens are accepted by the parser in sequence.\n        Will not advance the parser.\n\n        Returns the prefix list of tokens that are accepted by the parser.\n        \"\"\"\n        if len(tokens) == 0:\n            return []\n        if self.ll_matcher.is_stopped():\n            return []\n\n        num_tokens = self.ll_matcher.validate_tokens(tokens)\n\n        self.check_error()\n\n        return tokens[:num_tokens]\n```\n\n**Site 3 \u2014 Rust frontend accepts an empty structured-output value the Python frontend rejects.** The opt-in Rust frontend admits an empty `structured_outputs.json` / `structured_outputs.grammar` string that the Python frontend rejects; the empty value passes through the wire-params conversion without validation, reaches the engine, and marks EngineCore dead.\n\n- `impl TryFrom\u003cWireStructuredOutputsParams\u003e for StructuredOutputsParams`: [`rust/src/engine-core-client/src/protocol/structured_outputs.rs#L135-L163`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/rust/src/engine-core-client/src/protocol/structured_outputs.rs#L135-L163) \u2014 `try_from` at L138 maps `raw.json` to a `Json` constraint (L159) and `raw.grammar` to a `Grammar` constraint (L162) with no non-empty check, so an empty value is forwarded unchanged. `WireStructuredOutputsParams` is defined at [`#L115`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/rust/src/engine-core-client/src/protocol/structured_outputs.rs#L115).\n\nThe conversion maps each field to a constraint with no non-empty check, so an empty `json`/`grammar` string is forwarded unchanged:\n\n```rust\n// rust/src/engine-core-client/src/protocol/structured_outputs.rs Lines 135-162\nimpl TryFrom\u003cWireStructuredOutputsParams\u003e for StructuredOutputsParams {\n    type Error = Error;\n\n    fn try_from(raw: WireStructuredOutputsParams) -\u003e Result\u003cSelf\u003e {\n        use StructuredOutputConstraint::*;\n\n        let mut constraint = None;\n\n        macro_rules! insert_constraint {\n            ($name:literal, $value:expr) =\u003e {\n                if let Some(value) = $value {\n                    if let Some((existing, _)) = constraint {\n                        return Err(Error::InvalidStructuredOutputsParams {\n                            message: format!(\n                                \"multiple structured output constraints specified: {existing}, {}\",\n                                $name\n                            ),\n                        });\n                    }\n                    constraint = Some(($name, value));\n                }\n            };\n        }\n\n        insert_constraint!(\"json\", raw.json.map(Json));\n        insert_constraint!(\"regex\", raw.regex.map(Regex));\n        insert_constraint!(\"choice\", raw.choice.map(Choice));\n        insert_constraint!(\"grammar\", raw.grammar.map(Grammar));\n```\n\n## Impact\n\nAny client able to send an ordinary structured-output request (two requests for Site 1) can terminate the shared EngineCore, denying service to all tenants of that engine instance. Availability only; no code execution, memory corruption, or data disclosure.\n\n- **Site 1** affects the default `\"auto\"` structured-output backend; no speculative decoding or non-default configuration is required.\n- **Site 2** requires a deployment using the `guidance` backend together with `ngram_gpu` speculative decoding; the `-1` sentinel is produced by the proposer itself, so an ordinary constrained request suffices \u2014 the client does not craft the negative token.\n- **Site 3** requires the opt-in Rust frontend; a single request with an empty constraint value is enough. API-key middleware narrows the attacker from unauthenticated to authenticated but does not restore the missing validation.\n\n\n## Suggested Fix\n\nConvert structured-output failures into request-scoped errors at the boundary. Each site is a distinct fix shape; the core hunk for each is below.\n\n**Site 1** \u2014 resolve the backend per request instead of latching one process-wide, so a grammar is always compiled with the backend that `auto` actually selected for it (and a compile failure is that request\u0027s error, not the engine\u0027s):\n\n```python\n# vllm/v1/structured_output/__init__.py \u2014 grammar_init(), replacing the latched-backend path\nbackend = self._get_or_create_backend(request.structured_output_request.backend)\nif self._use_async_grammar_compilation:\n    grammar = self.executor.submit(self._create_grammar, request, backend)\nelse:\n    grammar = self._create_grammar(request, backend)\n```\n\n**Site 2** \u2014 drop negative sentinels before handing the row to the native matcher, inside `validate_tokens()`:\n\n```python\n# vllm/v1/structured_output/backend_guidance.py \u2014 validate_tokens(), before the ll_matcher call\nfor i, token in enumerate(tokens):\n    if token \u003c 0:\n        tokens = tokens[:i]\n        break\nif len(tokens) == 0:\n    return []\n```\n\n**Site 3** \u2014 reject empty `json`/`grammar` strings in the Rust wire-params conversion, matching the Python frontend, before the value reaches the engine:\n\n```rust\n// rust/src/engine-core-client/src/protocol/structured_outputs.rs \u2014 try_from(), before constraint mapping\nif matches!(\u0026raw.json, Some(Value::String(value)) if value.trim().is_empty()) {\n    return Err(Error::InvalidStructuredOutputsParams {\n        message: \"structured_outputs.json cannot be an empty string\".to_string(),\n    });\n}\nif matches!(\u0026raw.grammar, Some(value) if value.trim().is_empty()) {\n    return Err(Error::InvalidStructuredOutputsParams {\n        message: \"structured_outputs.grammar cannot be an empty string\".to_string(),\n    });\n}\n```\n\nThe three sites share one root cause and the same fix shape (bound the failure to the request), so they are filed as a single advisory; happy to split into per-component advisories if the maintainers prefer. Each fix carries a regression test.\n\n## Credit\n\n**Reported by:** Patch the Planet (Trail of Bits + OpenAI collaboration)\n\nThese vulnerabilities were discovered using GPT-5.5-Cyber as part of the Patch the Planet security initiative.\n\n---\n\n**Proposed fix:** a fix for this issue is proposed in a public pull request: https://github.com/vllm-project/vllm/pull/51450",
  "id": "GHSA-85xf-c7hm-whqw",
  "modified": "2026-10-05T23:42:44Z",
  "published": "2026-10-05T23:42:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-85xf-c7hm-whqw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/51450"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/c55e15a44ec4127832d4a86928a356fdd9e68dbd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/releases/tag/v0.30.0"
    }
  ],
  "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": "vLLM: Structured-output request errors escape the request boundary and terminate the shared EngineCore \u2014 engine-fatal denial of service (3 sites)"
}

GHSA-877P-G3P3-329R

Vulnerability from github – Published: 2026-05-01 18:31 – Updated: 2026-05-07 21:30
VLAI
Details

An issue was discovered in Vanetza V2X v26.02 allowing remote unauthorized attackers to cause a denial of service. The vulnerability exists in the GeoNetworking packet processing pipeline where OpenSSL exceptions from ECC point validation (invalid compressed point, point not on curve) are not properly caught by the Router::indicate() call chain. The openssl_wrapper.cpp check() function (line 19) throws openssl::Exception when OpenSSL operations fail. The parser's catch block in parse_secured() should catch these, but the exception escapes through subsequent processing stages (indicate_common, indicate_extended). This causes std::terminate, crashing the V2X receiver.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-37554"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-01T16:16:31Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Vanetza V2X v26.02 allowing remote unauthorized attackers to cause a denial of service. The vulnerability exists in the GeoNetworking packet processing pipeline where OpenSSL exceptions from ECC point validation (invalid compressed point, point not on curve) are not properly caught by the Router::indicate() call chain. The openssl_wrapper.cpp check() function (line 19) throws openssl::Exception when OpenSSL operations fail. The parser\u0027s catch block in parse_secured() should catch these, but the exception escapes through subsequent processing stages (indicate_common, indicate_extended). This causes std::terminate, crashing the V2X receiver.",
  "id": "GHSA-877p-g3p3-329r",
  "modified": "2026-05-07T21:30:24Z",
  "published": "2026-05-01T18:31:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/riebl/vanetza/security/advisories/GHSA-44qj-vh8c-5354"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-37554"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/sgInnora/45128ae15d52df7238680a8f2da8359f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/riebl/vanetza"
    },
    {
      "type": "WEB",
      "url": "https://github.com/riebl/vanetza/blob/master/vanetza/geonet/router.cpp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/riebl/vanetza/blob/master/vanetza/security/openssl_wrapper.cpp"
    }
  ],
  "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-87FW-525C-9H5M

Vulnerability from github – Published: 2026-08-29 00:31 – Updated: 2026-08-29 00:31
VLAI
Details

An unauthenticated party able to reach the port of a MongoDB Connector for BI (mongosqld) instance may generate enough routine connection log activity to exhaust the storage backing the configured log path. When a log write or log rotation operation subsequently fails, the resulting error is not handled and the shared mongosqld process ends, ending service for all connected SQL clients. The process continues to end on startup until an operator restores available storage, and the diagnostic message explaining the condition is not recorded.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-81517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-28T22:16:54Z",
    "severity": "HIGH"
  },
  "details": "An unauthenticated party able to reach the port of a MongoDB Connector for BI (mongosqld) instance may generate enough routine connection log activity to exhaust the storage backing the configured log path. When a log write or log rotation operation subsequently fails, the resulting error is not handled and the shared mongosqld process ends, ending service for all connected SQL clients. The process continues to end on startup until an operator restores available storage, and the diagnostic message explaining the condition is not recorded.",
  "id": "GHSA-87fw-525c-9h5m",
  "modified": "2026-08-29T00:31:03Z",
  "published": "2026-08-29T00:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81517"
    },
    {
      "type": "WEB",
      "url": "https://www.mongodb.com/docs/bi-connector/current/release-notes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-87MF-GV2C-C62C

Vulnerability from github – Published: 2026-06-19 06:31 – Updated: 2026-06-19 21:41
VLAI
Summary
ts-deepmerge: Prototype Method Override leads to DoS
Details

Versions of the package ts-deepmerge before 8.0.0 are vulnerable to Uncaught Exception due to the improper handling of built-in Object.prototype methods (such as toString, valueOf). When user-controlled input contains these keys with non-function values, the resulting merged object becomes broken — any string context operation throws a TypeError, crashing the application.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
5.5 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ts-deepmerge"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-12644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:41:52Z",
    "nvd_published_at": "2026-06-19T06:17:01Z",
    "severity": "MODERATE"
  },
  "details": "Versions of the package ts-deepmerge before 8.0.0 are vulnerable to Uncaught Exception due to the improper handling of built-in Object.prototype methods (such as toString, valueOf). When user-controlled input contains these keys with non-function values, the resulting merged object becomes broken \u2014 any string context operation throws a TypeError, crashing the application.",
  "id": "GHSA-87mf-gv2c-c62c",
  "modified": "2026-06-19T21:41:52Z",
  "published": "2026-06-19T06:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12644"
    },
    {
      "type": "WEB",
      "url": "https://github.com/voodoocreation/ts-deepmerge/commit/305a05831a462fb2c353d3cbbff55a0733286f8c"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/igorg1312/775fa00114c4d47df6ae0551779ab407"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/voodoocreation/ts-deepmerge"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-TSDEEPMERGE-17339141"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ts-deepmerge: Prototype Method Override leads to DoS"
}

GHSA-89V8-RHWQ-HF77

Vulnerability from github – Published: 2026-08-20 17:28 – Updated: 2026-08-20 17:28
VLAI
Summary
asteval has a Sandbox Escape via BaseException Subclasses
Details

Summary

An attacker who can supply expressions to asteval.Interpreter.eval() can raise SystemExit, KeyboardInterrupt, GeneratorExit, or BaseException from inside the sandbox. These exceptions are subclasses of BaseException but not Exception, so they bypass the except Exception: safety net in both run() and eval(). The exception propagates verbatim to the calling application, terminating the process or disrupting signal and cleanup handlers.

This is distinct from prior vulnerabilities CVE-2025-24359 (format string injection) and GHSA-vp47-9734-prjw (AST mutation TOCTOU), both fixed in 1.0.6. This vector is present in all versions including 1.0.6 and current HEAD.

Affected Code

asteval/astutils.py, lines 89–108 — FROM_PY exposes dangerous classes to sandbox users:

FROM_PY = ('ArithmeticError', 'AssertionError', 'AttributeError',
           'BaseException',          # ← escapes except Exception:
           'BufferError', 'BytesWarning',
           ...
           'GeneratorExit',          # ← escapes except Exception:
           ...
           'KeyboardInterrupt',      # ← escapes except Exception:
           ...
           'SystemExit',             # ← escapes except Exception:
           ...)

asteval/asteval.py, line 322 — run() exception handler:

except Exception:                    # ← does NOT catch BaseException subclasses
    if with_raise and self.expr is not None:
        self.raise_exception(node, expr=self.expr)

asteval/asteval.py, line 370 — eval() exception handler:

except Exception:                    # ← same gap
    if show_errors and not raise_errors:
        ...

asteval/asteval.py, line 264 — raise_exception() raises the class directly:

raise exc(self.error_msg)            # ← when exc=SystemExit, escapes both handlers above

Root Cause

Python's exception hierarchy has two distinct branches under BaseException:

BaseException
├── SystemExit          ← NOT caught by except Exception:
├── KeyboardInterrupt   ← NOT caught by except Exception:
├── GeneratorExit       ← NOT caught by except Exception:
└── Exception           ← caught normally
    ├── RuntimeError
    ├── ValueError
    └── ...

FROM_PY exposes all four non-Exception classes to sandbox users. When a user writes raise SystemExit("msg"), the on_raise() handler calls:

self.raise_exception(None, exc=out.__class__, msg=msg, expr='')

which executes raise SystemExit(msg). This propagates through both except Exception: guards unchecked and surfaces in the calling application.

Proof of Concept

from asteval import Interpreter

# Variant 1: terminate the process
aeval = Interpreter()
try:
    aeval.eval('raise SystemExit("terminated by sandbox user")')
except SystemExit as e:
    print(f"[CONFIRMED] SystemExit escaped: {e.code!r}")

# Variant 2: disrupt signal/finally handling
aeval = Interpreter()
try:
    aeval.eval('raise KeyboardInterrupt("interrupt injected")')
except KeyboardInterrupt as e:
    print(f"[CONFIRMED] KeyboardInterrupt escaped: {str(e)!r}")

# Variant 3: GeneratorExit
aeval = Interpreter()
try:
    aeval.eval('raise GeneratorExit("gen escape")')
except GeneratorExit as e:
    print(f"[CONFIRMED] GeneratorExit escaped: {str(e)!r}")

# Variant 4: BaseException base class
aeval = Interpreter()
try:
    aeval.eval('raise BaseException("base escape")')
except BaseException as e:
    if not isinstance(e, Exception):
        print(f"[CONFIRMED] BaseException escaped: {str(e)!r}")

Output (tested on asteval 1.0.6, Python 3.11/3.12):

[CONFIRMED] SystemExit escaped: 'terminated by sandbox user'
[CONFIRMED] KeyboardInterrupt escaped: 'interrupt injected'
[CONFIRMED] GeneratorExit escaped: 'gen escape'
[CONFIRMED] BaseException escaped: 'base escape'

Real-world server scenario

from asteval import Interpreter

def handle_request(user_expression):
    aeval = Interpreter()
    return aeval.eval(user_expression)   # SystemExit propagates here

# Attacker sends: raise SystemExit(1)
# Application terminates. Top-level except Exception: handlers do not protect it.
try:
    handle_request('raise SystemExit(1)')
except Exception:
    pass  # <-- does NOT catch SystemExit; process exits

Impact

Variant Impact
SystemExit Process terminates; exit code and message attacker-controlled
KeyboardInterrupt Disrupts finally blocks, signal handlers, and KeyboardInterrupt-aware loops
GeneratorExit Disrupts generator cleanup in calling code
BaseException Generic escape, same propagation

Any application that: - Accepts user-supplied expressions via asteval - Relies on except Exception: at the top level (standard practice) - Does not wrap aeval.eval() in except BaseException: (non-standard, unexpected requirement)

...is vulnerable to attacker-triggered process termination (DoS).

CVSS breakdown: Network-reachable (AV:N), no special conditions (AC:L), no credentials (PR:N), no interaction (UI:N), scope unchanged (S:U), no confidentiality/integrity impact (C:N/I:N), high availability impact — process termination (A:H).

Additional Note: File Read Capability (Acknowledged Limitation)

Independently of this vulnerability, asteval exposes a read-only open() wrapper (_open in astutils.py) that allows reading arbitrary files with the permissions of the calling process:

aeval.eval("open('/etc/passwd').read()")   # returns /etc/passwd contents

This is documented in doc/motivation.rst as a known design choice ("If reading from disk must be forbidden, you will want to overwrite the open() function from the symbol table"). It is included here for completeness, not as a separate advisory claim.

Recommended Fix

Option A — Remove dangerous classes from FROM_PY (minimal, preferred):

# asteval/astutils.py

FROM_PY = ('ArithmeticError', 'AssertionError', 'AttributeError',
           # Remove: 'BaseException',
           'BufferError', 'BytesWarning',
           'DeprecationWarning', 'EOFError', 'EnvironmentError',
           'Exception', 'False', 'FloatingPointError',
           # Remove: 'GeneratorExit',
           'IOError', 'ImportError', 'ImportWarning', 'IndentationError',
           'IndexError', 'KeyError',
           # Remove: 'KeyboardInterrupt',
           'LookupError',
           'MemoryError', 'NameError', 'None',
           'NotImplementedError', 'OSError', 'OverflowError',
           'ReferenceError', 'RuntimeError', 'RuntimeWarning',
           'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError',
           # Remove: 'SystemExit',
           'True', 'TypeError', ...)

Option B — Block non-Exception raises in on_raise():

# asteval/asteval.py

def on_raise(self, node):
    excnode = node.exc
    msgnode = node.cause
    out = self.run(excnode)
    # Prevent BaseException subclasses from escaping the sandbox
    if not issubclass(out.__class__, Exception):
        self.raise_exception(node, exc=RuntimeError,
                             msg=f"raising {out.__class__.__name__!r} is not permitted")
        return
    msg = ' '.join(str(a) for a in out.args)
    msg2 = self.run(msgnode)
    if msg2 not in (None, 'None'):
        msg = f"{msg}: {msg2}"
    self.raise_exception(None, exc=out.__class__, msg=msg, expr='')

Note: Option B also fixes a secondary bug on the same line — ' '.join(out.args) crashes with TypeError when args contain non-strings (e.g., raise SystemExit(0) with integer code). The fix uses str(a) for a in out.args.

Option C — Catch BaseException in run() and eval() (broadest, requires care):

except BaseException as exc:
    if isinstance(exc, (SystemExit, KeyboardInterrupt, GeneratorExit)):
        # Re-raise as RuntimeError to contain within sandbox
        self.raise_exception(node, exc=RuntimeError,
                             msg=f"{type(exc).__name__} raised in sandbox")
    elif with_raise and self.expr is not None:
        self.raise_exception(node, expr=self.expr)

Option A is the simplest and least likely to introduce regressions. Option B additionally addresses the str.join crash on integer args.

Disclosure Timeline

Date Event
2026-06-09 Vulnerability discovered during code review
2026-06-09 Report submitted via GitHub Security Advisory
TBD Maintainer acknowledgment
TBD + 90 days Public disclosure deadline

Researcher

Independent security researcher. No bug bounty program exists for this project. CVE assignment requested via GitHub Security Advisory submission.

References

  • Prior CVE: CVE-2025-24359 (format string injection, fixed 1.0.6)
  • Prior advisory: GHSA-vp47-9734-prjw (AST mutation TOCTOU, fixed 1.0.6)
  • Python exception hierarchy: https://docs.python.org/3/library/exceptions.html#exception-hierarchy
  • asteval documentation: https://lmfit.github.io/asteval/
Severity
5.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "asteval"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-20T17:28:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAn attacker who can supply expressions to `asteval.Interpreter.eval()` can raise `SystemExit`,\n`KeyboardInterrupt`, `GeneratorExit`, or `BaseException` from inside the sandbox. These\nexceptions are subclasses of `BaseException` but not `Exception`, so they bypass the\n`except Exception:` safety net in both `run()` and `eval()`. The exception propagates\nverbatim to the calling application, terminating the process or disrupting signal and\ncleanup handlers.\n\nThis is distinct from prior vulnerabilities CVE-2025-24359 (format string injection) and\nGHSA-vp47-9734-prjw (AST mutation TOCTOU), both fixed in 1.0.6. This vector is present in\nall versions including 1.0.6 and current HEAD.\n\n---\n\n## Affected Code\n\n**`asteval/astutils.py`, lines 89\u2013108** \u2014 `FROM_PY` exposes dangerous classes to sandbox users:\n\n```python\nFROM_PY = (\u0027ArithmeticError\u0027, \u0027AssertionError\u0027, \u0027AttributeError\u0027,\n           \u0027BaseException\u0027,          # \u2190 escapes except Exception:\n           \u0027BufferError\u0027, \u0027BytesWarning\u0027,\n           ...\n           \u0027GeneratorExit\u0027,          # \u2190 escapes except Exception:\n           ...\n           \u0027KeyboardInterrupt\u0027,      # \u2190 escapes except Exception:\n           ...\n           \u0027SystemExit\u0027,             # \u2190 escapes except Exception:\n           ...)\n```\n\n**`asteval/asteval.py`, line 322** \u2014 `run()` exception handler:\n\n```python\nexcept Exception:                    # \u2190 does NOT catch BaseException subclasses\n    if with_raise and self.expr is not None:\n        self.raise_exception(node, expr=self.expr)\n```\n\n**`asteval/asteval.py`, line 370** \u2014 `eval()` exception handler:\n\n```python\nexcept Exception:                    # \u2190 same gap\n    if show_errors and not raise_errors:\n        ...\n```\n\n**`asteval/asteval.py`, line 264** \u2014 `raise_exception()` raises the class directly:\n\n```python\nraise exc(self.error_msg)            # \u2190 when exc=SystemExit, escapes both handlers above\n```\n\n---\n\n## Root Cause\n\nPython\u0027s exception hierarchy has two distinct branches under `BaseException`:\n\n```\nBaseException\n\u251c\u2500\u2500 SystemExit          \u2190 NOT caught by except Exception:\n\u251c\u2500\u2500 KeyboardInterrupt   \u2190 NOT caught by except Exception:\n\u251c\u2500\u2500 GeneratorExit       \u2190 NOT caught by except Exception:\n\u2514\u2500\u2500 Exception           \u2190 caught normally\n    \u251c\u2500\u2500 RuntimeError\n    \u251c\u2500\u2500 ValueError\n    \u2514\u2500\u2500 ...\n```\n\n`FROM_PY` exposes all four non-`Exception` classes to sandbox users. When a user writes\n`raise SystemExit(\"msg\")`, the `on_raise()` handler calls:\n\n```python\nself.raise_exception(None, exc=out.__class__, msg=msg, expr=\u0027\u0027)\n```\n\nwhich executes `raise SystemExit(msg)`. This propagates through both `except Exception:`\nguards unchecked and surfaces in the calling application.\n\n---\n\n## Proof of Concept\n\n```python\nfrom asteval import Interpreter\n\n# Variant 1: terminate the process\naeval = Interpreter()\ntry:\n    aeval.eval(\u0027raise SystemExit(\"terminated by sandbox user\")\u0027)\nexcept SystemExit as e:\n    print(f\"[CONFIRMED] SystemExit escaped: {e.code!r}\")\n\n# Variant 2: disrupt signal/finally handling\naeval = Interpreter()\ntry:\n    aeval.eval(\u0027raise KeyboardInterrupt(\"interrupt injected\")\u0027)\nexcept KeyboardInterrupt as e:\n    print(f\"[CONFIRMED] KeyboardInterrupt escaped: {str(e)!r}\")\n\n# Variant 3: GeneratorExit\naeval = Interpreter()\ntry:\n    aeval.eval(\u0027raise GeneratorExit(\"gen escape\")\u0027)\nexcept GeneratorExit as e:\n    print(f\"[CONFIRMED] GeneratorExit escaped: {str(e)!r}\")\n\n# Variant 4: BaseException base class\naeval = Interpreter()\ntry:\n    aeval.eval(\u0027raise BaseException(\"base escape\")\u0027)\nexcept BaseException as e:\n    if not isinstance(e, Exception):\n        print(f\"[CONFIRMED] BaseException escaped: {str(e)!r}\")\n```\n\n**Output (tested on asteval 1.0.6, Python 3.11/3.12):**\n\n```\n[CONFIRMED] SystemExit escaped: \u0027terminated by sandbox user\u0027\n[CONFIRMED] KeyboardInterrupt escaped: \u0027interrupt injected\u0027\n[CONFIRMED] GeneratorExit escaped: \u0027gen escape\u0027\n[CONFIRMED] BaseException escaped: \u0027base escape\u0027\n```\n\n### Real-world server scenario\n\n```python\nfrom asteval import Interpreter\n\ndef handle_request(user_expression):\n    aeval = Interpreter()\n    return aeval.eval(user_expression)   # SystemExit propagates here\n\n# Attacker sends: raise SystemExit(1)\n# Application terminates. Top-level except Exception: handlers do not protect it.\ntry:\n    handle_request(\u0027raise SystemExit(1)\u0027)\nexcept Exception:\n    pass  # \u003c-- does NOT catch SystemExit; process exits\n```\n\n---\n\n## Impact\n\n| Variant | Impact |\n|---------|--------|\n| `SystemExit` | Process terminates; exit code and message attacker-controlled |\n| `KeyboardInterrupt` | Disrupts `finally` blocks, signal handlers, and `KeyboardInterrupt`-aware loops |\n| `GeneratorExit` | Disrupts generator cleanup in calling code |\n| `BaseException` | Generic escape, same propagation |\n\nAny application that:\n- Accepts user-supplied expressions via `asteval`\n- Relies on `except Exception:` at the top level (standard practice)\n- Does not wrap `aeval.eval()` in `except BaseException:` (non-standard, unexpected requirement)\n\n...is vulnerable to attacker-triggered process termination (DoS).\n\nCVSS breakdown: Network-reachable (AV:N), no special conditions (AC:L), no credentials (PR:N),\nno interaction (UI:N), scope unchanged (S:U), no confidentiality/integrity impact (C:N/I:N),\nhigh availability impact \u2014 process termination (A:H).\n\n---\n\n## Additional Note: File Read Capability (Acknowledged Limitation)\n\nIndependently of this vulnerability, `asteval` exposes a read-only `open()` wrapper\n(`_open` in `astutils.py`) that allows reading arbitrary files with the permissions of the\ncalling process:\n\n```python\naeval.eval(\"open(\u0027/etc/passwd\u0027).read()\")   # returns /etc/passwd contents\n```\n\nThis is documented in `doc/motivation.rst` as a known design choice (\"If reading from disk\nmust be forbidden, you will want to overwrite the `open()` function from the symbol table\").\nIt is included here for completeness, not as a separate advisory claim.\n\n---\n\n## Recommended Fix\n\n**Option A \u2014 Remove dangerous classes from `FROM_PY` (minimal, preferred):**\n\n```python\n# asteval/astutils.py\n\nFROM_PY = (\u0027ArithmeticError\u0027, \u0027AssertionError\u0027, \u0027AttributeError\u0027,\n           # Remove: \u0027BaseException\u0027,\n           \u0027BufferError\u0027, \u0027BytesWarning\u0027,\n           \u0027DeprecationWarning\u0027, \u0027EOFError\u0027, \u0027EnvironmentError\u0027,\n           \u0027Exception\u0027, \u0027False\u0027, \u0027FloatingPointError\u0027,\n           # Remove: \u0027GeneratorExit\u0027,\n           \u0027IOError\u0027, \u0027ImportError\u0027, \u0027ImportWarning\u0027, \u0027IndentationError\u0027,\n           \u0027IndexError\u0027, \u0027KeyError\u0027,\n           # Remove: \u0027KeyboardInterrupt\u0027,\n           \u0027LookupError\u0027,\n           \u0027MemoryError\u0027, \u0027NameError\u0027, \u0027None\u0027,\n           \u0027NotImplementedError\u0027, \u0027OSError\u0027, \u0027OverflowError\u0027,\n           \u0027ReferenceError\u0027, \u0027RuntimeError\u0027, \u0027RuntimeWarning\u0027,\n           \u0027StopIteration\u0027, \u0027SyntaxError\u0027, \u0027SyntaxWarning\u0027, \u0027SystemError\u0027,\n           # Remove: \u0027SystemExit\u0027,\n           \u0027True\u0027, \u0027TypeError\u0027, ...)\n```\n\n**Option B \u2014 Block non-`Exception` raises in `on_raise()`:**\n\n```python\n# asteval/asteval.py\n\ndef on_raise(self, node):\n    excnode = node.exc\n    msgnode = node.cause\n    out = self.run(excnode)\n    # Prevent BaseException subclasses from escaping the sandbox\n    if not issubclass(out.__class__, Exception):\n        self.raise_exception(node, exc=RuntimeError,\n                             msg=f\"raising {out.__class__.__name__!r} is not permitted\")\n        return\n    msg = \u0027 \u0027.join(str(a) for a in out.args)\n    msg2 = self.run(msgnode)\n    if msg2 not in (None, \u0027None\u0027):\n        msg = f\"{msg}: {msg2}\"\n    self.raise_exception(None, exc=out.__class__, msg=msg, expr=\u0027\u0027)\n```\n\nNote: Option B also fixes a secondary bug on the same line \u2014 `\u0027 \u0027.join(out.args)` crashes\nwith `TypeError` when args contain non-strings (e.g., `raise SystemExit(0)` with integer\ncode). The fix uses `str(a) for a in out.args`.\n\n**Option C \u2014 Catch `BaseException` in `run()` and `eval()` (broadest, requires care):**\n\n```python\nexcept BaseException as exc:\n    if isinstance(exc, (SystemExit, KeyboardInterrupt, GeneratorExit)):\n        # Re-raise as RuntimeError to contain within sandbox\n        self.raise_exception(node, exc=RuntimeError,\n                             msg=f\"{type(exc).__name__} raised in sandbox\")\n    elif with_raise and self.expr is not None:\n        self.raise_exception(node, expr=self.expr)\n```\n\nOption A is the simplest and least likely to introduce regressions. Option B additionally\naddresses the `str.join` crash on integer args.\n\n---\n\n## Disclosure Timeline\n\n| Date | Event |\n|------|-------|\n| 2026-06-09 | Vulnerability discovered during code review |\n| 2026-06-09 | Report submitted via GitHub Security Advisory |\n| TBD | Maintainer acknowledgment |\n| TBD + 90 days | Public disclosure deadline |\n\n---\n\n## Researcher\n\nIndependent security researcher. No bug bounty program exists for this project.\nCVE assignment requested via GitHub Security Advisory submission.\n\n---\n\n## References\n\n- Prior CVE: CVE-2025-24359 (format string injection, fixed 1.0.6)\n- Prior advisory: GHSA-vp47-9734-prjw (AST mutation TOCTOU, fixed 1.0.6)\n- Python exception hierarchy: https://docs.python.org/3/library/exceptions.html#exception-hierarchy\n- `asteval` documentation: https://lmfit.github.io/asteval/",
  "id": "GHSA-89v8-rhwq-hf77",
  "modified": "2026-08-20T17:28:52Z",
  "published": "2026-08-20T17:28:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lmfit/asteval/security/advisories/GHSA-89v8-rhwq-hf77"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lmfit/asteval/pull/153"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lmfit/asteval/commit/a3e56e7f8ed567a4817684d94213b290359077b4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lmfit/asteval"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lmfit/asteval/releases/tag/1.0.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "asteval has a Sandbox Escape via BaseException Subclasses"
}

GHSA-8C5G-69WP-X3WV

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

Deserialization vulnerability in the IPC module Impact: Successful exploitation of this vulnerability may affect availability.

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-48907"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-06T07:15:26Z",
    "severity": "MODERATE"
  },
  "details": "Deserialization vulnerability in the IPC module\nImpact: Successful exploitation of this vulnerability may affect availability.",
  "id": "GHSA-8c5g-69wp-x3wv",
  "modified": "2025-06-06T09:30:24Z",
  "published": "2025-06-06T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48907"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2025/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8GV7-MMCH-W6H8

Vulnerability from github – Published: 2024-11-13 21:30 – Updated: 2024-11-13 21:30
VLAI
Details

Uncaught exception for some Intel(R) CST software before version 8.7.10803 may allow an authenticated user to potentially enable denial of service via local access.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
6.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-29076"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-13T21:15:15Z",
    "severity": "MODERATE"
  },
  "details": "Uncaught exception for some Intel(R) CST software before version 8.7.10803 may allow an authenticated user to potentially enable denial of service via local access.",
  "id": "GHSA-8gv7-mmch-w6h8",
  "modified": "2024-11-13T21:30:36Z",
  "published": "2024-11-13T21:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29076"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01024.html"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/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"
    }
  ]
}

GHSA-8J4C-6X6G-RQ3J

Vulnerability from github – Published: 2026-10-08 19:40 – Updated: 2026-10-08 19:40
VLAI
Summary
music-metadata: uncatchable process crash parsing a crafted `.dsf` (residual of GHSA-v6c2-xwv6-8xf7)
Details

Summary

DsfParser.parseChunks skips an unrecognised chunk's payload with an un-awaited call:

this.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len);   // lib/dsf/DsfParser.js:51 — no await

ChunkHeader.len is 12. A crafted .dsf chunk with id != 'fmt ' and size in 0..11 makes the argument negative; strtok3 (≥ 10.3.5) throws RangeError on a negative ignore. Because the call is fire-and-forget, the rejection is detached from the parseBuffer() promise chain → unhandled rejection → Node's default (≥ 15) crashes the process — after parseBuffer() already resolved, so a caller's try/catch catches nothing and is still taken down.

Residual of GHSA-v6c2-xwv6-8xf7: the ASF site was fixed in 11.12.3 (size validation) and strtok3 now throws on negative ignore; the DSF site was never validated, and its missing await escalates that throw into an uncatchable crash.

Root cause (lib/dsf/DsfParser.js:34-56)

while (bytesRemaining >= ChunkHeader.len) {               // ChunkHeader.len = 12
  const chunkHeader = await this.tokenizer.readToken(ChunkHeader);   // { id, size }
  switch (chunkHeader.id) {
    case 'fmt ': { ...; return; }
    default: this.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len); break;  // size<12 -> negative, no await
  }
  bytesRemaining -= chunkHeader.size;
}

strtok3 AbstractTokenizer.ignore (L78-79): if (length < 0) throw new RangeError('ignore length must be ≥ 0 bytes');

Steps to reproduce

repro/ — public API only, Node's default unhandled-rejection mode, try/catch around the parse:

npm install && node poc.mjs

Confirmed on 11.14.0:

[app] parseBuffer() RESOLVED — the caller saw no error to catch.
RangeError: ignore length must be ≥ 0 bytes
    at DsfParser.parseChunks (.../lib/dsf/DsfParser.js:51)
   <process exits non-zero — the "process survived" line never prints>

Impact

DoS: a single crafted .dsf (or any file with the DSD magic) crashes the Node process of any app parsing untrusted audio with music-metadata (2.2M weekly downloads). The crash bypasses the caller's error handling, so even apps that correctly try/catch per-file parsing are killed — one malicious upload can take down a shared server/worker.

Remediation

Add await on line 51 (makes the RangeError a catchable parse error), and validate chunkHeader.size >= ChunkHeader.len before the skip (as the ASF fix did; also guards the loop counter). Audit other parsers for un-awaited tokenizer.ignore()/readToken().

Scope / honesty

Requires the DSF path (a DSD-magic file — normal auto-detection). Relies on Node's default unhandled-rejection mode (throw, default since Node 15); the point is that the standard defensive per-parse try/catch does not protect against it. Crash (availability), not disclosure/RCE. Negatives confirmed alongside: ASF infinite loop fixed; negative-ignore infinite-loop class closed at strtok3; unbounded allocation bounded by strtok3's read bound-check.

Credits

Issue also reported by @ryu7eroo

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.14.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "music-metadata"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107392"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T19:40:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n`DsfParser.parseChunks` skips an unrecognised chunk\u0027s payload with an **un-awaited** call:\n```js\nthis.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len);   // lib/dsf/DsfParser.js:51 \u2014 no await\n```\n`ChunkHeader.len` is 12. A crafted `.dsf` chunk with `id != \u0027fmt \u0027` and `size` in `0..11` makes the\nargument negative; strtok3 (\u2265 10.3.5) throws `RangeError` on a negative `ignore`. Because the call\nis fire-and-forget, the rejection is **detached from the `parseBuffer()` promise chain** \u2192 unhandled\nrejection \u2192 Node\u0027s default (\u2265 15) **crashes the process** \u2014 **after** `parseBuffer()` already\nresolved, so a caller\u0027s `try/catch` catches nothing and is still taken down.\n\nResidual of GHSA-v6c2-xwv6-8xf7: the ASF site was fixed in 11.12.3 (size validation) and strtok3\nnow throws on negative `ignore`; the DSF site was never validated, and its missing `await`\nescalates that throw into an **uncatchable** crash.\n\n## Root cause (`lib/dsf/DsfParser.js:34-56`)\n```js\nwhile (bytesRemaining \u003e= ChunkHeader.len) {               // ChunkHeader.len = 12\n  const chunkHeader = await this.tokenizer.readToken(ChunkHeader);   // { id, size }\n  switch (chunkHeader.id) {\n    case \u0027fmt \u0027: { ...; return; }\n    default: this.tokenizer.ignore(Number(chunkHeader.size) - ChunkHeader.len); break;  // size\u003c12 -\u003e negative, no await\n  }\n  bytesRemaining -= chunkHeader.size;\n}\n```\nstrtok3 `AbstractTokenizer.ignore` (L78-79): `if (length \u003c 0) throw new RangeError(\u0027ignore length must be \u2265 0 bytes\u0027);`\n\n## Steps to reproduce\n`repro/` \u2014 public API only, Node\u0027s default unhandled-rejection mode, `try/catch` around the parse:\n```\nnpm install \u0026\u0026 node poc.mjs\n```\nConfirmed on 11.14.0:\n```\n[app] parseBuffer() RESOLVED \u2014 the caller saw no error to catch.\nRangeError: ignore length must be \u2265 0 bytes\n    at DsfParser.parseChunks (.../lib/dsf/DsfParser.js:51)\n   \u003cprocess exits non-zero \u2014 the \"process survived\" line never prints\u003e\n```\n\n## Impact\nDoS: a single crafted `.dsf` (or any file with the `DSD ` magic) crashes the Node process of any\napp parsing untrusted audio with music-metadata (2.2M weekly downloads). The crash bypasses the\ncaller\u0027s error handling, so even apps that correctly `try/catch` per-file parsing are killed \u2014 one\nmalicious upload can take down a shared server/worker.\n\n## Remediation\nAdd `await` on line 51 (makes the `RangeError` a catchable parse error), and validate\n`chunkHeader.size \u003e= ChunkHeader.len` before the skip (as the ASF fix did; also guards the loop\ncounter). Audit other parsers for un-awaited `tokenizer.ignore()`/`readToken()`.\n\n## Scope / honesty\nRequires the DSF path (a `DSD `-magic file \u2014 normal auto-detection). Relies on Node\u0027s default\nunhandled-rejection mode (`throw`, default since Node 15); the point is that the standard defensive\nper-parse `try/catch` does not protect against it. Crash (availability), not disclosure/RCE.\nNegatives confirmed alongside: ASF infinite loop fixed; negative-`ignore` infinite-loop class\nclosed at strtok3; unbounded allocation bounded by strtok3\u0027s read bound-check.\n\n## Credits\nIssue also reported by @ryu7eroo",
  "id": "GHSA-8j4c-6x6g-rq3j",
  "modified": "2026-10-08T19:40:45Z",
  "published": "2026-10-08T19:40:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-8j4c-6x6g-rq3j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/pull/2700"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/commit/e7fc27a96e789d41ece41fdac590fc7618274a41"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Borewit/music-metadata"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/releases/tag/v11.15.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "music-metadata: uncatchable process crash parsing a crafted `.dsf` (residual of GHSA-v6c2-xwv6-8xf7)"
}

GHSA-8R4G-CG4M-X23C

Vulnerability from github – Published: 2021-09-22 18:22 – Updated: 2025-10-03 18:27
VLAI
Summary
Denial of Service in node-static
Details

All versions of node-static are vulnerable to a Denial of Service. The package fails to catch an exception when user input includes null bytes. This allows attackers to access http://host/%00 and crash the server.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "node-static"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.7.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-22T18:21:20Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "All versions of node-static are vulnerable to a Denial of Service. The package fails to catch an exception when user input includes null bytes. This allows attackers to access `http://host/%00` and crash the server.",
  "id": "GHSA-8r4g-cg4m-x23c",
  "modified": "2025-10-03T18:27:42Z",
  "published": "2021-09-22T18:22:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11149"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudhead/node-static/pull/213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/advisory-database/pull/6248"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudhead/node-static"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudhead/node-static/blob/643a528ec7bbd05a59c4030655d94810570afb3f/CHANGES.md#-unreleased"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-NODESTATIC-1297183"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Denial of Service in node-static"
}

GHSA-8RF5-92JH-3VC9

Vulnerability from github – Published: 2021-05-13 22:31 – Updated: 2021-04-06 21:46
VLAI
Summary
Uncaught Exception leading to Denial of Service in json-sanitizer
Details

OWASP json-sanitizer before 1.2.2 can output invalid JSON or throw an undeclared exception for crafted input. This may lead to denial of service if the application is not prepared to handle these situations.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.mikesamuel:json-sanitizer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23900"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-06T21:46:21Z",
    "nvd_published_at": "2021-01-13T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "OWASP json-sanitizer before 1.2.2 can output invalid JSON or throw an undeclared exception for crafted input. This may lead to denial of service if the application is not prepared to handle these situations.",
  "id": "GHSA-8rf5-92jh-3vc9",
  "modified": "2021-04-06T21:46:21Z",
  "published": "2021-05-13T22:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23900"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OWASP/json-sanitizer/commit/a37f594f7378a1c76b3283e0dab9e1ab1dc0247e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OWASP/json-sanitizer/compare/v1.2.1...v1.2.2"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/json-sanitizer-support/c/dAW1AeNMoA0"
    }
  ],
  "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": "Uncaught Exception leading to Denial of Service in json-sanitizer"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list