Тысячи открытых серверов NVIDIA и критическая уязвимость в DCGM Exporter

В современном ИТ-секторе вычислительные мощности для работы искусственного интеллекта требуют надежной защиты не только на уровне самих моделей, но и на уровне вспомогательных сервисов. В недавнем отчете специалистов по кибербезопасности из Lava подробно описываются риски, связанные с открытым доступом к телеметрии серверов. Исследователи обнаружили тысячи незащищенных узлов, раскрывающих ключевую информацию о дорогостоящем оборудовании.

Помимо утечки данных о конфигурации, специалисты выявили опасную уязвимость в официальном ПО для мониторинга от NVIDIA. Проблема получила идентификатор CVE-2026-47483 и оценку 8.2 балла по шкале CVSS. Она позволяет неавторизованным пользователям перегружать ресурсы сервера, что напрямую угрожает стабильности систем и ставит под удар общую безопасность GPU-серверов.

Результаты сканирования: масштабы открытых данных

Оригинальное исследование, проведенное Майклом Качинским (Michael Katchinskiy) из компании Lava, базируется на четырех сканированиях сети в период с марта по май 2026 года. Таким образом, опубликованные цифры отражают ситуацию, зафиксированную на этапе сбора данных, а не текущее количество открытых серверов в реальном времени.

В ходе сканирования были обнаружены хосты, которые отдавали телеметрию графических процессоров без прохождения какой-либо авторизации. В поле зрения специалистов попали как мощные ускорители для дата-центров (NVIDIA H100, H200 и Blackwell Ultra B300), так и потребительские видеокарты RTX 4090 и RTX 5090, используемые в составе рабочих станций. По предварительной оценке экспертов, совокупная рыночная стоимость обнаруженного оборудования превышает 100 миллионов долларов США. Данная сумма отражает именно рыночную цену оборудования, а не прямой финансовый ущерб от возможных кибератак.

Приблизительно четверть из обнаруженных незащищенных хостов DCGM также предоставляла открытый доступ к внутренним диагностическим интерфейсам Go profiling (pprof). Исследователи подчеркивают важность этого разделения: наличие открытого порта для сбора метрик и доступность уязвимого интерфейса профилирования — это разные технические проблемы. Было бы некорректно утверждать, что все 12 000 обнаруженных графических процессоров гарантированно пострадали от найденной уязвимости.

Все тесты по исчерпанию системных ресурсов специалисты Lava проводили исключительно в изолированной контролируемой среде, не совершая реальных атак на публичные серверы. Результаты работы демонстрируют теоретический вектор атаки, но не доказывают, что организации подверглись реальным взломам или столкнулись с кражей данных своих ИИ-моделей.

Почему безопасность GPU-серверов зависит от правильной настройки мониторинга

Аббревиатура DCGM расшифровывается как Data Center GPU Manager. Официальное ПО DCGM Exporter от компании NVIDIA собирает определенные параметры работы видеокарт и транслирует их в формате, который понимает популярная система мониторинга Prometheus. Обычно этот интерфейс используется администраторами для контроля за состоянием и нагрузкой на вычислительные узлы.

Метрики вроде температуры, уровня утилизации чипа, загрузки памяти, энергопотребления и системных ошибок необходимы операторам для оценки стабильности вычислений. Однако если те же самые данные становятся доступны посторонним лицам, они превращаются в ценный источник информации для разведки и составления карты инфраструктуры.

Открытые ответы сервера могут выдать точные модели оборудования и особенности его эксплуатации. Регулярный сбор таких метрик позволяет внешнему наблюдателю выявить периоды пиковой активности и составить график работы систем. Хотя эти сведения напрямую не доказывают, что на сервере обучается конкретная нейросеть, они помогают злоумышленникам сузить круг поиска и понять структуру сети.

Необходимо разграничивать уровни доступа. Чтение телеметрии графического процессора не эквивалентно доступу к весам ИИ-модели, обучающим датасетам или пользовательским промптам. И тем не менее, детальная информация об инфраструктуре представляет ценность: злоумышленник, знающий точные версии компонентов программного обеспечения и моделей оборудования, получает гораздо более конкретную отправную точку для планирования атаки, чем при работе с полностью закрытой системой.

Технические детали уязвимости в службе мониторинга

Согласно бюллетеню безопасности от NVIDIA, уязвимость кроется в конечных точках /debug/pprof инструмента DCGM Exporter. Одновременные неавторизованные запросы на профилирование могут привести к неконтролируемому расходу ресурсов процессора и оперативной памяти, вызывая отказ в обслуживании (DoS) и потенциальное раскрытие системных данных.

Профилирование является стандартной диагностической функцией, помогающей разработчикам отслеживать поведение памяти и процессора внутри приложения. Проблема безопасности возникает тогда, когда ресурсоемкая внутренняя функция становится доступной для внешних недоверенных запросов без проверки прав доступа.

Специалисты Lava изначально предполагали, что столкнулись с ошибкой конфигурации со стороны владельцев серверов, однако затем успешно воспроизвели проблему, используя официальный Docker-контейнер от NVIDIA. Тесты показали, что чрезмерная нагрузка способна аварийно завершить работу экспортера, полностью лишая администраторов возможности отслеживать состояние оборудования. Нагрузка на центральный процессор и память хоста также может негативно повлиять на стабильность процессов обучения или генерации ИИ, запущенных на том же физическом сервере.

При этом сбой в работе экспортера мониторинга не останавливает автоматически сами вычисления на GPU. Первичным следствием становится именно потеря видимости. Степень влияния на соседние рабочие процессы зависит от уровня изоляции ресурсов в конкретной ИТ-архитектуре. Это классическая уязвимость программного обеспечения, развернутого вокруг графической инфраструктуры, а не дефект самих чипов.

С операционной точки зрения это различие критично. Если мониторинг пропадает в момент замедления основных вычислений, дежурным инженерам необходимо понимать, вызвано ли это сбоем самой системы наблюдения. Восприятие пропавших метрик как простой технической неполадки в системе сбора данных может задержать обнаружение активной атаки, направленной на исчерпание ресурсов.

Обнаружение открытых узлов на других уровнях инфраструктуры

В публикации Lava также приводится информация об обнаружении 12 096 публично доступных хостов Node Exporter. Этот инструмент выполняет иную роль, нежели DCGM Exporter — он собирает общие данные о работе сервера и операционной системы. Открытые телеметрические данные содержали подробные сведения о конфигурации операционной системы и аппаратной части серверов, окружающих ИИ-инфраструктуру.

Эксперты рекомендуют разделять эти метрики. Данные по Node Exporter указывают на общие проблемы с безопасностью сетевого периметра организаций, а не на число серверов, уязвимых непосредственно к CVE-2026-47483. Объединение этих цифр исказило бы понимание реальных рисков для каждого отдельного сервиса.

Основной вывод из сложившейся ситуации заключается в том, что безопасность искусственного интеллекта должна охватывать не только сами модели, но и уровни управления и мониторинга. Контроль доступа к API нейросети не защищает автоматически сопутствующие сервисы сбора метрик. Организация может надежно закрыть доступ к самой модели ИИ, но оставить открытым для всего интернета вспомогательный интерфейс на том же сервере.

Обновление ПО и ограничение доступа как разные методы защиты

Производитель уже выпустил необходимые исправления. В бюллетене NVIDIA указано, что уязвимость устранена в версии DCGM Exporter 4.8.2, а также в обновлении DCGM 4.5.3. Администраторам систем следует изучить официальные рекомендации вендора и использовать только проверенные сочетания версий для своих дистрибутивов.

Важно понимать, что установка патча решает проблему самой уязвимости программного кода, но не закрывает доступ к метрикам из внешней сети. Даже обновленный экспортер продолжит транслировать важные системные данные, если его сетевой порт останется открытым для всего интернета без авторизации.

В документации по безопасности системы Prometheus содержится прямое предупреждение о недопустимости публикации HTTP-интерфейсов компонентов в открытых сетях без дополнительных защитных мер. Руководство описывает риски перегрузки сервисов запросами к метрикам, API и Go-профилировщику.

Рекомендации по защите ИИ-инфраструктуры

Для системных администраторов и инженеров, проверяющих безопасность своих вычислительных кластеров, эксперты предлагают последовательный план действий:

• Провести инвентаризацию: Четко определить, какие экспортеры, серверы Prometheus и диагностические интерфейсы запущены в системе, кто отвечает за их обслуживание и как к ним можно получить доступ.
• Применить обновления безопасности: Установить исправленные версии ПО от вендора, предварительно проверив реальные версии запущенных контейнеров, а не только конфигурационные файлы.
• Ограничить сетевой доступ: Использовать изолированные подсети, настройки брандмауэров и группы безопасности для того, чтобы метрики были доступны только легитимным серверам сбора данных.
• Отключить неиспользуемые функции профилирования: Специалисты рекомендуют держать флаг --enable-pprof выключенным, если в профилировании нет прямой необходимости. В актуальных версиях ПО эта опция требует явного включения пользователем.
• Настроить контроль работоспособности: Убедиться, что авторизованный сбор метрик работает стабильно, а любые внезапные падения экспортеров фиксируются дежурными службами.

Каждый из этих шагов направлен на решение самостоятельной задачи: наличие дефектов в коде, физическая доступность сервиса для внешних лиц и своевременное обнаружение сбоев в работе систем наблюдения.

Распределение ответственности за безопасность вычислений

В современных реалиях мощности GPU часто распределены между инфраструктурой облачного провайдера и сервисами, которые разворачивает сам клиент. Качественный аудит безопасности должен четко определять, кто отвечает за обновление каждого программного компонента, кто контролирует сетевой периметр и кто реагирует на сообщения об открытых портах. При отсутствии явного разделения зон ответственности критически важный сервис мониторинга может оказаться в “слепой зоне” между командами, каждая из которых будет рассчитывать на защитные меры другой стороны.

Главный практический урок исследования заключается в том, что защита вычислений для искусственного интеллекта невозможна без обеспечения безопасности систем их измерения и контроля. Опубликованные данные фиксируют серьезные системные упущения прошлых периодов, а официальные рекомендации NVIDIA предоставляют понятный путь для исправления уязвимости. Основной задачей для администраторов сейчас является аудит текущих конфигураций и перевод внутренних служб мониторинга в доверенную зону сети.