Red Hat раскрыла уязвимость CVE-2026-75939 в утилите oc-mirror, которая входит в OpenShift Container Platform 4. Ошибка затрагивает проверку подписей релизных образов. Злоумышленник, способный вмешаться в сетевой обмен, отправляет в закрытый реестр подделанное содержимое, и операторы принимают его за доверенное. Предварительная оценка по шкале CVSS, то есть по системе оценки уязвимостей, - 7,4 балла. Уровень важности Red Hat обозначила как высокий. Публикация датирована 21 сентября 2026 года, тогда же запись обновили в последний раз.
Уязвимость CVE-2026-75939
Утилита oc-mirror нужна там, где кластеры работают без выхода в публичные реестры. Администратор запускает её на машине с доступом в интернет, утилита забирает релизные образы Red Hat из внешних источников и складывает их во внутренний реестр организации. Такой порядок сохраняет сведения о происхождении образов: у каждого остаётся подпись PGP (Pretty Good Privacy - криптографическая подпись, подтверждающая, что образ выпустила и подписала конкретная сторона). Пока кластер отрезан от сети, эта подпись служит главным доказательством подлинности. Никакая внешняя служба больше не может подтвердить, что перед нами именно оригинал.
Ошибка кроется в последовательности действий. Утилита ищет признаки проблемы в подписи раньше, чем обрабатывает весь подписанный блок данных. Из-за этого часть проверки не выполняется, и подпись можно обойти. Категория проблемы - CWE-347, некорректная проверка криптографических подписей.
Воспользоваться уязвимостью может тот, кто перехватывает или подменяет трафик к серверу, откуда утилита получает подписи. Злоумышленник собирает PGP-сообщение, где указан подлинный идентификатор релизного ключа Red Hat, а подпись внутри подделана. Если организация принимает такие метаданные, содержимое попадает во внутренний реестр как прошедшее проверку подлинности. После этого развёртывания работают с образом, которым управляет атакующий, а специалисты считают его доверенным. Red Hat предупреждает, что такой сценарий ставит под сомнение целостность программного обеспечения в изолированных средах.
Атака достижима по сети. Учётные данные и привилегии ей не нужны, участие пользователя не требуется, зато сложность высокая: попасть в поток данных между утилитой и сервером подписей удаётся не всегда. Вектор CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N описывает высокое влияние на конфиденциальность и целостность, тогда как доступность не страдает. Данных о реальных атаках с использованием этой уязвимости в бюллетене нет.
Затронут компонент oc-mirror-plugin-rhel9 для OpenShift Container Platform 4. Плагин для RHEL 8 уязвимости не подвержен, потому что этого компонента в нём нет. Red Hat напоминает: если для версии пакета не сказано обратного, её следует считать уязвимой, даже когда полный анализ не проводился. Сильнее всего рискуют госструктуры, промышленные предприятия и другие владельцы изолированных кластеров. Подмена образа не проявится при обычной работе, зато затронет все системы, развёрнутые из него.
Хранилища образов и утилиты для их переноса давно стали целью атак на цепочку поставок, то есть на путь программного обеспечения от разработчика до площадки заказчика. Один изменённый образ способен привести на площадку вредоносное содержимое, которое затем расходится по всем развёртываниям. Отсюда и требования к проверке подписей: она подтверждает не только авторство, но и неизменность файла. Важность проблемы Red Hat связывает именно с доверием к содержимому, которое попадает в закрытый контур.
Готового исправления нет. Выпущенного бюллетеня безопасности тоже нет. Варианты компенсации, которые Red Hat могла бы предложить, не прошли её критерии простоты, применимости к широкой базе установок и стабильности. До появления патча организациям остаются организационные и сетевые меры, а значит, ответственность за проверку содержимого переходит к администраторам.
Сначала нужно выяснить, где установлен затронутый плагин для RHEL 9. Доступ к сетевым путям, по которым утилита забирает подписи, ограничивают и ставят под наблюдение. Затем проверяют настройки прокси, DNS, инспекции TLS и правила исходящих соединений: через эти точки удобнее всего заметить вмешательство в трафик. Перед выводом содержимого в промышленную эксплуатацию контрольные суммы и происхождение образов подтверждают по независимому каналу. Службе реагирования на инциденты стоит хранить журналы зеркалирования и после каждой синхронизации сверять содержимое реестра с манифестами. Права на запись в реестр сужают, эталонные манифесты сохраняют, а любое неожиданное изменение контрольной суммы образа разбирают отдельно. Такая рутина помогает заметить подмену до того, как изменённый образ станет частью базовой конфигурации развёртывания. Полезно также фиксировать, кто и когда запускал утилиту: журналы операций пригодятся при разборе инцидента, если подозрительный образ уже успел попасть в реестр.
Ошибки в проверке криптографических подписей опасны тем, что не мешают системам работать и не создают заметных сбоев. В изолированной среде подменённый образ живёт рядом с оригиналом, а выявить его можно только при ручной сверке. Пока патч не вышел, проверка происхождения образов целиком ложится на администраторов, и именно от их дисциплины зависит, останется ли доверие к содержимому обоснованным.
Ссылки
