Cosa dice l'avviso
Il progetto vLLM ha rivelato CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv come una catena di vulnerabilità critica dell'elaborazione video. L'avviso esaminato afferma che una distribuzione interessata può raggiungere l'esecuzione di codice in modalità remota quando serve un modello con funzionalità video ed elabora l'input video controllato dall'aggressore. Le distribuzioni che non supportano un modello video non sono interessate da questo advisory. [S1] [S2]
Versioni interessate
Le versioni PyPI interessate iniziano con vLLM 0.8.3 e terminano prima della 0.14.1. PyPA e OSV enumerano le versioni pubblicate interessate, incluse le versioni post e a quattro componenti come 0.8.5.post1, 0.9.0.1 e 0.10.1.1. vLLM 0.14.1 è la prima versione fissa. [S2] [S3] [S4] [S5]
Perché il contesto di distribuzione è importante
Una dipendenza vulnerabile è un'importante prova di patch triage, ma non è la stessa cosa di un servizio live vulnerabile. L'esposizione pratica dipende dalla versione del pacchetto distribuito, dal fatto che il runtime serva un modello con funzionalità video, se gli utenti non attendibili possano fornire input video e se il percorso di elaborazione pertinente sia raggiungibile. [S1]
Come lo copre FixVibe
Coperto da FixVibe. Le scansioni del repository GitHub possono segnalare prove di dipendenza vLLM interessate da manifest Python supportati e file di lock in un repository autorizzato. Il risultato identifica l'origine della dipendenza, la versione o l'intervallo consentito, la versione fissa, la confidenza e una posizione di evidenza consultiva basata sulla versione.
FixVibe non esegue vLLM, avvia un server modello, ispeziona le funzionalità del modello caricato, invia o recupera video, esercita percorsi di inferenza, esegue crash test dei decodificatori, dimostra il danneggiamento della memoria o rivendica l'esecuzione di codice remoto dalle prove del repository. Il controllo è intenzionalmente limitato all'analisi sicura delle dipendenze.
Bonifica
Aggiorna vLLM alla versione 0.14.1 o successiva nell'origine delle dipendenze che controlla la distribuzione. Rigenera i file di blocco attivi e ricostruisci ogni server di inferenza, lavoratore, notebook, immagine CI, contenitore di servizio modelli, ambiente virtuale, wheel cache e cache di pacchetto che lo installa. Verificare la versione nell'artefatto in esecuzione, non solo nel controllo del codice sorgente. [S3] [S5]
Verifica se i runtime distribuiti servono modelli con funzionalità video o accettano input video. Fino alla distribuzione della build corretta, disabilita o isola l'elaborazione video non attendibile e limita l'accesso al servizio di modelli. Utilizzare controlli dell'albero delle dipendenze, controlli della versione runtime, revisione della capacità del modello e test del fumo di inferenza benigni; non utilizzare media artigianali o tentativi di sfruttamento come verifica. L'avviso upstream e le correzioni collegate forniscono il contesto di riparazione autorevole. [S1] [S6] [S7] [S8]