Dell призвала срочно обновить Dell System Update (DSU): критическая уязвимость CVE-2026-86360 позволяет удалённому атакующему без учётной записи потенциально выполнить произвольный код с правами root. Причина — ошибка обработки путей к файлам. Как сообщает BleepingComputer со ссылкой на предупреждение Dell, исправление входит в DSU версии 2.3.0.0 и более поздние выпуски. Подробности — в источнике.
DSU — утилита командной строки, через которую администраторы устанавливают обновления BIOS, прошивок и программного обеспечения на серверах PowerEdge под Linux и Windows. Поэтому проверять нужно не только серверы, на которых сейчас идёт обновление, но и те, где утилиту оставили после прежнего обслуживания. Вместе с критической ошибкой Dell закрыла в DSU четыре уязвимости высокой степени опасности: CVE-2026-63697 и CVE-2026-71168 связаны с удалённым выполнением кода, CVE-2026-86361 и CVE-2026-86362 — с повышением привилегий.
Почему утилита обновления попадает в приоритетный список
Обычный серверный сервис легко найти в реестре приложений: у него есть владелец, адрес и порядок сопровождения. С DSU бывает иначе. Администратор мог установить её ради прошивки контроллера, добавить в образ ОС или вызвать из задания автоматизации. Когда работы закончились, пакет остался. Именно такую «вспомогательную» установку легко пропустить при плановом разборе уязвимостей.
Здесь цена ошибки выше, чем у рядовой пользовательской программы. Утилита обслуживает инфраструктуру PowerEdge, а описанная Dell атака допускает выполнение кода с максимальными правами. Приоритет проверки определяйте не по тому, насколько часто запускают DSU, а по сочетанию версии, доступности уязвимого компонента и роли сервера. Узел виртуализации, сервер резервного копирования и машина с доступом к административной сети требуют особенно аккуратного разбора последствий.
Формулировка «удалённый атакующий» не означает, что на каждом PowerEdge открыт одинаковый сетевой порт. Не стройте схему атаки по одному заголовку новости. Для своей установки выясните, какие компоненты DSU задействованы, откуда к ним есть доступ и какие сетевые ограничения действуют. Даже если внешний доступ исключён, это не повод откладывать исправление на неопределённый срок: внутренние сегменты тоже входят в модель угроз.
Порядок работ: от инвентаризации до повторной проверки
- Найдите все установки DSU. Сверьте данные системы управления конфигурациями с установленными пакетами на Linux, списком программ и файлов на Windows, а также с образами развёртывания и сценариями обновления. Зачем: инвентаризация только работающих процессов не обнаружит утилиту, которую запускают по расписанию или вручную. Зафиксируйте сервер, версию, владельца системы и способ установки; не ограничивайтесь общим списком оборудования Dell.
- Проверьте фактическую версию и доступ. Сопоставьте версию каждой найденной установки с порогом 2.3.0.0 или более поздним выпуском. Затем посмотрите правила межсетевого экрана, доступ из административных подсетей, задания оркестрации и учётные записи, от имени которых работает обновление. Зачем: так вы отделите срочное исправление уязвимой установки от проверки пакета, который уже обновлён, и сможете снизить доступность компонента до окончания работ.
- Разберите зависимости перед заменой пакета. На тестовом узле проверьте, как новая версия DSU взаимодействует с вашей ОС, моделью сервера, репозиториями обновлений и существующими сценариями. Сохраните используемые параметры запуска и перечень заданий. Зачем: замена утилиты не должна неожиданно остановить очередное обслуживание прошивок или изменить поведение автоматизации. При вопросах по поддерживаемым сочетаниям опирайтесь на документацию Dell и подтверждение поставщика.
- Подготовьте окно и путь отката. Разделите обновление самой DSU и установку BIOS или прошивок: это разные изменения с разными рисками простоя. Убедитесь, что резервные копии и процедура восстановления актуальны, согласуйте окно с владельцем сервиса, назначьте ответственного за проверку после работ. Зачем: попытка одновременно исправить утилиту и обновить все прошивки усложняет поиск причины сбоя.
- Обновите DSU и проверьте результат. Установите версию 2.3.0.0 или новее из официального канала, затем повторно проверьте установленную версию и выполнение штатных заданий обновления. Отдельно проверьте, не сохранился ли старый пакет в шаблоне развёртывания, локальном репозитории или сценарии подготовки нового сервера. Зачем: иначе исправленный узел легко заменить новым — с той же уязвимой версией.
- Закройте работу записью в инвентаризации. Зафиксируйте результат проверки, версию после обновления, исключения и назначенного владельца каждого оставшегося узла. Если обновить систему сразу нельзя, документируйте временное ограничение доступа и дату повторного рассмотрения. Зачем: без такого следа следующий дежурный не отличит сознательно отложенную работу от забытого сервера.
Что проверить в журнале и чего не ждать от патча
При обнаружении старой версии не ограничивайтесь установкой новой. Просмотрите журналы ОС, запуска DSU и средств централизованного мониторинга за доступный период: необычные вызовы утилиты, изменения файлов, незнакомые административные действия. Сопоставляйте события с утверждёнными работами — легитимное обновление тоже выглядит как изменение системных файлов. Если есть признаки посторонней активности, действуйте по процедуре реагирования, а не пытайтесь «лечить» возможный инцидент одной заменой пакета.
Dell пока не отмечала перечисленные уязвимости как активно эксплуатируемые. Это не подтверждение безопасности конкретного сервера и не основание объявлять его скомпрометированным. Практический вывод проще: исправляйте уязвимую версию, проверяйте доступ и сохраняйте данные, нужные для расследования, если оно потребуется.
Не смешивайте эту задачу с другими предупреждениями Dell. В тот же день компания призвала исправить две уязвимости максимальной степени опасности в Container Storage Modules — CVE-2026-63688 и CVE-2026-63692. Если в инфраструктуре используется CSM, заведите для него отдельную проверку и отдельный план обновления. Обновление DSU само по себе не заменяет работу с другим продуктом.
Где чаще всего ломается план обновления
- Проверяют только Linux. DSU применяется и на Windows-системах PowerEdge. Список активов и сценарии поиска должны охватывать обе платформы; при этом формулировку о правах root не стоит механически переносить на модель привилегий Windows.
- Путают версию утилиты с версией прошивки. Свежий BIOS не доказывает, что исправлена DSU. Проверяйте именно установленный пакет, а затем отдельно оценивайте состояние прошивок.
- Удаляют компонент без разговора с эксплуатацией. Если DSU встроена в регламент обслуживания, удаление может сорвать запланированные обновления. Сначала найдите зависимости, затем решайте, обновлять утилиту или выводить её из эксплуатации.
- Полностью полагаются на сегментацию. Ограничение доступа снижает риск, но не исправляет ошибку в пакете. Проверка сетевых правил — временная мера и часть контроля, а не замена обновлению.
Для команд в Казахстане здесь есть и закупочная часть работы. Если серверы обслуживает подрядчик или DSU включена в поставляемый образ, запросите подтверждение версии, перечень совместимых ОС и моделей, документацию по обновлению и порядок поддержки после установки. При планировании окна заранее согласуйте доступ к нужным пакетам и действия на случай неудачного обновления; сроки поставки оборудования или обслуживания уточняйте под свой проект. При выборе серверов полезно сразу закрепить, кто отвечает за обновление служебных утилит после ввода системы в эксплуатацию: поставщик, подрядчик или внутренняя команда.
Исправить пакет — и не потерять его снова
Главное действие сейчас — найти DSU на PowerEdge и довести обнаруженные установки до версии 2.3.0.0 или новее, не забыв про образы и автоматизацию. Параллельно проверьте доступ и сохраните понятный след выполненных работ. За другими практическими разборами серверной инфраструктуры можно следить в блоге.