Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

6312 vulnerabilities reference this CWE, most recent first.

GHSA-8PVX-W36X-67CM

Vulnerability from github – Published: 2022-05-13 01:16 – Updated: 2022-05-13 01:16
VLAI
Details

An issue was discovered in Qt before 5.11.3. There is QTgaFile Uncontrolled Resource Consumption.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-19871"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-26T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Qt before 5.11.3. There is QTgaFile Uncontrolled Resource Consumption.",
  "id": "GHSA-8pvx-w36x-67cm",
  "modified": "2022-05-13T01:16:05Z",
  "published": "2022-05-13T01:16:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19871"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2135"
    },
    {
      "type": "WEB",
      "url": "https://blog.qt.io/blog/2018/12/04/qt-5-11-3-released-important-security-updates"
    },
    {
      "type": "WEB",
      "url": "https://codereview.qt-project.org/#/c/237761"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8PW2-6JV3-MJ5J

Vulnerability from github – Published: 2026-09-17 17:17 – Updated: 2026-09-17 17:17
VLAI
Summary
vLLM: Request-selected PyNvVideoCodec GPU decode bypasses static VRAM reservation
Details

Summary

Current vLLM main lets an inference request choose the PyNvVideoCodec GPU video decoder through media_io_kwargs.video.video_backend, but engine GPU memory reservation is computed only from static startup configuration and VLLM_VIDEO_LOADER_BACKEND. If the server starts with the default OpenCV/software backend and no --mm-ipc-gpu-memory-gb budget, a client can still route a video request into the PyNvVideoCodec path after startup, causing frontend CUDA-context, decoder-surface, and decoded-frame GPU allocations that were not carved out of the engine KV-cache budget.

Technical Details

The vulnerable boundary is the split between request-time media decoding choices in the API server and startup-time memory budgeting in the engine worker. Request bodies for Chat Completions and Responses expose media_io_kwargs, and those values are forwarded to the shared media connector. For video inputs, MediaConnector.fetch_video() copies self.media_io_kwargs["video"] into video_io_kwargs, only setting a model-derived backend when video_backend is absent. VideoMediaIO.__init__() then consumes video_backend from those kwargs and loads that backend from VIDEO_LOADER_REGISTRY.

The relevant request-side source path is:

video_io_kwargs = dict(self.media_io_kwargs.get("video", {}))
if "video_backend" not in video_io_kwargs and (
    video_backend := get_video_loader_backend_for_processor(video_processor)
):
    video_io_kwargs["video_backend"] = video_backend
video_io = VideoMediaIO(image_io, **video_io_kwargs)

video_loader_backend = (
    kwargs.pop("video_backend", None) or envs.VLLM_VIDEO_LOADER_BACKEND
)
self.video_loader = VIDEO_LOADER_REGISTRY.load(video_loader_backend)

VideoBackend.load_bytes() then dispatches backend == "pynvvideocodec" into decode_frames_pynvvideocodec(), which constructs a PyNvVideoCodec decoder, creates or uses a CUDA stream, reads stream metadata, decodes selected frames on the GPU, and copies those frames into pinned host memory. The new frontend GPU memory pool accounts only for raw decoded frame bytes when a pool exists; it does not make request-time backend selection safe when no startup reservation was made.

The engine-side reservation code makes its decision from static model config and environment only:

def _uses_pynvvideocodec_video_backend(mm_config) -> bool:
    video_kwargs = mm_config.media_io_kwargs.get("video", {})
    video_loader_backend = (
        video_kwargs.get("video_backend") or envs.VLLM_VIDEO_LOADER_BACKEND
    )
    codec_backend = video_kwargs.get("backend")
    return (
        video_loader_backend == PYNVVIDEOCODEC_VIDEO_BACKEND
        or codec_backend == PYNVVIDEOCODEC_VIDEO_BACKEND
    )

decoder_reserved_bytes = (
    num_api_servers * per_server_decoder_bytes
    if self._uses_pynvvideocodec_video_backend(mm_config)
    else 0
)
reserved_bytes = raw_frame_reserved_bytes + decoder_reserved_bytes
if reserved_bytes <= 0:
    return available_kv_cache_memory_bytes

With default static video configuration, mm_config.media_io_kwargs["video"] does not name PyNvVideoCodec and VLLM_VIDEO_LOADER_BACKEND defaults to OpenCV/software decoding. The worker therefore reserves no PyNv decoder/CUDA-context bytes. A later request can still set media_io_kwargs.video.video_backend="pynvvideocodec" and reach the GPU decoder path because that runtime field is intentionally honored by VideoMediaIO.

PoV

An ordinary multimodal inference request can carry the backend override in the request body:

{
  "model": "served-vlm",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "summarize this clip"},
        {"type": "video_url", "video_url": {"url": "data:video/mp4;base64,<small-mp4>"}}
      ]
    }
  ],
  "media_io_kwargs": {
    "video": {
      "video_backend": "pynvvideocodec"
    }
  }
}

The following bounded source-level check confirms the code path without allocating GPU memory:

git clone --filter=blob:none https://github.com/vllm-project/vllm.git
cd vllm
git checkout ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a
python3 check_pynv_backend_reservation.py --repo .

PoC

The bounded check validates current source markers, simulates the exact static reservation predicate, and compares vulnerable and negative-control configurations. Key output:

{
  "vulnerable": true,
  "head": "ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a",
  "reservation_simulation": {
    "env_video_loader_backend": "opencv",
    "request_selects_pynv_after_startup": true,
    "vulnerable_static_reserved_bytes": 0,
    "negative_control_static_pynv_reserved_bytes": 2066953011,
    "raw_frame_only_control_reserved_bytes": 268435456,
    "unreserved_decoder_bytes_when_only_request_selects_pynv": 2066953011
  }
}

The negative control is important: when PyNvVideoCodec is selected statically, the worker reserves 2066953011 bytes per API process for decoder surfaces plus CUDA context. The vulnerable case reserves 0 bytes for the same decoder overhead because PyNvVideoCodec is selected only by the later request. A second control with static OpenCV plus mm_ipc_gpu_memory_gb=0.25 reserves only the raw-frame semaphore budget and still does not reserve PyNv decoder/CUDA-context bytes.

Impact

An attacker who can submit video requests to a vLLM deployment with PyNvVideoCodec available can force frontend GPU decoding even when the engine did not reserve memory for that decoder during startup. On high-utilization serving deployments, the unreserved CUDA context, retained decoder surfaces, and decoded-frame allocations can reduce or exhaust GPU memory that the engine assumed was available for weights, activations, or KV cache, causing request failures, worker crashes, or service-level denial of service.

Suggested severity is Medium with conservative CVSS v3.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (6.5). If a deployment exposes the affected API without authentication, PR:N would raise the deployment-specific score. Suggested weaknesses are CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-400 (Uncontrolled Resource Consumption). This should not be rated Low because the affected resource is shared GPU memory in the serving path and the code already treats the PyNv decoder/CUDA-context footprint as large enough to reserve at startup when statically configured.

Limitations: exploitation requires a GPU deployment where PyNvVideoCodec is installed and usable, and the request must reach a video-capable model/path. The issue does not claim code execution, data disclosure, or SSRF.

Suggested Fix

Do not allow untrusted request fields to select a GPU decoder that was not included in startup memory reservation. The simplest fix is to reject request-level media_io_kwargs.video.video_backend="pynvvideocodec" unless the static server configuration already selected PyNvVideoCodec and reserved its decoder/CUDA-context budget.

If dynamic backend selection remains supported, split software and GPU decoder policies: allow request selection among CPU/software decoders only, require an explicit operator allowlist for GPU decoders, and include every request-selectable GPU decoder in the startup reservation predicate. Add regression coverage for static OpenCV startup config plus request-level PyNvVideoCodec override, and preserve the negative control where static PyNvVideoCodec configuration reserves decoder/CUDA-context bytes.

Affected Package/Versions

Package: vllm from vllm-project/vllm.

Confirmed affected: current main at ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a.

Introduced by: af16446bf39de047ab57649c933063cf1cbf1e50, Vram semaphore infra (#44465), committed 2026-06-26T17:32:51-07:00.

Release status checked: git tag --contains af16446bf returned no release tags in the fresh checkout. GitHub repository metadata reported latest published release v0.23.0 published 2026-06-15T05:27:20Z; the local v0.24.0 tag also does not contain the introducing commit. The affected range should therefore be current main builds containing af16446bf until fixed, rather than a confirmed released-version range.

Advisory History

Public vLLM advisories checked included audio decompression-bomb DoS, unbounded video/jpeg frame-count DoS, MediaConnector SSRF, video processing RCE, multimodal embedding DoS/RCE, GGUF GPU memory exposure, multimodal hashing, and other request-parameter DoS classes. None matched request-selected PyNvVideoCodec or the static VRAM reservation mismatch.

Prior local/private vLLM report families checked included request-level media_io_kwargs reopening video/jpeg frame fanout, GLM video metadata amplification, and audio media decode duration-limit bypass. Those reports share the request-level media kwargs boundary, but they target CPU/media decode limits or model metadata amplification. This report targets a different privileged asset and fix surface: GPU decoder selection after engine startup memory reservation.

Focused GitHub issue/PR searches for pynvvideocodec, mm_ipc_gpu_memory, video_backend media_io_kwargs, Vram semaphore infra, and frontend multimodal GPU decoding found the PyNvVideoCodec zero-copy RFC, an old do-not-review prototype, merged PR #44465, and an unrelated TorchCodec backend PR. No public issue or PR described this security boundary.

Appendix: Bounded Source-Level Check

#!/usr/bin/env python3
from __future__ import annotations

import argparse
import json
import re
import subprocess
from pathlib import Path

MIB = 1024 * 1024
GIB = 1024 * MIB

def read(repo: Path, rel: str) -> str:
    return (repo / rel).read_text(encoding="utf-8")

def const_int(source: str, name: str) -> int:
    expr = re.search(rf"^{name}\s*=\s*(.+)$", source, flags=re.MULTILINE).group(1).strip()
    if expr == "128 * MiB_bytes":
        return 128 * MIB
    if expr == "int(1.8 * 1024 * MiB_bytes)":
        return int(1.8 * 1024 * MIB)
    if expr == "1":
        return 1
    raise AssertionError(expr)

def uses_pynv_static(static_media_io_kwargs: dict[str, dict[str, str]], env_backend: str) -> bool:
    video_kwargs = static_media_io_kwargs.get("video", {})
    video_loader_backend = video_kwargs.get("video_backend") or env_backend
    codec_backend = video_kwargs.get("backend")
    return video_loader_backend == "pynvvideocodec" or codec_backend == "pynvvideocodec"

def reserve_bytes(static_media_io_kwargs, env_backend, mm_ipc_gpu_memory_gb, decoder_bytes, cuda_context_bytes, retained_decoders):
    raw_frame_reserved_bytes = int(mm_ipc_gpu_memory_gb * GIB)
    per_server_decoder_bytes = decoder_bytes * retained_decoders + cuda_context_bytes
    decoder_reserved_bytes = per_server_decoder_bytes if uses_pynv_static(static_media_io_kwargs, env_backend) else 0
    return raw_frame_reserved_bytes + decoder_reserved_bytes

parser = argparse.ArgumentParser()
parser.add_argument("--repo", required=True, type=Path)
repo = parser.parse_args().repo.resolve()

media_video = read(repo, "vllm/multimodal/media/video.py")
connector = read(repo, "vllm/multimodal/media/connector.py")
chat_protocol = read(repo, "vllm/entrypoints/openai/chat_completion/protocol.py")
responses_protocol = read(repo, "vllm/entrypoints/openai/responses/protocol.py")
gpu_worker = read(repo, "vllm/v1/worker/gpu_worker.py")
video_core = read(repo, "vllm/multimodal/video.py")

assert "media_io_kwargs: dict[str, dict[str, Any]] | None = Field(" in chat_protocol
assert "media_io_kwargs: dict[str, dict[str, Any]] | None = Field(" in responses_protocol
assert 'video_io_kwargs = dict(self.media_io_kwargs.get("video", {}))' in connector
assert 'if "video_backend" not in video_io_kwargs and (' in connector
assert 'kwargs.pop("video_backend", None) or envs.VLLM_VIDEO_LOADER_BACKEND' in media_video
assert "elif backend == PYNVVIDEOCODEC_VIDEO_BACKEND:" in video_core
assert 'video_kwargs = mm_config.media_io_kwargs.get("video", {})' in gpu_worker

decoder_bytes = const_int(video_core, "PYNVVIDEOCODEC_DECODER_GPU_MEMORY_BYTES")
retained_decoders = const_int(video_core, "PYNVVIDEOCODEC_MAX_RETAINED_DECODERS")
cuda_context_bytes = const_int(video_core, "PYNVVIDEOCODEC_CUDA_CONTEXT_BYTES")
per_server_decoder_bytes = decoder_bytes * retained_decoders + cuda_context_bytes

vulnerable_static_reserved = reserve_bytes({}, "opencv", 0.0, decoder_bytes, cuda_context_bytes, retained_decoders)
negative_control_reserved = reserve_bytes({"video": {"video_backend": "pynvvideocodec"}}, "opencv", 0.0, decoder_bytes, cuda_context_bytes, retained_decoders)
raw_frame_only_control = reserve_bytes({}, "opencv", 0.25, decoder_bytes, cuda_context_bytes, retained_decoders)

head = subprocess.check_output(["git", "-C", str(repo), "rev-parse", "HEAD"], text=True).strip()
print(json.dumps({
    "head": head,
    "vulnerable": vulnerable_static_reserved == 0 and negative_control_reserved == per_server_decoder_bytes,
    "reservation_simulation": {
        "env_video_loader_backend": "opencv",
        "request_selects_pynv_after_startup": True,
        "vulnerable_static_reserved_bytes": vulnerable_static_reserved,
        "negative_control_static_pynv_reserved_bytes": negative_control_reserved,
        "raw_frame_only_control_reserved_bytes": raw_frame_only_control,
        "unreserved_decoder_bytes_when_only_request_selects_pynv": per_server_decoder_bytes,
    },
}, indent=2, sort_keys=True))
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.28.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-69147"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T17:17:39Z",
    "nvd_published_at": "2026-09-16T18:17:11Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nCurrent vLLM `main` lets an inference request choose the PyNvVideoCodec GPU video decoder through `media_io_kwargs.video.video_backend`, but engine GPU memory reservation is computed only from static startup configuration and `VLLM_VIDEO_LOADER_BACKEND`. If the server starts with the default OpenCV/software backend and no `--mm-ipc-gpu-memory-gb` budget, a client can still route a video request into the PyNvVideoCodec path after startup, causing frontend CUDA-context, decoder-surface, and decoded-frame GPU allocations that were not carved out of the engine KV-cache budget.\n\n## Technical Details\n\nThe vulnerable boundary is the split between request-time media decoding choices in the API server and startup-time memory budgeting in the engine worker. Request bodies for Chat Completions and Responses expose `media_io_kwargs`, and those values are forwarded to the shared media connector. For video inputs, `MediaConnector.fetch_video()` copies `self.media_io_kwargs[\"video\"]` into `video_io_kwargs`, only setting a model-derived backend when `video_backend` is absent. `VideoMediaIO.__init__()` then consumes `video_backend` from those kwargs and loads that backend from `VIDEO_LOADER_REGISTRY`.\n\nThe relevant request-side source path is:\n\n```python\nvideo_io_kwargs = dict(self.media_io_kwargs.get(\"video\", {}))\nif \"video_backend\" not in video_io_kwargs and (\n    video_backend := get_video_loader_backend_for_processor(video_processor)\n):\n    video_io_kwargs[\"video_backend\"] = video_backend\nvideo_io = VideoMediaIO(image_io, **video_io_kwargs)\n```\n\n```python\nvideo_loader_backend = (\n    kwargs.pop(\"video_backend\", None) or envs.VLLM_VIDEO_LOADER_BACKEND\n)\nself.video_loader = VIDEO_LOADER_REGISTRY.load(video_loader_backend)\n```\n\n`VideoBackend.load_bytes()` then dispatches `backend == \"pynvvideocodec\"` into `decode_frames_pynvvideocodec()`, which constructs a PyNvVideoCodec decoder, creates or uses a CUDA stream, reads stream metadata, decodes selected frames on the GPU, and copies those frames into pinned host memory. The new frontend GPU memory pool accounts only for raw decoded frame bytes when a pool exists; it does not make request-time backend selection safe when no startup reservation was made.\n\nThe engine-side reservation code makes its decision from static model config and environment only:\n\n```python\ndef _uses_pynvvideocodec_video_backend(mm_config) -\u003e bool:\n    video_kwargs = mm_config.media_io_kwargs.get(\"video\", {})\n    video_loader_backend = (\n        video_kwargs.get(\"video_backend\") or envs.VLLM_VIDEO_LOADER_BACKEND\n    )\n    codec_backend = video_kwargs.get(\"backend\")\n    return (\n        video_loader_backend == PYNVVIDEOCODEC_VIDEO_BACKEND\n        or codec_backend == PYNVVIDEOCODEC_VIDEO_BACKEND\n    )\n```\n\n```python\ndecoder_reserved_bytes = (\n    num_api_servers * per_server_decoder_bytes\n    if self._uses_pynvvideocodec_video_backend(mm_config)\n    else 0\n)\nreserved_bytes = raw_frame_reserved_bytes + decoder_reserved_bytes\nif reserved_bytes \u003c= 0:\n    return available_kv_cache_memory_bytes\n```\n\nWith default static video configuration, `mm_config.media_io_kwargs[\"video\"]` does not name PyNvVideoCodec and `VLLM_VIDEO_LOADER_BACKEND` defaults to OpenCV/software decoding. The worker therefore reserves no PyNv decoder/CUDA-context bytes. A later request can still set `media_io_kwargs.video.video_backend=\"pynvvideocodec\"` and reach the GPU decoder path because that runtime field is intentionally honored by `VideoMediaIO`.\n\n## PoV\n\nAn ordinary multimodal inference request can carry the backend override in the request body:\n\n```json\n{\n  \"model\": \"served-vlm\",\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\"type\": \"text\", \"text\": \"summarize this clip\"},\n        {\"type\": \"video_url\", \"video_url\": {\"url\": \"data:video/mp4;base64,\u003csmall-mp4\u003e\"}}\n      ]\n    }\n  ],\n  \"media_io_kwargs\": {\n    \"video\": {\n      \"video_backend\": \"pynvvideocodec\"\n    }\n  }\n}\n```\n\nThe following bounded source-level check confirms the code path without allocating GPU memory:\n\n```bash\ngit clone --filter=blob:none https://github.com/vllm-project/vllm.git\ncd vllm\ngit checkout ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a\npython3 check_pynv_backend_reservation.py --repo .\n```\n\n## PoC\n\nThe bounded check validates current source markers, simulates the exact static reservation predicate, and compares vulnerable and negative-control configurations. Key output:\n\n```json\n{\n  \"vulnerable\": true,\n  \"head\": \"ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a\",\n  \"reservation_simulation\": {\n    \"env_video_loader_backend\": \"opencv\",\n    \"request_selects_pynv_after_startup\": true,\n    \"vulnerable_static_reserved_bytes\": 0,\n    \"negative_control_static_pynv_reserved_bytes\": 2066953011,\n    \"raw_frame_only_control_reserved_bytes\": 268435456,\n    \"unreserved_decoder_bytes_when_only_request_selects_pynv\": 2066953011\n  }\n}\n```\n\nThe negative control is important: when PyNvVideoCodec is selected statically, the worker reserves `2066953011` bytes per API process for decoder surfaces plus CUDA context. The vulnerable case reserves `0` bytes for the same decoder overhead because PyNvVideoCodec is selected only by the later request. A second control with static OpenCV plus `mm_ipc_gpu_memory_gb=0.25` reserves only the raw-frame semaphore budget and still does not reserve PyNv decoder/CUDA-context bytes.\n\n## Impact\n\nAn attacker who can submit video requests to a vLLM deployment with PyNvVideoCodec available can force frontend GPU decoding even when the engine did not reserve memory for that decoder during startup. On high-utilization serving deployments, the unreserved CUDA context, retained decoder surfaces, and decoded-frame allocations can reduce or exhaust GPU memory that the engine assumed was available for weights, activations, or KV cache, causing request failures, worker crashes, or service-level denial of service.\n\nSuggested severity is Medium with conservative CVSS v3.1 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H` (6.5). If a deployment exposes the affected API without authentication, `PR:N` would raise the deployment-specific score. Suggested weaknesses are `CWE-770` (Allocation of Resources Without Limits or Throttling) and `CWE-400` (Uncontrolled Resource Consumption). This should not be rated Low because the affected resource is shared GPU memory in the serving path and the code already treats the PyNv decoder/CUDA-context footprint as large enough to reserve at startup when statically configured.\n\nLimitations: exploitation requires a GPU deployment where PyNvVideoCodec is installed and usable, and the request must reach a video-capable model/path. The issue does not claim code execution, data disclosure, or SSRF.\n\n## Suggested Fix\n\nDo not allow untrusted request fields to select a GPU decoder that was not included in startup memory reservation. The simplest fix is to reject request-level `media_io_kwargs.video.video_backend=\"pynvvideocodec\"` unless the static server configuration already selected PyNvVideoCodec and reserved its decoder/CUDA-context budget.\n\nIf dynamic backend selection remains supported, split software and GPU decoder policies: allow request selection among CPU/software decoders only, require an explicit operator allowlist for GPU decoders, and include every request-selectable GPU decoder in the startup reservation predicate. Add regression coverage for static OpenCV startup config plus request-level PyNvVideoCodec override, and preserve the negative control where static PyNvVideoCodec configuration reserves decoder/CUDA-context bytes.\n\n## Affected Package/Versions\n\nPackage: `vllm` from `vllm-project/vllm`.\n\nConfirmed affected: current `main` at `ddd3855a28a561a5bb54d380c6e6b8b1e883cc4a`.\n\nIntroduced by: `af16446bf39de047ab57649c933063cf1cbf1e50`, `Vram semaphore infra (#44465)`, committed 2026-06-26T17:32:51-07:00.\n\nRelease status checked: `git tag --contains af16446bf` returned no release tags in the fresh checkout. GitHub repository metadata reported latest published release `v0.23.0` published 2026-06-15T05:27:20Z; the local `v0.24.0` tag also does not contain the introducing commit. The affected range should therefore be current `main` builds containing `af16446bf` until fixed, rather than a confirmed released-version range.\n\n## Advisory History\n\nPublic vLLM advisories checked included audio decompression-bomb DoS, unbounded `video/jpeg` frame-count DoS, MediaConnector SSRF, video processing RCE, multimodal embedding DoS/RCE, GGUF GPU memory exposure, multimodal hashing, and other request-parameter DoS classes. None matched request-selected PyNvVideoCodec or the static VRAM reservation mismatch.\n\nPrior local/private vLLM report families checked included request-level `media_io_kwargs` reopening `video/jpeg` frame fanout, GLM video metadata amplification, and audio media decode duration-limit bypass. Those reports share the request-level media kwargs boundary, but they target CPU/media decode limits or model metadata amplification. This report targets a different privileged asset and fix surface: GPU decoder selection after engine startup memory reservation.\n\nFocused GitHub issue/PR searches for `pynvvideocodec`, `mm_ipc_gpu_memory`, `video_backend media_io_kwargs`, `Vram semaphore infra`, and `frontend multimodal GPU decoding` found the PyNvVideoCodec zero-copy RFC, an old do-not-review prototype, merged PR `#44465`, and an unrelated TorchCodec backend PR. No public issue or PR described this security boundary.\n\n## Appendix: Bounded Source-Level Check\n\n```python\n#!/usr/bin/env python3\nfrom __future__ import annotations\n\nimport argparse\nimport json\nimport re\nimport subprocess\nfrom pathlib import Path\n\nMIB = 1024 * 1024\nGIB = 1024 * MIB\n\ndef read(repo: Path, rel: str) -\u003e str:\n    return (repo / rel).read_text(encoding=\"utf-8\")\n\ndef const_int(source: str, name: str) -\u003e int:\n    expr = re.search(rf\"^{name}\\s*=\\s*(.+)$\", source, flags=re.MULTILINE).group(1).strip()\n    if expr == \"128 * MiB_bytes\":\n        return 128 * MIB\n    if expr == \"int(1.8 * 1024 * MiB_bytes)\":\n        return int(1.8 * 1024 * MIB)\n    if expr == \"1\":\n        return 1\n    raise AssertionError(expr)\n\ndef uses_pynv_static(static_media_io_kwargs: dict[str, dict[str, str]], env_backend: str) -\u003e bool:\n    video_kwargs = static_media_io_kwargs.get(\"video\", {})\n    video_loader_backend = video_kwargs.get(\"video_backend\") or env_backend\n    codec_backend = video_kwargs.get(\"backend\")\n    return video_loader_backend == \"pynvvideocodec\" or codec_backend == \"pynvvideocodec\"\n\ndef reserve_bytes(static_media_io_kwargs, env_backend, mm_ipc_gpu_memory_gb, decoder_bytes, cuda_context_bytes, retained_decoders):\n    raw_frame_reserved_bytes = int(mm_ipc_gpu_memory_gb * GIB)\n    per_server_decoder_bytes = decoder_bytes * retained_decoders + cuda_context_bytes\n    decoder_reserved_bytes = per_server_decoder_bytes if uses_pynv_static(static_media_io_kwargs, env_backend) else 0\n    return raw_frame_reserved_bytes + decoder_reserved_bytes\n\nparser = argparse.ArgumentParser()\nparser.add_argument(\"--repo\", required=True, type=Path)\nrepo = parser.parse_args().repo.resolve()\n\nmedia_video = read(repo, \"vllm/multimodal/media/video.py\")\nconnector = read(repo, \"vllm/multimodal/media/connector.py\")\nchat_protocol = read(repo, \"vllm/entrypoints/openai/chat_completion/protocol.py\")\nresponses_protocol = read(repo, \"vllm/entrypoints/openai/responses/protocol.py\")\ngpu_worker = read(repo, \"vllm/v1/worker/gpu_worker.py\")\nvideo_core = read(repo, \"vllm/multimodal/video.py\")\n\nassert \"media_io_kwargs: dict[str, dict[str, Any]] | None = Field(\" in chat_protocol\nassert \"media_io_kwargs: dict[str, dict[str, Any]] | None = Field(\" in responses_protocol\nassert \u0027video_io_kwargs = dict(self.media_io_kwargs.get(\"video\", {}))\u0027 in connector\nassert \u0027if \"video_backend\" not in video_io_kwargs and (\u0027 in connector\nassert \u0027kwargs.pop(\"video_backend\", None) or envs.VLLM_VIDEO_LOADER_BACKEND\u0027 in media_video\nassert \"elif backend == PYNVVIDEOCODEC_VIDEO_BACKEND:\" in video_core\nassert \u0027video_kwargs = mm_config.media_io_kwargs.get(\"video\", {})\u0027 in gpu_worker\n\ndecoder_bytes = const_int(video_core, \"PYNVVIDEOCODEC_DECODER_GPU_MEMORY_BYTES\")\nretained_decoders = const_int(video_core, \"PYNVVIDEOCODEC_MAX_RETAINED_DECODERS\")\ncuda_context_bytes = const_int(video_core, \"PYNVVIDEOCODEC_CUDA_CONTEXT_BYTES\")\nper_server_decoder_bytes = decoder_bytes * retained_decoders + cuda_context_bytes\n\nvulnerable_static_reserved = reserve_bytes({}, \"opencv\", 0.0, decoder_bytes, cuda_context_bytes, retained_decoders)\nnegative_control_reserved = reserve_bytes({\"video\": {\"video_backend\": \"pynvvideocodec\"}}, \"opencv\", 0.0, decoder_bytes, cuda_context_bytes, retained_decoders)\nraw_frame_only_control = reserve_bytes({}, \"opencv\", 0.25, decoder_bytes, cuda_context_bytes, retained_decoders)\n\nhead = subprocess.check_output([\"git\", \"-C\", str(repo), \"rev-parse\", \"HEAD\"], text=True).strip()\nprint(json.dumps({\n    \"head\": head,\n    \"vulnerable\": vulnerable_static_reserved == 0 and negative_control_reserved == per_server_decoder_bytes,\n    \"reservation_simulation\": {\n        \"env_video_loader_backend\": \"opencv\",\n        \"request_selects_pynv_after_startup\": True,\n        \"vulnerable_static_reserved_bytes\": vulnerable_static_reserved,\n        \"negative_control_static_pynv_reserved_bytes\": negative_control_reserved,\n        \"raw_frame_only_control_reserved_bytes\": raw_frame_only_control,\n        \"unreserved_decoder_bytes_when_only_request_selects_pynv\": per_server_decoder_bytes,\n    },\n}, indent=2, sort_keys=True))\n```",
  "id": "GHSA-8pw2-6jv3-mj5j",
  "modified": "2026-09-17T17:17:40Z",
  "published": "2026-09-17T17:17:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-8pw2-6jv3-mj5j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69147"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/47259"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/283893c72292ede38d277e3cd2b9b64c3e4f1dda"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/ba22152096b2484faa3579624a253d54804d876d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/releases/tag/v0.25.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: Request-selected PyNvVideoCodec GPU decode bypasses static VRAM reservation"
}

GHSA-8Q46-8C27-MJGG

Vulnerability from github – Published: 2023-12-12 12:30 – Updated: 2023-12-14 21:31
VLAI
Details

Denial-of-service (DoS) vulnerability exists in FTP service of HMI GC-A2 series. If a remote unauthenticated attacker sends a specially crafted packets to specific ports, a denial-of-service (DoS) condition may occur.

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-2023-41963"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-12T10:15:10Z",
    "severity": "HIGH"
  },
  "details": "Denial-of-service (DoS) vulnerability exists in FTP service of HMI GC-A2 series. If a remote unauthenticated attacker sends a specially crafted packets to specific ports, a denial-of-service (DoS) condition may occur.",
  "id": "GHSA-8q46-8c27-mjgg",
  "modified": "2023-12-14T21:31:14Z",
  "published": "2023-12-12T12:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41963"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN34145838"
    },
    {
      "type": "WEB",
      "url": "https://www.electronics.jtekt.co.jp/en/topics/202312116562"
    }
  ],
  "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-8Q58-8VM2-MF3Q

Vulnerability from github – Published: 2023-11-06 09:30 – Updated: 2024-09-16 15:32
VLAI
Details

A vulnerability was found in Samba's "rpcecho" development server, a non-Windows RPC server used to test Samba's DCE/RPC stack elements. This vulnerability stems from an RPC function that can be blocked indefinitely. The issue arises because the "rpcecho" service operates with only one worker in the main RPC task, allowing calls to the "rpcecho" server to be blocked for a specified time, causing service disruptions. This disruption is triggered by a "sleep()" call in the "dcesrv_echo_TestSleep()" function under specific conditions. Authenticated users or attackers can exploit this vulnerability to make calls to the "rpcecho" server, requesting it to block for a specified duration, effectively disrupting most services and leading to a complete denial of service on the AD DC. The DoS affects all other services as "rpcecho" runs in the main RPC task.

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": [],
  "aliases": [
    "CVE-2023-42669"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-06T07:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Samba\u0027s \"rpcecho\" development server, a non-Windows RPC server used to test Samba\u0027s DCE/RPC stack elements. This vulnerability stems from an RPC function that can be blocked indefinitely. The issue arises because the \"rpcecho\" service operates with only one worker in the main RPC task, allowing calls to the \"rpcecho\" server to be blocked for a specified time, causing service disruptions. This disruption is triggered by a \"sleep()\" call in the \"dcesrv_echo_TestSleep()\" function under specific conditions. Authenticated users or attackers can exploit this vulnerability to make calls to the \"rpcecho\" server, requesting it to block for a specified duration, effectively disrupting most services and leading to a complete denial of service on the AD DC. The DoS affects all other services as \"rpcecho\" runs in the main RPC task.",
  "id": "GHSA-8q58-8vm2-mf3q",
  "modified": "2024-09-16T15:32:45Z",
  "published": "2023-11-06T09:30:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42669"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:6209"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:6744"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7371"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7408"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7464"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7467"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-42669"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2241884"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.samba.org/show_bug.cgi?id=15474"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20231124-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.samba.org/samba/security/CVE-2023-42669.html"
    }
  ],
  "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-8Q76-66PG-95C5

Vulnerability from github – Published: 2022-08-06 00:00 – Updated: 2022-08-16 00:00
VLAI
Details

A Denial-of-Service vulnerability was discovered in the F-Secure Atlant and in certain WithSecure products while scanning fuzzed PE32-bit files it is possible that can crash the scanning engine. The exploit can be triggered remotely by an attacker.

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-2022-28880"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-05T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Denial-of-Service vulnerability was discovered in the F-Secure Atlant and in certain WithSecure products while scanning fuzzed PE32-bit files it is possible that can crash the scanning engine. The exploit can be triggered remotely by an attacker.",
  "id": "GHSA-8q76-66pg-95c5",
  "modified": "2022-08-16T00:00:21Z",
  "published": "2022-08-06T00:00:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28880"
    },
    {
      "type": "WEB",
      "url": "https://www.f-secure.com/en/home/support/vulnerability-reward-program/hall-of-fame"
    },
    {
      "type": "WEB",
      "url": "https://www.withsecure.com/en/expertise/people"
    }
  ],
  "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-8Q93-326V-3M7G

Vulnerability from github – Published: 2026-05-14 16:18 – Updated: 2026-06-09 10:18
VLAI
Summary
Synapse CPU starvation (Denial of Service)
Details

Impact

Local authenticated users can cause Synapse to starve other requests of CPU and lead to other requests failing, causing other users to be denied service.

Homeservers that trust all their local users are not at risk.

Patches

Update to Synapse 1.152.1 or later.

Workarounds

If Synapse is deployed behind a reverse proxy, the reverse proxy could be configured to limit the rate of user requests, preventing or increasing the difficulty of the attack.

Identifiers

  • ELEMENTSEC-2026-1706

For more information

If you have any questions or comments about this advisory, please email us at security at element.io.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "matrix-synapse"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.152.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T16:18:40Z",
    "nvd_published_at": "2026-05-28T17:16:31Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nLocal authenticated users can cause Synapse to starve other requests of CPU and lead to other requests failing, causing other users to be denied service.\n\nHomeservers that trust all their local users are not at risk.\n\n### Patches\n\nUpdate to Synapse 1.152.1 or later.\n\n### Workarounds\n\nIf Synapse is deployed behind a reverse proxy, the reverse proxy could be configured to limit the rate of user requests,\npreventing or increasing the difficulty of the attack.\n\n### Identifiers\n\n- ELEMENTSEC-2026-1706\n\n### For more information\n\nIf you have any questions or comments about this advisory, please email us at [security at element.io](mailto:security@element.io).",
  "id": "GHSA-8q93-326v-3m7g",
  "modified": "2026-06-09T10:18:03Z",
  "published": "2026-05-14T16:18:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/element-hq/synapse/security/advisories/GHSA-8q93-326v-3m7g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45078"
    },
    {
      "type": "WEB",
      "url": "https://github.com/element-hq/synapse/issues/19394"
    },
    {
      "type": "WEB",
      "url": "https://github.com/element-hq/synapse/commit/3f58bc50dfba5768ee43ce48c5e74c25ba0b078a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/element-hq/synapse"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/matrix-synapse/PYSEC-2026-191.yaml"
    }
  ],
  "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:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Synapse CPU starvation (Denial of Service)"
}

GHSA-8QP7-8Q8F-4335

Vulnerability from github – Published: 2023-11-08 18:30 – Updated: 2024-09-04 15:30
VLAI
Details

In Helix Core versions prior to 2023.2, an unauthenticated remote Denial of Service (DoS) via the commit function was identified. Reported by Jason Geffner. 

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-2023-45319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-08T16:15:10Z",
    "severity": "HIGH"
  },
  "details": "In Helix Core versions prior to 2023.2, an unauthenticated remote Denial of Service (DoS) via the commit function was identified.  Reported by Jason Geffner.\u00a0\n",
  "id": "GHSA-8qp7-8q8f-4335",
  "modified": "2024-09-04T15:30:31Z",
  "published": "2023-11-08T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45319"
    },
    {
      "type": "WEB",
      "url": "https://perforce.com"
    }
  ],
  "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-8QV2-5VQ6-G2G7

Vulnerability from github – Published: 2023-08-25 00:12 – Updated: 2023-09-06 17:36
VLAI
Summary
webpki: CPU denial of service in certificate path building
Details

When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in https://github.com/briansmith/webpki/issues/69.

rustls-webpki is a fork of this crate which contains a fix for this issue and is actively maintained.

Severity
7.5 (High)
CVSS:3.0/AV:N/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= 0.22.1"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "webpki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-25T00:12:39Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building.\n\nBoth TLS clients and TLS servers that accept client certificate are affected.\n\nThis was previously reported in https://github.com/briansmith/webpki/issues/69.\n\n`rustls-webpki` is a fork of this crate which contains a fix for this issue and is actively maintained.",
  "id": "GHSA-8qv2-5vq6-g2g7",
  "modified": "2023-09-06T17:36:28Z",
  "published": "2023-08-25T00:12:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/briansmith/webpki/issues/69"
    },
    {
      "type": "WEB",
      "url": "https://github.com/briansmith/webpki/issues/69#issuecomment-1699894848"
    },
    {
      "type": "WEB",
      "url": "https://github.com/briansmith/webpki/commit/30a108e0802fd09585e0d071013f24b8272d139b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/briansmith/webpki"
    },
    {
      "type": "WEB",
      "url": "https://github.com/crypto-com/sgx-vendor"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0052.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "webpki: CPU denial of service in certificate path building"
}

GHSA-8QV5-PJHW-3GX4

Vulnerability from github – Published: 2026-09-16 15:31 – Updated: 2026-09-16 18:32
VLAI
Details

A flaw was found in the theme localization endpoints of the keycloak-services component, which is the core service responsible for authentication flows and theme management in Keycloak. The issue occurs because the system accepts arbitrary locale tags from unauthenticated requests and stores them in a permanent in-memory cache without limits. An attacker can exploit this by sending a large number of unique locale tags, eventually causing the server to run out of memory and crash.

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-79651"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T15:17:52Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in the theme localization endpoints of the keycloak-services component, which is the core service responsible for authentication flows and theme management in Keycloak. The issue occurs because the system accepts arbitrary locale tags from unauthenticated requests and stores them in a permanent in-memory cache without limits. An attacker can exploit this by sending a large number of unique locale tags, eventually causing the server to run out of memory and crash.",
  "id": "GHSA-8qv5-pjhw-3gx4",
  "modified": "2026-09-16T18:32:00Z",
  "published": "2026-09-16T15:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79651"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:68276"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:68277"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:68278"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:68280"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-79651"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2523345"
    }
  ],
  "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-8QWH-6R32-9V26

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

Autel EVO NANO drone flight control firmware version 1.6.5 is vulnerable to denial of service (DoS).

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-50121"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-06T05:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Autel EVO NANO drone flight control firmware version 1.6.5 is vulnerable to denial of service (DoS).",
  "id": "GHSA-8qwh-6r32-9v26",
  "modified": "2024-01-12T21:30:18Z",
  "published": "2024-01-06T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50121"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Drone-Lab/Reports-of-AUTEL-drones-losing-control-at-the-edge-of-the-no-fly-zone/tree/main"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list