CVE-2026-22778: 
NixOS vulnerability analysis and mitigation

CVE-2026-22778 is a critical Remote Code Execution (RCE) vulnerability in vLLM, an inference and serving engine for large language models, affecting versions 0.8.3 through 0.14.0. The vulnerability is a chained exploit combining an information leak (PIL error messages exposing heap memory addresses, enabling ASLR bypass) with a heap overflow in the JPEG2000 decoder bundled within OpenCV/FFmpeg. An unauthenticated attacker can trigger RCE by sending a malicious video URL to vLLM's multimodal API endpoints on deployments serving a video model. It was published on February 2, 2026, and carries a CVSS v3.1 base score of 9.8 (Critical) (GitHub Advisory, vLLM Security Advisory).

The vulnerability chain consists of two weaknesses: CWE-209/CWE-532 (information leak via PIL error messages) and CWE-122 (heap-based buffer overflow). Vuln 1 (ASLR Bypass): When an invalid image is submitted to vLLM's multimodal endpoint, PIL raises an error such as cannot identify image file <_io.BytesIO object at 0x7a95e299e750>, and vLLM returns this raw error to the client, leaking a heap address approximately 10.33 GB before libc — reducing ASLR entropy from ~4 billion guesses to ~8. Vuln 2 (Heap Overflow): vLLM accepts a video_url parameter in POST /v1/chat/completions or POST /v1/invocations, fetches the remote video bytes, and passes them to cv2.VideoCapture(). OpenCV's bundled FFmpeg 5.1.x decodes JPEG2000 frames using libopenjp2, which honors a malicious cdef box that remaps the Y (luma) channel into the smaller U (chroma) plane buffer. For a 150×64 image, this causes a 7,200-byte overflow (Y=9,600 bytes vs. U=2,400 bytes), overwriting an AVBuffer structure's free() function pointer with system() and setting opaque to an attacker-controlled command string — executing arbitrary commands when the buffer is freed (GitHub Advisory, vLLM Security Advisory).

Successful exploitation results in complete system compromise with arbitrary command execution at the privilege level of the vLLM process. All three security pillars are fully impacted: confidentiality (access to model weights, inference data, API keys, and system secrets), integrity (ability to modify files, inject malicious outputs, or alter model behavior), and availability (process crash or denial of service). Default vLLM installations from pip or Docker have no authentication on the Completions endpoint, enabling fully unauthenticated RCE; even API-key-protected deployments are vulnerable via the pre-authentication /v1/invocations route. The compromised server could serve as a pivot point for lateral movement within AI infrastructure or cloud environments (GitHub Advisory, Cybernoz).

Exploitation has been reported in the wild by multiple threat intelligence sources, including The Cyber Express and Cybernoz, though no public proof-of-concept code has been confirmed (Feedly). The vulnerability requires no authentication and no user interaction, making it trivially exploitable against default vLLM deployments. A Nuclei template for the information disclosure component was submitted to the projectdiscovery/nuclei-templates repository (PR #15358, later closed). The EPSS score is approximately 0.061% (0.102% per GitHub Advisory), placing it in the 28th percentile for near-term exploitation probability. No specific threat actor attribution has been published, and the vulnerability does not appear in the CISA KEV catalog as of the time of this report (GitHub Advisory, The Cyber Express).

1. Reconnaissance: Identify internet-facing vLLM instances (versions 0.8.3–0.14.0) serving video models using Shodan, Censys, or similar tools by searching for the vLLM OpenAI-compatible API banner on default port 8000.
2. ASLR Bypass (Info Leak): Send an HTTP POST request to POST /v1/chat/completions with an invalid image payload in the multimodal content field. The PIL error response will contain a raw Python object representation such as cannot identify image file <_io.BytesIO object at 0x7a95e299e750>, leaking a heap address.
3. Calculate libc Base: Use the leaked heap address (known to be ~10.33 GB before libc) to compute the libc base address, reducing ASLR guesses from ~4 billion to ~8.
4. Craft Malicious Video: Build a .mov container with JPEG2000-encoded frames containing a malicious cdef box. Set Asoc=2 for channel 0 (Y channel) to force Y-plane data into the smaller U-plane buffer. Use a frame geometry such as 150×64 to produce a 7,200-byte overflow. Embed the target AVBuffer.free pointer overwrite with system() and set opaque to the desired shell command, using the computed libc address.
5. Host Malicious Video: Serve the crafted .mov file from an attacker-controlled HTTP server.
6. Trigger RCE: Send a POST /v1/chat/completions or POST /v1/invocations request with a video_url content part pointing to the attacker's server. vLLM fetches the video, passes it to cv2.VideoCapture(), FFmpeg decodes the JPEG2000 frames, the heap overflow fires, and system("attacker command") executes when the AVBuffer is freed.
7. Achieve Persistence: Use the RCE to establish a reverse shell, exfiltrate credentials, or deploy a persistent backdoor on the compromised server (GitHub Advisory, vLLM Security Advisory).

• Network: Outbound HTTP requests from the vLLM server to unexpected external hosts (attacker-controlled video file servers); unusual outbound connections (reverse shells) from the vLLM process to non-standard ports; inbound POST requests to /v1/chat/completions or /v1/invocations with video_url fields pointing to external or internal IP addresses.
• Logs: vLLM API access logs showing POST requests to /v1/chat/completions or /v1/invocations with video_url content parts from unknown clients; error responses containing PIL BytesIO object memory address strings (e.g., cannot identify image file <_io.BytesIO object at 0x...>) in API response logs prior to patching.
• Process: Unexpected child processes spawned by the vLLM Python process (e.g., /bin/sh, /bin/bash, curl, wget, python3, nc); unusual process tree with cv2.VideoCapture or FFmpeg-related processes executing shell commands.
• File System: New or modified files in the vLLM working directory or /tmp; unexpected cron jobs, systemd units, or SSH authorized_keys modifications created by the vLLM service account; web shells or reverse shell scripts dropped on the server.
• Memory/Runtime: Crashes or segmentation faults in the vLLM process associated with OpenCV/FFmpeg video decoding, particularly when processing externally-supplied video URLs (GitHub Advisory, The Cyber Express).

Primary remediation: Upgrade vLLM to version 0.14.1 or later immediately, as this release contains all three fixes: sanitizing error messages to prevent memory address leaks (PR #31987, PR #32319) and bumping the opencv-python dependency to version 4.13 which addresses the JPEG2000 heap overflow (PR #32668) (GitHub Advisory, vLLM Security Advisory). Interim workarounds for organizations unable to upgrade immediately: (1) Restrict network access to vLLM API endpoints using firewall rules or network policies; (2) Enable API key authentication and block unauthenticated access to /v1/invocations; (3) Disable video model serving if not required, as deployments not serving a video model are not affected. Red Hat has also issued an errata (RHSA-2026:3462) for affected Red Hat products (Red Hat Advisory).

The vulnerability received significant coverage from AI and cybersecurity media outlets, with The Cyber Express, Cybernoz, and Security Online Info publishing detailed write-ups shortly after disclosure (The Cyber Express, Cybernoz). Orca Security and OX Security published dedicated technical blog posts analyzing the exploit chain (Orca Security, OX Security). The Hacker Wire covered the heap leak and RCE chain, and the vulnerability was shared on Mastodon, Bluesky, and LinkedIn by security researchers. CERT.at included it in their daily threat digest. The community noted the particularly dangerous default-unauthenticated posture of vLLM and the pre-auth bypass via the /v1/invocations route as especially alarming for AI infrastructure operators. A follow-up PR (#45119) was later opened to extend the sanitize_message fix to Anthropic API and speech-to-text paths that were missed in the original patch.