CVE-2026-90555: DoS-уязвимость в vLLM через аудиозаголовки
В vLLM до версии 0.28.0 обнаружена уязвимость высокого уровня опасности (CVSS 7.1), позволяющая аутентифицированному клиенту вызвать отказ в обслуживании API-сервера. Атака выполняется через подделку заголовков аудиофайла в эндпоинте транскрипции и приводит к падению процесса, затрагивая всех арендаторов инстанса.
Подробности
Уязвимы все версии vLLM (продукт vllm-project vLLM) до 0.28.0 включительно. Причина — отсутствие проверки заголовков частоты дискретизации (sample rate) в аудиофайлах, поступающих на эндпоинт транскрипции. Логика сервиса опирается на эти заголовки при оценке длительности аудио и, соответственно, при выделении ресурсов под обработку. Аутентифицированный клиент может отправить специально сформированный FLAC-файл с завышенным значением sample rate в заголовке. Длительность записи при этом остаётся небольшой, поэтому проверки продолжительности не срабатывают, однако вычисленное значение длительности оказывается искусственно раздутым. Это провоцирует чрезмерное выделение памяти при обработке запроса, что в итоге приводит к аварийному завершению процесса API-сервера. Ключевая особенность уязвимости — её влияние на многопользовательские развёртывания: падение процесса API затрагивает всех арендаторов (tenants), использующих данный инстанс, а не только инициатора атаки. Для эксплуатации требуется наличие учётной записи, то есть речь идёт о сценарии «аутентифицированный злоумышленник», что несколько снижает вектор, но не отменяет последствий — отказ в обслуживании носит общесистемный характер.Что делать
Основная рекомендация — обновить vLLM до версии 0.28.0 или более поздней, где валидация заголовков частоты дискретизации реализована корректно. Это единственный надёжный способ закрыть уязвимость. Если немедленное обновление невозможно, стоит рассмотреть временные меры: - ограничить доступ к эндпоинту транскрипции доверенными клиентами и, по возможности, отключить его, если функциональность не используется; - настроить лимиты памяти для процессов API (cgroups, лимиты контейнера), чтобы аварийное выделение ресурсов не приводило к падению всего сервиса; - добавить внешнюю валидацию аудиофайлов на уровне прокси или шлюза, отсекая документы с аномальными значениями sample rate; - вести мониторинг потребления памяти и аварийных перезапусков процесса для раннего обнаружения попыток эксплуатации. Важно понимать, что перечисленные митигации снижают риск, но не устраняют корневую причину — отсутствие проверки на стороне приложения. Полноценным решением остаётся обновление.Итог
CVE-2026-90555 — типичный пример уязвимости, возникающей из-за доверия к метаданным входного файла. Один недооценённый заголовок FLAC превращается в вектор отказа в обслуживания, причём с последствиями для всех пользователей инстанса. Командам, эксплуатирующим vLLM в мультитенантном режиме, следует приоритизировать обновление до 0.28.0 и проверить изоляцию ресурсов между арендаторами.Источник: CVE Project (cvelistV5)