Dell Container Storage Modules: две уязвимости на 10 баллов открывают СХД и узлы Kubernetes

Коротко о главном

1 октября 2026 года Dell выпустила бюллетень DSA-2026-448 для Container Storage Modules (CSM) — набора модулей, подключающих СХД Dell к Kubernetes. Две уязвимости получили максимальные 10 баллов CVSS: без аутентификации можно получить учётные данные администратора всех подключённых массивов. Обходных мер нет — обновляйтесь до CSM 1.18.0.

Для команд, которые держат stateful-нагрузки в собственном Kubernetes, это не локальный баг драйвера, а дыра на стыке двух зон ответственности: платформы и систем хранения. Через модуль авторизации CSM проходят доступы ко всем массивам, поэтому его компрометация бьёт сразу по данным всех арендаторов кластера. Если хранение и оркестрация у вас разведены между разными командами, обновление легко «потерять» — такие компоненты стоит закрепить в регламенте DevOps-сопровождения.

Часть уязвимостей требует лишь низкопривилегированной учётной записи в кластере и ведёт к root на узлах. Насколько далеко атакующий продвинется от одного сервисного аккаунта до секретов и СХД, показывает тестирование на проникновение инфраструктуры, а базовые принципы изоляции разобраны в нашем руководстве по Kubernetes.

Что исправила Dell в бюллетене DSA-2026-448

Бюллетень закрывает 13 собственных уязвимостей CSM: шесть критических, четыре высокого и три среднего уровня. Ещё 16 CVE относятся к сторонним компонентам — библиотекам golang.org/x/crypto, JWT и protobuf. Самые опасные дефекты сосредоточены в модуле CSM Authorization и в CSM Operator:

• CVE-2026-63688 (CVSS 10.0) — нет аутентификации в gRPC-сервере csm-authorization-storage. Удалённый неаутентифицированный атакующий получает учётные данные администратора всех зарегистрированных массивов хранения.
• CVE-2026-63692 (CVSS 10.0) — нет аутентификации в прокси авторизации и tenant-сервисе. Даёт полный административный контроль над сервисом авторизации и доступ к ресурсам хранения всех арендаторов.
• CVE-2026-67269 (CVSS 9.9) — некорректное управление привилегиями в CSM Operator: низкопривилегированный пользователь через специально подготовленный ресурс ContainerStorageModule получает root на узлах Kubernetes.
• CVE-2026-54472 (CVSS 9.8) — жёстко зашитые учётные данные, позволяющие подделывать валидные административные JWT.
• CVE-2026-61421 (CVSS 9.8) — зашитый криптографический ключ в архивном компоненте karavi-authorization: публично известный секрет подписи позволяет выпускать поддельные токены.
• CVE-2026-67273 (CVSS 9.6) — инъекция в шаблонизатор CSM Operator, которая даёт чтение Kubernetes Secrets во всём кластере и создание кластерных RBAC-ресурсов.

Какие версии затронуты

По данным Dell, уязвимы все версии Container Storage Modules до 1.17.0; исправления вошли в 1.18.0 и более поздние версии. В графе «обходные меры» бюллетень указывает «нет», так что единственный способ закрыть риск — обновление. На момент публикации Dell не сообщает об эксплуатации в реальных атаках, публичного эксплойта также не зафиксировано.

Почему модуль авторизации хранилища — критическая точка

CSM Authorization задуман как посредник: драйверы CSI в кластерах не получают прямых админских доступов к массивам, а работают через прокси с квотами и токенами арендаторов. Обратная сторона такой схемы — в одном сервисе собираются ключи от всего хранилища. Отсутствие проверки подлинности на этом уровне превращает защитный слой в единую точку компрометации: атакующий может менять конфигурацию СХД, читать данные, нарушать работу нагрузок и закрепляться в среде.

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

Что делать командам эксплуатации

Обновите CSM до 1.18.0 или новее во всех кластерах, включая тестовые и DR-площадки: модуль авторизации часто разворачивается один раз и надолго выпадает из патч-цикла.

Ротируйте секреты подписи JWT и токены арендаторов CSM Authorization после обновления. Старые токены, подписанные скомпрометированным ключом, нужно отозвать.

Проверьте журналы доступа CSM Authorization и использование административных токенов на предмет обращений без ожидаемой аутентификации.

Проведите аудит RBAC: ищите неожиданные ClusterRole и ClusterRoleBinding, а также изменённые ресурсы ContainerStorageModule. Ограничьте сетевой доступ к сервисам авторизации — они не должны быть доступны из пользовательских сегментов.

Часто задаваемые вопросы

Затрагивает ли уязвимость тех, кто не использует СХД Dell? Нет. Проблема касается только кластеров, где развёрнуты Dell Container Storage Modules и драйверы CSI для массивов Dell.

Можно ли обойтись без обновления? Dell прямо указывает, что обходных мер нет. Сетевая изоляция снижает риск, но не устраняет его.

Эксплуатируются ли уязвимости? На момент публикации сведений об атаках и публичного эксплойта нет, но с выходом патча разбор изменений становится вопросом времени.

Нужно ли что-то делать после установки 1.18.0? Да: перевыпустить секреты подписи JWT, отозвать старые токены и проверить RBAC и журналы на следы вмешательства.

Источники

Dell — DSA-2026-448: Security Update for Dell Container Storage Modules Multiple Vulnerabilities, 1 октября 2026 года (первоисточник).

The Hacker News — Dell CSM Flaws Enable Unauthenticated Admin Access and Root on Kubernetes Nodes, 2 октября 2026 года.

Cyber Security News — Critical Dell Container Storage Flaws Let Unauthenticated Attackers Gain Full Administrative Control, 3 октября 2026 года.