# vLLM Video JPEG2000 Decoder RCE Attempt - **Severity:** High - **Signature ID:** `7f3c1d2e-9b64-4a17-b0d5-6c8e2f4a91d3` - **OWASP:** LLM03 (Supply Chain) ## Summary An attacker sends a crafted JPEG2000-family video file to a vLLM server's chat or inference endpoint. The file exploits a bug in the bundled FFmpeg decoder used for video understanding, corrupting memory in a way that triggers a system() call and runs attacker commands on the server. ## How the attack works The attacker submits an HTTP request to a vLLM multimodal endpoint (chat completions or invocations) referencing a video URL. That video is either a JPEG2000-family file (.mj2, .jp2, .j2k, etc.) or contains the specific Motion JPEG2000 box structure the exploit needs, often fetched from a bare IP address or over plain HTTP on an unusual port rather than a normal hosted video. When vLLM's server hands this file to OpenCV's bundled FFmpeg 5.1 decoder, a crafted 'cdef' channel-definition box causes a heap buffer overflow that corrupts a function pointer used during cleanup, redirecting execution into a system() call. If exploitation succeeds, the resulting shell command often opens a reverse shell back to the attacker, visible as a /bin/sh -c process spawning netcat, a /dev/tcp redirect, or a scripting-language socket one-liner. ## Why it matters A successful attack gives the attacker arbitrary command execution on the machine running vLLM, from a single crafted video submitted through normal-looking inference traffic — potentially exposing model weights, internal networks, or other services reachable from that host. ## What you can do - Restrict which media hosts and URL schemes your vLLM deployment is allowed to fetch video from; block IP-literal URLs and cleartext HTTP on non-standard ports unless explicitly required. - Patch or replace the FFmpeg/OpenCV build vLLM uses for video decoding, or disable JPEG2000/Motion JPEG2000 decoding paths if they are not needed. - Treat any /bin/sh -c process spawned by the vLLM server process, especially one containing reverse-shell patterns (/dev/tcp, nc -e, mkfifo, python/perl socket calls), as a high-priority incident. - If you legitimately serve Motion JPEG2000 media to a VLM (e.g. medical imaging, satellite, cinema pipelines), scope monitoring by known internal source rather than disabling detection of the file type entirely. ## Known benign look-alikes - Digital-cinema, geospatial, satellite or medical-imaging pipelines that legitimately serve Motion JPEG2000 (.mj2/.jp2/.j2k) assets to a vision-language model. These are rare but real - treat a repeated, same-source .mj2 stream from a known internal pipeline as expected traffic and tune by media source, not by widening the rule. - Internal media servers addressed as http://:/clip.mp4 feeding legitimate multimodal inference. Only the IP-literal / cleartext-non-standard-port shape matches; named-host https media never fires. - Security regression tests or PoC replays against a patched vLLM build (the exploit body still matches, by design). - OpenAPI/JSON-schema documents or templated request fixtures containing sample video_url values - suppressed by filter_schema_doc and filter_templated_url. - Operators or CI jobs running a deliberate `sh -c` netcat/mkfifo one-liner for network debugging on the same host (post-exploitation branch only). ## References - https://attack.mitre.org/techniques/T1190/ - https://attack.mitre.org/techniques/T1059/004/ - https://github.com/vllm-project/vllm/security --- Source: https://www.netzilo.com/threats/vllm-video-jpeg2000-rce