Docker Hub передавал чужие ключи доступа новому владельцу при превращении личного аккаунта в организацию. Персональный токен доступа (PAT, personal access token - строка-пароль, которой автоматика подключается к реестру) оставался на руках у прежнего владельца, но начинал аутентифицироваться как новый. Значит, злоумышленник мог завести одноразовый аккаунт, получить токен и назвать владельцем организации постороннего человека. Такой токен открывал доступ к его приватным репозиториям и образам. Проблема жила больше двух лет, с 26 августа 2024 года по 30 сентября 2026-го. Docker отнесла её к критическому уровню из-за риска для цепочки поставок программного обеспечения. Следов реальной эксплуатации вендор не нашёл.
CVE-2026-105445 и механика переноса токенов
Конвертация нужна потому, что в Docker Hub нет способа перенести репозиторий между аккаунтами. Превращение личной учётной записи в организацию сохраняет прежние имена образов, поэтому уже настроенные команды скачивания продолжают работать без правок. Во время конвертации пользователь указывает существующий аккаунт Docker Hub владельцем новой организации. С 26 августа 2024 года этот шаг заодно переводил на указанного владельца персональные токены конвертируемого аккаунта. Вендор менял запись о владельце токена, но не отзывал и не перевыпускал сам секрет. Согласия человека никто не спрашивал, уведомление тоже не отправлялось. Эти два пробела и открыли путь для атаки.
Сценарий выглядит так. Злоумышленник создаёт аккаунт, выпускает на нём токен, конвертирует аккаунт в организацию и называет владельцем жертву. Токен переходит к жертве, однако секрет остаётся у атакующего. Дальше токен действует уже с правами жертвы, а на уровне реестра образов аутентифицируется как она.
Объём доступа зависел от прав токена и привилегий самой жертвы. В этих границах атакующий мог скачивать, публиковать и удалять образы в её репозиториях и в организациях, куда у неё был доступ. Публикация изменённого образа под доверенным именем создаёт риск для цепочки поставок, поскольку пользователи скачивают его, доверяя имени. Веб-интерфейс Docker Hub уязвимость не открывала. Сменить пароль, адрес электронной почты или настройки двухфакторной аутентификации через неё было нельзя, полный захват аккаунта тоже исключён.
Об уязвимости 30 сентября 2026 года сообщили исследователи Петер Мольнар и Кристиан Хозак из mptrdev.com. Docker воспроизвела проблему на своих тестовых аккаунтах и меньше чем за четыре часа поставила исправление на рабочие серверы. Окно уязвимости растянулось с 26 августа 2024 года до момента исправления. Публично о ней рассказали 12 октября.
Разбор занял несколько дней. Docker перечислила все конвертации с 26 августа 2024 года и сопоставила их с журналами аутентификации реестра, данными об использовании и записями о токенах. Среди примерно 304 тысяч публикаций образов, сделанных с перенесёнными токенами, ни одна не попала в чужой аккаунт. Все они уходили либо в репозитории самой конвертированной организации, либо в репозитории нового владельца. Статический анализ самых рискованных публичных образов не выявил вредоносного ПО, майнеров, командно-контрольных серверов (C2), сбора учётных данных, закрепления в системе или подмены содержимого. Инфраструктура Docker тоже не пострадала.
Одна оговорка важна для оценки риска. Журналы фиксируют использование токена, а не его существование. Поэтому неиспользованный перенесённый токен не оставляет следов. По этой причине вендор считал потенциально затронутыми все перенесённые токены, а не только замеченные в работе.
Владельцев пострадавших аккаунтов уведомили 2 октября. В письме перечислены токены с описанием и датой создания, чтобы их можно было найти в Docker Hub. Организаторов уведомили отдельно. Восьмого октября Docker принудительно отключила перенесённые токены, кроме тех, что владельцы успели попросить оставить.
Само исправление убрало перенос токенов при конвертации. Теперь Docker требует согласия человека, прежде чем назначить его владельцем организации, и уведомляет о назначении. Кроме того, вендор записывает историю смены владельцев токенов и проверяет другие сценарии, где меняется владелец учётных данных.
Пользователям стоит заглянуть в настройки аккаунта, в раздел Personal access tokens, и отозвать незнакомые или ненужные токены. Для автоматизации организации лучше применять organization access tokens, а не личный токен сотрудника. Вопросы принимает поддержка Docker. Тем, кто не получил письмо от 2 октября, ничего делать не нужно: их аккаунты в эту схему не попадали.
Такие переносы прав на ключи доступа встречаются не только у Docker. История показывает, что опасен не сам факт смены владельца токена, а отсутствие у него нового секрета. Теперь Docker отвечает на подобные вопросы по записям о владельцах токенов, а не по косвенным признакам.
Ссылки
