Apa yang dikatakan penasehat itu
Proyek vLLM mengungkapkan CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv sebagai rantai kerentanan pemrosesan video yang penting. Saran yang ditinjau mengatakan penerapan yang terpengaruh dapat mencapai eksekusi kode jarak jauh ketika melayani model berkemampuan video dan memproses masukan video yang dikendalikan penyerang. Penerapan yang tidak menayangkan model video tidak terpengaruh oleh saran ini. [S1] [S2]
Rilis yang terpengaruh
Rilis PyPI yang terpengaruh dimulai pada vLLM 0.8.3 dan berhenti sebelum 0.14.1. PyPA dan OSV menghitung rilis terbitan yang terpengaruh, termasuk rilis pasca dan empat komponen seperti 0.8.5.post1, 0.9.0.1, dan 0.10.1.1. vLLM 0.14.1 adalah rilis tetap pertama. [S2] [S3] [S4] [S5]
Mengapa konteks penerapan penting
Ketergantungan yang rentan merupakan bukti penting dari patch-triage, namun hal ini tidak sama dengan layanan langsung yang rentan. Paparan praktis bergantung pada versi paket yang diterapkan, apakah runtime tersebut menyajikan model berkemampuan video, apakah pengguna yang tidak tepercaya dapat menyediakan masukan video, dan apakah jalur pemrosesan yang relevan dapat dijangkau. [S1]
Bagaimana FixVibe mencakupnya
Dicakup oleh FixVibe. Pemindaian repo GitHub dapat melaporkan bukti ketergantungan vLLM yang terpengaruh dari manifes Python yang didukung dan file kunci di repositori resmi. Temuan ini mengidentifikasi sumber ketergantungan, versi atau rentang yang diizinkan, versi tetap, keyakinan, dan postur bukti saran berbasis versi.
FixVibe tidak menjalankan vLLM, memulai server model, memeriksa kemampuan model yang dimuat, mengirimkan atau mengambil video, menjalankan rute inferensi, uji kerusakan dekoder, membuktikan kerusakan memori, atau mengklaim eksekusi kode jarak jauh dari bukti repositori. Pemeriksaan ini sengaja dibatasi pada analisis ketergantungan yang aman.
Remediasi
Tingkatkan vLLM ke 0.14.1 atau lebih baru di sumber ketergantungan yang mengontrol penerapan. Buat ulang file kunci aktif dan bangun kembali setiap server inferensi, pekerja, notebook, image CI, kontainer penyajian model, lingkungan virtual, cache roda, dan cache paket yang menginstalnya. Verifikasi versi di artefak yang sedang berjalan, tidak hanya di kontrol sumber. [S3] [S5]
Tinjau apakah runtime yang diterapkan melayani model berkemampuan video atau menerima input video. Hingga build tetap diterapkan, nonaktifkan atau isolasi pemrosesan video yang tidak tepercaya dan batasi akses penyajian model. Gunakan pemeriksaan pohon ketergantungan, pemeriksaan versi runtime, tinjauan kemampuan model, dan uji asap inferensi yang baik; jangan menggunakan media buatan atau upaya eksploitasi sebagai verifikasi. Saran hulu dan perbaikan terkait memberikan konteks remediasi yang otoritatif. [S1] [S6] [S7] [S8]