CVE-2026-5497
published 2026-06-11CVE-2026-5497: vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory (OOM) Denial of Service (DoS) attack due to unbounded frame count processing in the…
PriorityP346high7.5CVSS 3.1
AVNACLPRNUINSUCNINAH
EPSS
0.54%
41.5th percentile
vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory (OOM) Denial of Service (DoS) attack due to unbounded frame count processing in the `VideoMediaIO.load_base64()` method. When processing `video/jpeg` data URLs, the method splits the base64 data string on commas to extract individual JPEG frames without enforcing a frame count limit. An attacker can exploit this by crafting a single API request containing thousands of comma-separated base64-encoded JPEG frames in a data URL, causing the server to decode all frames into memory and crash due to excessive memory consumption. This vulnerability is reachable via the OpenAI-compatible chat completions API and does not require authentication.
Affected
32 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| linux | linux_kernel | >= 6.12.0 < 6.12.74 | 6.12.74 |
| linux | linux_kernel | >= 6.13.0 < 6.18.13 | 6.18.13 |
| rhaii | vllm-cpu-rhel9 | — | — |
| rhaii | vllm-cuda-rhel9 | — | — |
| rhaii | vllm-gaudi-rhel9 | — | — |
| rhaii | vllm-neuron-rhel9 | — | — |
| rhaii | vllm-rocm-rhel9 | — | — |
| rhaii | vllm-spyre-rhel9 | — | — |
| rhaii | vllm-tpu-rhel9 | — | — |
| rhaiis | vllm-cpu-rhel9 | — | — |
| rhaiis | vllm-cuda-rhel9 | — | — |
| rhaiis | vllm-neuron-rhel9 | — | — |
| rhaiis | vllm-rocm-rhel9 | — | — |
| rhaiis | vllm-spyre-rhel9 | — | — |
| rhaiis | vllm-tpu-rhel9 | — | — |
| rhelai3 | bootc-aws-cuda-rhel9 | — | — |
| rhelai3 | bootc-azure-cuda-rhel9 | — | — |
| rhelai3 | bootc-azure-rocm-rhel9 | — | — |
| rhelai3 | bootc-cuda-rhel9 | — | — |
| rhelai3 | bootc-gaudi-rhel9 | — | — |
| rhelai3 | bootc-gcp-cuda-rhel9 | — | — |
| rhelai3 | bootc-rocm-rhel9 | — | — |
| rhoai | odh-kserve-agent-rhel9 | — | — |
| rhoai | odh-kserve-controller-rhel9 | — | — |
| rhoai | odh-kserve-router-rhel9 | — | — |
CVSS provenance
nvdv3.17.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
nvdv3.07.5HIGHCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vendor_redhat7.5HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
VulDB
vLLM up to 0.18.x OpenAI-compatible Chat Completions API VideoMediaIO.load_base64 resource consumption (EUVD-2026-36217 / WID-SEC-2026-1897)
vuldb·2026-06-13·CVSS 7.5
CVE-2026-5497 [HIGH] vLLM up to 0.18.x OpenAI-compatible Chat Completions API VideoMediaIO.load_base64 resource consumption (EUVD-2026-36217 / WID-SEC-2026-1897)
A vulnerability, which was classified as problematic, was found in vLLM up to 0.18.x. Affected is the function VideoMediaIO.load_base64 of the component OpenAI-compatible Chat Completions API. Such manipulation leads to resource consumption.
This vulnerability is listed as CVE-2026-5497. The attack may be performed from remote. There is no available exploit.
You should upgrade the affected component.
GHSA
vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory (OOM) Denial of Service (DoS) attack due to unbounded frame count processing in the `VideoMediaIO.load_base64()` method.
ghsa_unreviewed·2026-06-11
CVE-2026-5497 [HIGH] CWE-400 vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory (OOM) Denial of Service (DoS) attack due to unbounded frame count processing in the `VideoMediaIO.load_base64()` method.
vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory (OOM) Denial of Service (DoS) attack due to unbounded frame count processing in the `VideoMediaIO.load_base64()` method. When processing `video/jpeg` data URLs, the method splits the base64 data string on commas to extract individual JPEG frames without enforcing a frame count limit. An attacker can exploit this by crafting a single API request containing thousands of comma-separated base64-encoded JPEG frames in a data URL, causing the server to decode all frames into memory and crash due to excessive memory consumption. This vulnerability is reachable via the OpenAI-compatible chat completions API and does not require authentication.
OSV
tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
osv·2026-03-25
CVE-2026-23390 tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
In the Linux kernel, the following vulnerability has been resolved:
tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
The dma_map_sg tracepoint can trigger a perf buffer overflow when
tracing large scatter-gather lists. With devices like virtio-gpu
creating large DRM buffers, nents can exceed 1000 entries, resulting
in:
phys_addrs: 1000 * 8 bytes = 8,000 bytes
dma_addrs: 1000 * 8 bytes = 8,000 bytes
lengths: 1000 * 4 bytes = 4,000 bytes
Total: ~20,000 bytes
This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:
WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405
perf buffer not large enough, wanted 24620, have 8192
Cap all three dynamic arrays at 128 entries using min() in t
Red Hat
vllm: vLLM: Denial of Service via unbounded video frame processing
vendor_redhat·2026-06-11·CVSS 7.5
CVE-2026-5497 [HIGH] CWE-770 vllm: vLLM: Denial of Service via unbounded video frame processing
vllm: vLLM: Denial of Service via unbounded video frame processing
vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory (OOM) Denial of Service (DoS) attack due to unbounded frame count processing in the `VideoMediaIO.load_base64()` method. When processing `video/jpeg` data URLs, the method splits the base64 data string on commas to extract individual JPEG frames without enforcing a frame count limit. An attacker can exploit this by crafting a single API request containing thousands of comma-separated base64-encoded JPEG frames in a data URL, causing the server to decode all frames into memory and crash due to excessive memory consumption. This vulnerability is reachable via the OpenAI-compatible chat completions API and does not require authentication.
A flaw was found in vL
Red Hat
kernel: tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
vendor_redhat·2026-03-25
CVE-2026-23390 CWE-131 kernel: tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
kernel: tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
In the Linux kernel, the following vulnerability has been resolved:
tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
The dma_map_sg tracepoint can trigger a perf buffer overflow when
tracing large scatter-gather lists. With devices like virtio-gpu
creating large DRM buffers, nents can exceed 1000 entries, resulting
in:
phys_addrs: 1000 * 8 bytes = 8,000 bytes
dma_addrs: 1000 * 8 bytes = 8,000 bytes
lengths: 1000 * 4 bytes = 4,000 bytes
Total: ~20,000 bytes
This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:
WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405
perf buffer not large enough, wanted 24620, have 8192
Cap all three dynamic arrays at 128 entries using min() in
No detection rules found.
No public exploits indexed.
https://github.com/vllm-project/vllm/commit/58ee61422169ce17e08248f8efa1e9df434fe395https://huntr.com/bounties/7bd92629-b396-4449-8f88-6c0092530eb4https://access.redhat.com/security/cve/CVE-2026-5497https://bugzilla.redhat.com/show_bug.cgi?id=2487813https://huntr.com/bounties/7bd92629-b396-4449-8f88-6c0092530eb4https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-5497.json
2026-06-11
Published