Уязвимости Dell CSM получили максимальную оценку критичности: две из них позволяют удаленному атакующему без учетной записи добраться до администраторских прав в storage-инфраструктуре. Для команд, которые подключают массивы Dell к Kubernetes, это не патч из серии «когда-нибудь в пятницу вечером», а повод быстро проверить версии Container Storage Modules и обновиться до 1.18.0 или новее.
Dell выпустила исправления для Container Storage Modules, которые расширяют стандартные CSI-драйверы Kubernetes и связывают кластеры с корпоративными системами хранения PowerStore, PowerScale, PowerFlex, PowerMax и Unity XT, сообщает BleepingComputer. Самые опасные проблемы находятся в Dell CSM Authorization — модуле, который отвечает за авторизацию доступа к storage-ресурсам.
Две уязвимости получили CVSS 10.0. Первая, CVE-2026-63688, связана с отсутствующей аутентификацией в csm-authorization-storage gRPC server. По описанию Dell, удаленный атакующий без привилегий может получить доступ к администраторским учетным данным backend-хранилищ для всех зарегистрированных массивов и обойти модель авторизации CSM. В практическом переводе с языка advisory: если такой компонент доступен атакующему, он может получить полный контроль над storage-инфраструктурой, которая обслуживает Kubernetes.
Вторая максимальная по тяжести проблема, CVE-2026-63692, находится в authorization proxy и tenant service. Она тоже относится к классу missing authentication for critical function: критическая функция есть, а проверки личности перед ней нет. Успешная эксплуатация дает злоумышленнику административный контроль над сервисом авторизации и потенциальный доступ к ресурсам хранения во всех tenant-сегментах. Для multi-tenant Kubernetes-сред это особенно неприятный сценарий: границы между командами и окружениями начинают выглядеть декоративно.
В тот же день Dell закрыла еще четыре критические уязвимости. CVE-2026-67269 позволяет удаленному атакующему без привилегий получить root на узлах кластера. CVE-2026-54472 ведет к административному доступу к CSM Authorization proxy. CVE-2026-61421 связана с возможностью подделки токенов аутентификации и получения админских прав. CVE-2026-67273 позволяет обходить Kubernetes access controls и читать Kubernetes Secrets на уровне всего кластера. Набор выглядит как плохой чек-лист для incident response: учетные данные storage, админка proxy, root на нодах, secrets из Kubernetes.
Dell рекомендует обновить Container Storage Modules до версии 1.18.0 или более поздней. Вендор пока не заявил, что эти конкретные уязвимости Dell CSM уже эксплуатируются в атаках. Но отсутствие такой отметки не равно низкому риску: речь идет о компонентах, которые стоят между Kubernetes и корпоративным хранением данных, а не о второстепенной утилите на забытой виртуалке.
Контекст тоже не успокаивает. В последние годы уязвимости в продуктах Dell уже использовались продвинутыми группировками. В одном из случаев северокорейская Lazarus эксплуатировала CVE-2021-21551 в драйвере Dell dbutil для установки Windows-руткита. В феврале Mandiant и Google Threat Intelligence Group сообщили, что группа UNC6201, которую связывают с Китаем, с середины 2024 года использовала максимальную по тяжести CVE-2026-22769 в Dell RecoverPoint for Virtual Machines. Тогда атакующие разворачивали вредоносные нагрузки и создавали скрытые сетевые интерфейсы на VMware ESXi. После этого CISA обязала федеральные агентства США закрыть проблему в течение трех дней.
Для российских и русскоязычных IT-команд главный вывод простой: проверить надо не только публичный периметр, но и внутренние Kubernetes-инсталляции, где CSM мог считаться «инфраструктурной сантехникой» и годами жить вне регулярного patch management. Если storage-команды и platform engineering работают раздельно, это хороший момент сверить инвентаризацию: какие кластеры используют Dell CSM, какие версии стоят, где включен Authorization module, кто владеет обновлением и есть ли резервный план на случай, если патч затронет persistent volumes.
Отдельная зона риска — Kubernetes Secrets. Даже read-only доступ к secrets на уровне кластера часто означает путь к сервисным токенам, строкам подключения, cloud-ключам и внутренним API. В хорошо построенной инфраструктуре такие секреты должны ротироваться и жить в специализированных хранилищах, но реальность обычно менее стерильна. Поэтому после обновления имеет смысл не ограничиваться галочкой «патч установлен», а проверить логи CSM-компонентов, сетевую доступность authorization-сервисов, подозрительные обращения к Kubernetes API и необходимость ротации наиболее чувствительных учетных данных.
Уязвимости Dell CSM хорошо показывают, как меняется профиль риска в Kubernetes: атакующему уже не обязательно ломать само приложение, если можно ударить по прослойке между кластером и инфраструктурой хранения. Чем больше enterprise-функций переезжает в cloud-native-обвязку, тем чаще именно такие модули будут становиться короткой дорогой к данным, правам администратора и очень долгому понедельнику для инфраструктурной команды.