Red Hat съобщи за важна уязвимост в сигурността на инструмента OpenShift oc-mirror, която би могла да позволи на атакуващи да заобиколят PGP проверката на цифрови подписи и да внедрят злонамерени изображения на релизи в изолирани (disconnected) OpenShift среди.

Проблемът, проследяван като CVE-2026-75939, има CVSS v3.1 оценка от 7.4 и бе оповестен публично на 21 септември 2026 г. Уязвимостта засяга компонента openshift/oc-mirror, който организациите използват за копиране на OpenShift изображения на релизи, каталози с оператори и свързано съдържание в частни регистри (registries).

Този процес е особено важен за среди с прекъсната мрежова връзка (air-gapped) или изолирани системи, при които инсталациите не могат да изтеглят софтуер директно от регистрите на Red Hat или от публичния интернет.

Според Red Hat, oc-mirror неправилно валидира PGP-подписаните подписи на изображенията на релизи. Инструментът проверява за грешки в подписите, преди да е приключил с обработката на цялото тяло на подписаното съобщение.

Това създава условие за заобикаляне на проверката, при което специално конфигурирано PGP съобщение може да изглежда като доверено, въпреки че подписът му е фалшифициран.

Уязвимост в Red Hat OpenShift

За да извърши атаката, киберпрестъпникът трябва да има възможност да прихваща или променя трафика между засегнатия инстанс на oc-mirror и крайната точка за подписи. Считано оттук, той би могъл да предостави фалшифицирано PGP съобщение, което съдържа валиден идентификатор на ключ за релизи на Red Hat.

Поради компрометираната последователност на валидация, инструментът може да приеме злонамереното съобщение като легитимно и да огледално копира (mirror) злонамерен инжектиран код в изолирания регистър. Това представлява сериозен риск за веригата на доставки (supply-chain risk), тъй като огледално копираното съдържание обикновено се третира като одобрен вътрешен софтуер.

След като злонамереното изображение на релиз достигне до частния регистър, администраторите на OpenShift или автоматизираните пайплайни за инсталация могат да го изберат за внедряване. Това би могло да изложи клъстерите на неоторизирано изпълнение на код, манипулиране на приложения, кражба на идентификационни данни или достъп до данни.

Red Hat класифицира проблема като „Важен“ (Important) и му определи мрежов вектор на атака (network attack vector). Уязвимостта не изисква привилегии на атакуващия или потребителско взаимодействие.

Въпреки това, експлоатацията има висока сложност на атаката, тъй като киберпрестъпникът трябва успешно да манипулира мрежовия трафик, свързан с подписите. Векторът CVSS на Red Hat посочва високо въздействие върху поверителността и целостта, докато въздействието върху наличността е оценено като нулево.

Засегнатият компонент е openshift4/oc-mirror-plugin-rhel9 в Red Hat OpenShift Container Platform 4. Версията на плъгина за RHEL 8 е посочена като незасегната, тъй като компонентът не присъства там.

От Red Hat отбелязват, че по-старите версии на пакетите в засегнатите продуктови потоци следва по принцип да се считат за уязвими, освен ако изрично не е посочено друго.

Към момента на разкриването от Red Hat заявиха, че няма практическа стъпка за смекчаване на риска, която да отговаря на техните стандарти за внедряване и стабилност. Поради това организациите, използващи oc-mirror, трябва да третират работните процеси по огледално копиране на релизи като високорискови, докато не бъдат издадени бюлетини за сигурност или обновени пакети.

Администраторите трябва да ограничат мрежовия достъп до крайните точки за подписи, внимателно да прилагат защитни мерки за TLS инспекция, да следят за необичайни промени в съдържанието на огледалните регистри и да валидират контролните суми (digests) на релизите чрез независими доверени канали, преди внедряване на съдържанието в реална среда.

Екипите трябва също така да прегледат контрола на достъпа до изолираните регистри, да извършат одит на наскоро копираните релизи и да следят бюлетините за сигурност на Red Hat за нови актуализации и корекции за сигурност.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC