14 октября 2026 года индийский центр реагирования CERT-In опубликовал предупреждение о критической уязвимости CVE-2026-105445 в Docker Hub. Ошибка при преобразовании личного аккаунта в организацию позволяла токену доступа действовать от имени другого пользователя и открывала возможность скачивать, публиковать или удалять его контейнерные образы. Docker устранила уязвимость на стороне сервиса ещё 30 сентября.

Docker Hub передавал токены новому владельцу организации без смены секрета
Проблема находилась в механизме преобразования личного аккаунта Docker Hub в организацию. Такой переход нужен командам, которым требуется совместный доступ к репозиториям. Названия репозиториев при этом сохраняются: образ, доступный по привычному адресу, продолжает использоваться в сборках и развёртывании приложений.
Для автоматической работы с реестром Docker Hub применяет персональные токены доступа — Personal Access Tokens (PAT). Они позволяют, например, системе непрерывной интеграции получать или отправлять образы без ввода пароля пользователя при каждом обращении.
С 26 августа 2024 года при преобразовании аккаунта сервис переносил существующие PAT на учётную запись назначенного владельца организации. В базе менялась принадлежность токена, но его секрет оставался действительным. При этом человек, которого указывали новым владельцем, не подтверждал назначение и не получал уведомления.
Из-за сочетания этих ошибок создатель токена мог сохранить его секрет и после переноса использовать его с правами другого пользователя. Доступ определялся разрешениями самого PAT и репозиториями, доступными новому владельцу, включая репозитории организаций. Уязвимость получила идентификатор CVE-2026-105445 и оценку 9,4 балла по CVSS 4.0 — критический уровень.
Подмена владельца PAT создавала риск для цепочки поставки контейнерных образов
14 октября CERT-In выпустил бюллетень CIVN-2026-0504. В нём отдельно выделен риск несанкционированной публикации вредоносных образов под именем легитимного пользователя. Это затрагивает цепочку поставки ПО: приложения и серверы получают готовые контейнерные образы из реестра, а доверие к имени автора и репозитория влияет на то, какой код будет запущен.
Представим систему CI/CD, которая автоматически загружает образ из Docker Hub перед развёртыванием. Если посторонний получает право публикации в таком репозитории, он потенциально может изменить содержимое образа. Следующая сборка или установка, использующая обновлённый образ, рискует получить код, который команда не собиралась распространять. Это возможный сценарий атаки, а не подтверждённый случай эксплуатации CVE-2026-105445.
Границы доступа были конкретными. С перенесённым токеном можно было выполнять разрешённые ему операции в реестре контейнерных образов — pull, push и delete. Доступа к веб-интерфейсу Docker Hub уязвимость не давала; смена пароля, электронной почты и настроек двухфакторной аутентификации через такой токен была недоступна.
Docker исправила механизм 30 сентября и отключила перенесённые PAT
Исследователи Петер Молнар и Кристиан Хозак сообщили об ошибке 30 сентября 2026 года. Docker воспроизвела проблему и менее чем за четыре часа после получения сообщения исправила облачный сервис. С этого момента преобразование личного аккаунта в организацию перестало переносить персональные токены доступа.
Дальнейшие действия Docker были связаны с токенами, которые успели перенести за предыдущие два года:
- 2 октября компания отправила сообщения пользователям и владельцам организаций, чьи аккаунты могли оказаться затронуты. Тема письма —
Docker Hub Vulnerability Identified & Resolved. - 8 октября Docker принудительно деактивировала выявленные перенесённые PAT. Исключением стали токены, владельцы которых заранее отказались от отключения.
- 12 октября Docker опубликовала подробный разбор уязвимости и результаты проверки.
- 14 октября CERT-In выпустил собственное предупреждение, присвоив риску критический уровень.
Изменение произошло в Docker Hub, то есть в размещённом у Docker сервисе хранения образов. Обновление локального Docker Engine или Docker Desktop само по себе не является способом исправления этой ошибки: её причина заключалась в обработке учётных записей и токенов на стороне Hub.
Как определить, затрагивала ли CVE-2026-105445 конкретную учётную запись
Docker заявляет, что уведомила всех пользователей, чьи аккаунты получили PAT в результате преобразования, и отдельно — соответствующих владельцев организаций. По информации компании, отсутствие письма от 2 октября означает, что токены аккаунта через уязвимый механизм не переносились и этот сценарий его не затронул.
После исправления документация Docker прямо указывает: при преобразовании личного аккаунта в организацию прежние PAT прекращают работать. Для дальнейшей автоматизации владелец организации создаёт новые учётные данные; Docker предлагает использовать organization access tokens (OAT), предназначенные для доступа от имени организации.
Таким образом, механизм работы после преобразования отличается от прежнего. Раньше секрет PAT мог пережить смену владельца и приобрести новые полномочия. Теперь старые персональные токены не переходят в новую организацию.
Docker не обнаружила следов использования уязвимости
Компания проверила историю преобразований аккаунтов с августа 2024 года, данные аутентификации, записи о токенах и примерно 304 тысячи операций публикации образов, выполненных с перенесёнными PAT. «Мы не обнаружили свидетельств эксплуатации уязвимости», — сообщила Docker по результатам этого аудита. Дополнительный статический анализ наиболее рискованных общедоступных образов также не выявил вредоносного содержимого или признаков подмены.
При этом разработчики обозначили ограничение проверки: журналы реестра показывают использование токена, но по ним нельзя судить о том, кто мог знать его секрет, если токен не применялся. Поэтому все PAT, затронутые переносом в рассматриваемый период, компания учитывала как потенциально уязвимые независимо от обнаруженной активности.
Предупреждение CERT-In от 14 октября касается уже закрытой ошибки. Исторический период её существования — с 26 августа 2024 года до 30 сентября 2026 года — объясняет, почему вопрос о доверии к опубликованным контейнерным образам сохранил значение и после исправления сервиса.