What the advisory says
The vLLM project disclosed CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv as a critical video-processing vulnerability chain. The reviewed advisory says an affected deployment can reach remote code execution when it serves a video-capable model and processes attacker-controlled video input. Deployments that do not serve a video model are not affected by this advisory. [S1] [S2]
Affected releases
The affected PyPI releases begin at vLLM 0.8.3 and stop before 0.14.1. PyPA and OSV enumerate the affected published releases, including post and four-component releases such as 0.8.5.post1, 0.9.0.1, and 0.10.1.1. vLLM 0.14.1 is the first fixed release. [S2] [S3] [S4] [S5]
Why deployment context matters
A vulnerable dependency is important patch-triage evidence, but it is not the same as a vulnerable live service. Practical exposure depends on the deployed package version, whether that runtime serves a video-capable model, whether untrusted users can supply video input, and whether the relevant processing path is reachable. [S1]
How FixVibe covers it
Covered by FixVibe. GitHub repo scans can report affected vLLM dependency evidence from supported Python manifests and lockfiles in an authorized repository. The finding identifies the dependency source, version or allowed range, fixed version, confidence, and a version-based advisory evidence posture.
FixVibe does not run vLLM, start a model server, inspect loaded model capabilities, submit or fetch video, exercise inference routes, crash-test decoders, prove memory corruption, or claim remote code execution from repository evidence. The check is intentionally limited to safe dependency analysis.
Remediation
Upgrade vLLM to 0.14.1 or newer in the dependency source that controls deployment. Regenerate active lockfiles and rebuild every inference server, worker, notebook, CI image, model-serving container, virtual environment, wheel cache, and package cache that installs it. Verify the version in the running artifact, not only in source control. [S3] [S5]
Review whether deployed runtimes serve video-capable models or accept video input. Until the fixed build is deployed, disable or isolate untrusted video processing and restrict model-serving access. Use dependency-tree checks, runtime-version checks, model-capability review, and benign inference smoke tests; do not use crafted media or exploitation attempts as verification. The upstream advisory and linked fixes provide the authoritative remediation context. [S1] [S6] [S7] [S8]