Common Weakness Enumeration

CWE-617

Allowed

Reachable Assertion

Abstraction: Base · Status: Draft

The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.

1052 vulnerabilities reference this CWE, most recent first.

GHSA-Q8GQ-377P-JQ3R

Vulnerability from github – Published: 2026-06-16 17:34 – Updated: 2026-09-01 15:30
VLAI
Summary
vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution
Details

Summary

An assert-based security check in vLLM's activation function loading allows any unauthenticated attacker to achieve arbitrary code execution on the server by publishing a malicious HuggingFace model, when vLLM runs in Python optimized mode (python -O or PYTHONOPTIMIZE=1).

Details

vLLM uses an assert statement at vllm/model_executor/layers/pooler/activations.py:48 as its sole security control to restrict which activation functions can be loaded from a HuggingFace model's config.json:

# vllm/model_executor/layers/pooler/activations.py:35-53
function_name: str | None = None
if (
    hasattr(config, "sentence_transformers")
    and "activation_fn" in config.sentence_transformers
):
    function_name = config.sentence_transformers["activation_fn"]
elif (
    hasattr(config, "sbert_ce_default_activation_function")
    and config.sbert_ce_default_activation_function is not None
):
    function_name = config.sbert_ce_default_activation_function

if function_name is not None:
    assert function_name.startswith("torch.nn.modules."), (
        "Loading of activation functions is restricted to "
        "torch.nn.modules for security reasons"
    )
    fn = resolve_obj_by_qualname(function_name)()

Python's assert statements are stripped at compile time when running in optimized mode (python -O or PYTHONOPTIMIZE=1). When the assert is absent, the attacker-controlled function_name from the model's config.json is passed directly to resolve_obj_by_qualname() — an unrestricted import gadget:

def resolve_obj_by_qualname(qualname: str) -> Any:
    module_name, obj_name = qualname.rsplit(".", 1)
    module = importlib.import_module(module_name)
    return getattr(module, obj_name)

This is the same vulnerability class as CVE-2017-1000433 (pysaml2 assert-based auth bypass), flagged by Bandit B101 and Ruff S101, and the reason Django proactively replaced all assert-based security checks (ticket #32508).

Attacker-controlled input sources: - config.sentence_transformers["activation_fn"] (line 40) - config.sbert_ce_default_activation_function (line 45)

Affected call sitesget_act_fn() is called via resolve_classifier_act_fn() from: - vllm/model_executor/layers/pooler/seqwise/poolers.py:122 — SequencePooler - vllm/model_executor/layers/pooler/tokwise/poolers.py:130 — TokenPooler

Broader systemic risk: resolve_obj_by_qualname is called from ~20 locations across the codebase with no validation of its own. Any future caller feeding user-controlled input to it without validation creates the same vulnerability class.

Suggested fix: Replace the assert with an explicit conditional raise:

if not function_name.startswith("torch.nn.modules."):
    raise ValueError(
        "Loading of activation functions is restricted to "
        "torch.nn.modules for security reasons"
    )

Impact

Arbitrary code execution. A malicious model author publishes a HuggingFace model with a crafted config.json. When a victim loads this model with vLLM running under python -O or PYTHONOPTIMIZE=1, arbitrary code executes during model initialization with the privileges of the vLLM process.

The attack requires: 1. Victim loads a malicious model from HuggingFace (user interaction) 2. vLLM runs under python -O or PYTHONOPTIMIZE=1 (documented in production use) 3. Model uses a cross-encoder architecture (e.g. BERT or RoBERTa with sequence classification)

Coordinated disclosure note: This vulnerability was also reported via huntr.com on April 2, 2026 (https://huntr.com/bounties/dcb05b04-e625-41e7-adbc-bbae0cc2d64c). A GitHub Security Advisory was also filed because it is vLLM's stated preferred disclosure channel per SECURITY.md.

Fix

A fix for this was introduced in this commit: https://github.com/vllm-project/vllm/commit/b3c7ffcab82c2439726f8cb213800f6f38c023d3

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T17:34:49Z",
    "nvd_published_at": "2026-06-22T23:16:30Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAn `assert`-based security check in vLLM\u0027s activation function loading allows any unauthenticated attacker to achieve arbitrary code execution on the server by publishing a malicious HuggingFace model, when vLLM runs in Python optimized mode (`python -O` or `PYTHONOPTIMIZE=1`).\n\n### Details\n\nvLLM uses an `assert` statement at [`vllm/model_executor/layers/pooler/activations.py:48`](https://github.com/vllm-project/vllm/blob/main/vllm/model_executor/layers/pooler/activations.py#L48) as its sole security control to restrict which activation functions can be loaded from a HuggingFace model\u0027s `config.json`:\n\n```python\n# vllm/model_executor/layers/pooler/activations.py:35-53\nfunction_name: str | None = None\nif (\n    hasattr(config, \"sentence_transformers\")\n    and \"activation_fn\" in config.sentence_transformers\n):\n    function_name = config.sentence_transformers[\"activation_fn\"]\nelif (\n    hasattr(config, \"sbert_ce_default_activation_function\")\n    and config.sbert_ce_default_activation_function is not None\n):\n    function_name = config.sbert_ce_default_activation_function\n\nif function_name is not None:\n    assert function_name.startswith(\"torch.nn.modules.\"), (\n        \"Loading of activation functions is restricted to \"\n        \"torch.nn.modules for security reasons\"\n    )\n    fn = resolve_obj_by_qualname(function_name)()\n```\n\nPython\u0027s `assert` statements are stripped at compile time when running in optimized mode (`python -O` or `PYTHONOPTIMIZE=1`). When the assert is absent, the attacker-controlled `function_name` from the model\u0027s `config.json` is passed directly to [`resolve_obj_by_qualname()`](https://github.com/vllm-project/vllm/blob/main/vllm/utils/import_utils.py#L106) \u2014 an unrestricted import gadget:\n\n```python\ndef resolve_obj_by_qualname(qualname: str) -\u003e Any:\n    module_name, obj_name = qualname.rsplit(\".\", 1)\n    module = importlib.import_module(module_name)\n    return getattr(module, obj_name)\n```\n\nThis is the same vulnerability class as **CVE-2017-1000433** (pysaml2 assert-based auth bypass), flagged by Bandit B101 and Ruff S101, and the reason Django proactively replaced all assert-based security checks (ticket #32508).\n\n**Attacker-controlled input sources:**\n- `config.sentence_transformers[\"activation_fn\"]` (line 40)\n- `config.sbert_ce_default_activation_function` (line 45)\n\n**Affected call sites** \u2014 `get_act_fn()` is called via `resolve_classifier_act_fn()` from:\n- `vllm/model_executor/layers/pooler/seqwise/poolers.py:122` \u2014 SequencePooler\n- `vllm/model_executor/layers/pooler/tokwise/poolers.py:130` \u2014 TokenPooler\n\n**Broader systemic risk:** `resolve_obj_by_qualname` is called from ~20 locations across the codebase with no validation of its own. Any future caller feeding user-controlled input to it without validation creates the same vulnerability class.\n\n**Suggested fix:** Replace the `assert` with an explicit conditional raise:\n\n```python\nif not function_name.startswith(\"torch.nn.modules.\"):\n    raise ValueError(\n        \"Loading of activation functions is restricted to \"\n        \"torch.nn.modules for security reasons\"\n    )\n```\n\n### Impact\n\n**Arbitrary code execution.** A malicious model author publishes a HuggingFace model with a crafted `config.json`. When a victim loads this model with vLLM running under `python -O` or `PYTHONOPTIMIZE=1`, arbitrary code executes during model initialization with the privileges of the vLLM process.\n\nThe attack requires:\n1. Victim loads a malicious model from HuggingFace (user interaction)\n2. vLLM runs under `python -O` or `PYTHONOPTIMIZE=1` (documented in production use)\n3. Model uses a cross-encoder architecture (e.g. BERT or RoBERTa with sequence classification)\n\n**Coordinated disclosure note:** This vulnerability was also reported via huntr.com on April 2, 2026 (https://huntr.com/bounties/dcb05b04-e625-41e7-adbc-bbae0cc2d64c). A GitHub Security Advisory was also filed because it is vLLM\u0027s stated preferred disclosure channel per SECURITY.md.\n\n### Fix\n\nA fix for this was introduced in this commit: https://github.com/vllm-project/vllm/commit/b3c7ffcab82c2439726f8cb213800f6f38c023d3",
  "id": "GHSA-q8gq-377p-jq3r",
  "modified": "2026-09-01T15:30:48Z",
  "published": "2026-06-16T17:34:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-q8gq-377p-jq3r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41523"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/b3c7ffcab82c2439726f8cb213800f6f38c023d3"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-41523.json"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/dcb05b04-e625-41e7-adbc-bbae0cc2d64c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-2300.yaml"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491582"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-41523"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:61629"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:61627"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59151"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59144"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59139"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59138"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57390"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57389"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57387"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:57380"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36006"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36005"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vLLM: Security Check Bypass via assert Statement in Activation Function Loading Allows Arbitrary Code Execution"
}

GHSA-Q8HX-MM92-4WVG

Vulnerability from github – Published: 2024-10-09 19:14 – Updated: 2026-06-08 20:00
VLAI
Summary
wasmtime has a runtime crash when combining tail calls with trapping imports
Details

Impact

Wasmtime's implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later.

WebAssembly tail calls are a proposal which relatively recently reached stage 4 in the standardization process. Wasmtime first enabled support for tail calls by default in Wasmtime 21.0.0, although that release contained a bug where it was only on-by-default for some configurations. In Wasmtime 22.0.0 tail calls were enabled by default for all configurations.

The specific crash happens when an exported function in a WebAssembly module (or component) performs a return_call (or return_call_indirect or return_call_ref) to an imported host function which captures a stack trace (for example, the host function raises a trap). In this situation, the stack-walking code previously assumed there was always at least one WebAssembly frame on the stack but with tail calls that is no longer true. With the tail-call proposal it's possible to have an entry trampoline appear as if it directly called the exit trampoline. This situation triggers an internal assert in the stack-walking code which raises a Rust panic!().

When Wasmtime is compiled with Rust versions 1.80 and prior this means that an extern "C" function in Rust is raising a panic!(). This is technically undefined behavior and typically manifests as a process abort when the unwinder fails to unwind Cranelift-generated frames. When Wasmtime is compiled with Rust versions 1.81 and later this panic becomes a deterministic process abort.

Overall the impact of this issue is that this is a denial-of-service vector where a malicious WebAssembly module or component can cause the host to crash. There is no other impact at this time other than availability of a service as the result of the crash is always a crash and no more.

This issue was discovered by routine fuzzing performed by the Wasmtime project via Google's OSS-Fuzz infrastructure. We have no evidence that it has ever been exploited by an attacker in the wild.

Patches

All versions of Wasmtime which have tail calls enabled by default have been patched:

  • 21.0.x - patched in 21.0.2
  • 22.0.x - patched in 22.0.1
  • 23.0.x - patched in 23.0.3
  • 24.0.x - patched in 24.0.1
  • 25.0.x - patched in 25.0.2

Wasmtime versions from 12.0.x (the first release with experimental tail call support) to 20.0.x (the last release with tail-calls off-by-default) have support for tail calls but the support is disabled by default. These versions are not affected in their default configurations, but users who explicitly enabled tail call support will need to either disable tail call support or upgrade to a patched version of Wasmtime.

Workarounds

The main workaround for this issue is to disable tail support for tail calls in Wasmtime, for example with Config::wasm_tail_call(false). Users are otherwise encouraged to upgrade to patched versions.

References

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "21.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0"
            },
            {
              "fixed": "22.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "24.0.0"
            },
            {
              "fixed": "24.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-09T19:14:03Z",
    "nvd_published_at": "2024-10-09T18:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWasmtime\u0027s implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later.\n\n[WebAssembly tail calls](https://github.com/webassembly/tail-call) are a proposal which relatively recently reached stage 4 in the [standardization process](https://github.com/WebAssembly/proposals/). Wasmtime first enabled support for tail calls by default [in Wasmtime 21.0.0](https://github.com/bytecodealliance/wasmtime/pull/8540), although that release contained a bug where it was only on-by-default for some configurations. In [Wasmtime 22.0.0](https://github.com/bytecodealliance/wasmtime/pull/8682) tail calls were enabled by default for all configurations.\n\nThe specific crash happens when an exported function in a WebAssembly module (or component) performs a `return_call` (or `return_call_indirect` or `return_call_ref`) to an imported host function which captures a stack trace (for example, the host function raises a trap). In this situation, the stack-walking code previously assumed there was always at least one WebAssembly frame on the stack but with tail calls that is no longer true. With the tail-call proposal it\u0027s possible to have an entry trampoline appear as if it directly called the exit trampoline. This situation triggers an internal assert in the stack-walking code which raises a Rust `panic!()`.\n\nWhen Wasmtime is compiled with Rust versions 1.80 and prior this means that an `extern \"C\"` function in Rust is raising a `panic!()`. This is technically undefined behavior and typically manifests as a process abort when the unwinder fails to unwind Cranelift-generated frames. When Wasmtime is compiled with Rust versions 1.81 and later this panic becomes a deterministic process abort.\n\nOverall the impact of this issue is that this is a denial-of-service vector where a malicious WebAssembly module or component can cause the host to crash. There is no other impact at this time other than availability of a service as the result of the crash is always a crash and no more.\n\nThis issue was discovered by routine fuzzing performed by the Wasmtime project via Google\u0027s OSS-Fuzz infrastructure. We have no evidence that it has ever been exploited by an attacker in the wild.\n\n### Patches\n\nAll versions of Wasmtime which have tail calls enabled by default have been patched:\n\n* 21.0.x - patched in 21.0.2\n* 22.0.x - patched in 22.0.1\n* 23.0.x - patched in 23.0.3 \n* 24.0.x - patched in 24.0.1\n* 25.0.x - patched in 25.0.2\n\nWasmtime versions from 12.0.x (the first release with experimental tail call support) to 20.0.x (the last release with tail-calls off-by-default) have support for tail calls but the support is disabled by default. These versions are not affected in their default configurations, but users who explicitly enabled tail call support will need to either disable tail call support or upgrade to a patched version of Wasmtime.\n\n### Workarounds\n\nThe main workaround for this issue is to disable tail support for tail calls in Wasmtime, for example with [`Config::wasm_tail_call(false)`](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_tail_call). Users are otherwise encouraged to upgrade to patched versions.\n\n### References\n\n* [Wasmtime\u0027s initial implementation of tail calls](https://github.com/bytecodealliance/wasmtime/pull/6774)\n* [Enabling of tail calls in 21.0.0](https://github.com/bytecodealliance/wasmtime/pull/8540)\n* [Fully enabling tail calls in 22.0.0](https://github.com/bytecodealliance/wasmtime/pull/8682)\n* [The WebAssembly\u0027s `tail-call` proposal](https://github.com/webassembly/tail-call)",
  "id": "GHSA-q8hx-mm92-4wvg",
  "modified": "2026-06-08T20:00:05Z",
  "published": "2024-10-09T19:14:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q8hx-mm92-4wvg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47763"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/6774"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/8540"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/pull/8682"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/commit/0ebe54d05f0e1f6c64b7c8bb48c9e9f6c95cacba"
    },
    {
      "type": "WEB",
      "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_tail_call"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WebAssembly/proposals"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/wasmtime-bin/PYSEC-2024-312.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webassembly/tail-call"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0440.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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "wasmtime has a runtime crash when combining tail calls with trapping imports"
}

GHSA-Q8JQ-R84F-F54X

Vulnerability from github – Published: 2022-01-21 00:00 – Updated: 2022-01-27 00:02
VLAI
Details

There is an Assertion 'opts & PARSER_CLASS_LITERAL_CTOR_PRESENT' failed at /parser/js/js-parser-expr.c(parser_parse_class_body) in JerryScript 3.0.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-46336"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-20T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "There is an Assertion \u0027opts \u0026 PARSER_CLASS_LITERAL_CTOR_PRESENT\u0027 failed at /parser/js/js-parser-expr.c(parser_parse_class_body) in JerryScript 3.0.0.",
  "id": "GHSA-q8jq-r84f-f54x",
  "modified": "2022-01-27T00:02:36Z",
  "published": "2022-01-21T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46336"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jerryscript-project/jerryscript/issues/4927"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-Q97V-2CP6-JV6P

Vulnerability from github – Published: 2024-11-04 12:32 – Updated: 2024-11-04 12:32
VLAI
Details

Transient DOS as modem reset occurs when an unexpected MAC RAR (with invalid PDU length) is seen at UE.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-23385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-04T10:15:04Z",
    "severity": "HIGH"
  },
  "details": "Transient DOS as modem reset occurs when an unexpected MAC RAR (with invalid PDU length) is seen at UE.",
  "id": "GHSA-q97v-2cp6-jv6p",
  "modified": "2024-11-04T12:32:56Z",
  "published": "2024-11-04T12:32:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23385"
    },
    {
      "type": "WEB",
      "url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/november-2024-bulletin.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QC53-44CJ-VFVX

Vulnerability from github – Published: 2020-09-25 18:28 – Updated: 2024-10-28 20:24
VLAI
Summary
Denial of Service in Tensorflow
Details

Impact

The SparseCountSparseOutput implementation does not validate that the input arguments form a valid sparse tensor. In particular, there is no validation that the indices tensor has rank 2. This tensor must be a matrix because code assumes its elements are accessed as elements of a matrix: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/count_ops.cc#L185

However, malicious users can pass in tensors of different rank, resulting in a CHECK assertion failure and a crash. This can be used to cause denial of service in serving installations, if users are allowed to control the components of the input sparse tensor.

Patches

We have patched the issue in 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and will release a patch release.

We recommend users to upgrade to TensorFlow 2.3.1.

For more information

Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution

This vulnerability is a variant of GHSA-p5f8-gfw5-33w4

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-617"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-09-25T17:18:05Z",
    "nvd_published_at": "2020-09-25T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe `SparseCountSparseOutput` implementation does not validate that the input arguments form a valid sparse tensor. In particular, there is no validation that the `indices` tensor has rank 2. This tensor must be a matrix because code assumes its elements are accessed as elements of a matrix:\nhttps://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/count_ops.cc#L185\n\nHowever, malicious users can pass in tensors of different rank, resulting in a `CHECK` assertion failure and a crash. This can be used to cause denial of service in serving installations, if users are allowed to control the components of the input sparse tensor.\n\n### Patches\nWe have patched the issue in 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and will release a patch release.\n\nWe recommend users to upgrade to TensorFlow 2.3.1.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution\nThis vulnerability is a variant of [GHSA-p5f8-gfw5-33w4](https://github.com/tensorflow/tensorflow/security/advisories/GHSA-p5f8-gfw5-33w4)",
  "id": "GHSA-qc53-44cj-vfvx",
  "modified": "2024-10-28T20:24:30Z",
  "published": "2020-09-25T18:28:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-qc53-44cj-vfvx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15197"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/3cbb917b4714766030b28eba9fb41bb97ce9ee02"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2020-277.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2020-312.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2020-120.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tensorflow/tensorflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Denial of Service in Tensorflow"
}

GHSA-QCJC-QMXQ-WF6X

Vulnerability from github – Published: 2025-01-22 15:32 – Updated: 2025-02-07 03:32
VLAI
Details

Open5GS MME versions <= 2.6.4 contain an assertion that can be remotely triggered via a malformed ASN.1 packet over the S1AP interface. An attacker may send an S1Setup Request message missing a required Global eNB ID field to repeatedly crash the MME, resulting in denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-37017"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-22T15:15:11Z",
    "severity": "HIGH"
  },
  "details": "Open5GS MME versions \u003c= 2.6.4 contain an assertion that can be remotely triggered via a malformed ASN.1 packet over the S1AP interface. An attacker may send an `S1Setup Request` message missing a required `Global eNB ID` field to repeatedly crash the MME, resulting in denial of service.",
  "id": "GHSA-qcjc-qmxq-wf6x",
  "modified": "2025-02-07T03:32:00Z",
  "published": "2025-01-22T15:32:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37017"
    },
    {
      "type": "WEB",
      "url": "https://cellularsecurity.org/ransacked"
    }
  ],
  "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"
    }
  ]
}

GHSA-QF95-V28G-MJGX

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

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

Show details on source website

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

GHSA-QG39-5Q45-4GCC

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

A user with access to the cluster with a limited set of privilege actions can trigger a crash of a mongod process during the limited and unpredictable window when the cluster is being promoted from a replica set to a sharded cluster. This may cause a denial of service by taking down the primary of the replica set.

This issue affects MongoDB Server v8.2 versions prior to 8.2.2, MongoDB Server v8.0 versions between 8.0.18, MongoDB Server v7.0 versions between 7.0.31.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5170"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-30T16:16:10Z",
    "severity": "MODERATE"
  },
  "details": "A user with access to the cluster with a limited set of privilege actions can trigger a crash of a\u00a0mongod process during the limited and unpredictable window when the cluster is being promoted from a replica set to a sharded cluster. This may cause a denial of service by taking down the primary of the replica set.\n\nThis issue affects MongoDB Server v8.2 versions prior to 8.2.2, MongoDB Server v8.0 versions between 8.0.18, MongoDB Server v7.0 versions between 7.0.31.",
  "id": "GHSA-qg39-5q45-4gcc",
  "modified": "2026-03-30T18:31:17Z",
  "published": "2026-03-30T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5170"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-101758"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/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-QGFX-VV83-VJ4G

Vulnerability from github – Published: 2025-09-23 15:31 – Updated: 2025-09-23 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ext4: don't BUG if someone dirty pages without asking ext4 first

[un]pin_user_pages_remote is dirtying pages without properly warning the file system in advance. A related race was noted by Jan Kara in 2018[1]; however, more recently instead of it being a very hard-to-hit race, it could be reliably triggered by process_vm_writev(2) which was discovered by Syzbot[2].

This is technically a bug in mm/gup.c, but arguably ext4 is fragile in that if some other kernel subsystem dirty pages without properly notifying the file system using page_mkwrite(), ext4 will BUG, while other file systems will not BUG (although data will still be lost).

So instead of crashing with a BUG, issue a warning (since there may be potential data loss) and just mark the page as clean to avoid unprivileged denial of service attacks until the problem can be properly fixed. More discussion and background can be found in the thread starting at [2].

[1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49171"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:54Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: don\u0027t BUG if someone dirty pages without asking ext4 first\n\n[un]pin_user_pages_remote is dirtying pages without properly warning\nthe file system in advance.  A related race was noted by Jan Kara in\n2018[1]; however, more recently instead of it being a very hard-to-hit\nrace, it could be reliably triggered by process_vm_writev(2) which was\ndiscovered by Syzbot[2].\n\nThis is technically a bug in mm/gup.c, but arguably ext4 is fragile in\nthat if some other kernel subsystem dirty pages without properly\nnotifying the file system using page_mkwrite(), ext4 will BUG, while\nother file systems will not BUG (although data will still be lost).\n\nSo instead of crashing with a BUG, issue a warning (since there may be\npotential data loss) and just mark the page as clean to avoid\nunprivileged denial of service attacks until the problem can be\nproperly fixed.  More discussion and background can be found in the\nthread starting at [2].\n\n[1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz\n[2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com",
  "id": "GHSA-qgfx-vv83-vj4g",
  "modified": "2025-09-23T15:31:08Z",
  "published": "2025-09-23T15:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49171"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0d3a6926f7e8be3c897fa46216ce13b119a9f56a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/330d0e44fc5a47c27df958ecdd4693a3cb1d8b81"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/343117559ef41e992e326f7a92da1a8f254dfa8c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5a016c053f426a73752c3b41b60b497b58694d48"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5db60e76edf5680ff1f3a7221036fc44b308f146"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/677c9d30e8487bee6c8e3b034070319d98f6e203"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a0856764dc1276ad2dc7891288c2e9246bf11a37"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cc5095747edfb054ca2068d01af20be3fcc3634f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d666dfaa571465a19f014534a214c255ea33f301"
    }
  ],
  "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-QGVM-PX6J-QX93

Vulnerability from github – Published: 2023-03-10 21:30 – Updated: 2023-03-15 21:30
VLAI
Details

Transient DOS due to reachable assertion in modem during MIB reception and SIB timeout

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-33244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-10T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Transient DOS due to reachable assertion in modem during MIB reception and SIB timeout",
  "id": "GHSA-qgvm-px6j-qx93",
  "modified": "2023-03-15T21:30:26Z",
  "published": "2023-03-10T21:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33244"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/march-2023-bulletin"
    }
  ],
  "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"
    }
  ]
}

Mitigation
Implementation

Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)

Mitigation
Implementation

Strategy: Input Validation

Perform input validation on user data.

No CAPEC attack patterns related to this CWE.