Docker устранил критическую уязвимость CVE-2026-105445 в Docker Hub, которая на протяжении более двух лет — с 26 августа 2024 года по 30 сентября 2026 года — позволяла злоумышленнику привязать контролируемый персональный токен доступа (PAT) к учётной записи другого пользователя и выполнять операции с контейнерными образами от его имени. Уязвимость получила оценку 9,4 балла по CVSS 4.0 и статус критической. Исправление применено на стороне сервера Docker Hub, установка обновлений на клиентах не требуется. По данным Docker, признаков эксплуатации уязвимости в реальных атаках не обнаружено, однако этот вывод основан исключительно на внутреннем расследовании вендора и не подтверждён независимым аудитом.
Механизм уязвимости
Проблема, классифицированная как CWE-266 (некорректное назначение привилегий), затрагивала механизм преобразования личного аккаунта Docker Hub в аккаунт организации. Согласно записи CVE, при конвертации система автоматически передавала все персональные токены доступа (PAT) назначенному владельцу организации. Ключевая ошибка: секрет токена при этом не менялся, а согласие нового владельца не запрашивалось.
Сценарий атаки выглядел следующим образом:
- Атакующий создаёт аккаунт и генерирует PAT с нужными правами доступа.
- Конвертирует свой аккаунт в организацию, указывая жертву в качестве владельца.
- Docker Hub привязывает токен к учётной записи жертвы, при этом секрет токена остаётся прежним.
- Атакующий использует свой PAT для доступа к реестру — система аутентифицирует его как жертву.
В зависимости от разрешений токена и прав жертвы атакующий мог скачивать, загружать и удалять контейнерные образы в репозиториях жертвы, включая репозитории организаций, к которым та имела доступ. Доступ ограничивался операциями с реестром: веб-интерфейс Docker Hub, смена пароля, адреса электронной почты или настроек двухфакторной аутентификации оставались недоступны.
Почему присвоен критический статус
Несмотря на ограниченный периметр воздействия, Docker присвоил уязвимости критический статус из-за угрозы для цепочки поставок: злоумышленник мог публиковать вредоносные образы от имени легитимных разработчиков. Для контекста: ранее в 2026 году Docker сообщал о случаях, когда украденные учётные данные издателей использовались для загрузки вредоносных образов Trivy и KICS в их собственные репозитории. GhostPat предоставляла альтернативный вектор для аналогичных атак — без необходимости красть пароли.
Примечательная деталь: собственная документация Docker, начиная с апреля 2025 года, прямо описывала передачу PAT при конвертации аккаунта как штатное поведение. Это указание было удалено 30 сентября 2026 года — через считанные минуты после развёртывания исправления. Таким образом, уязвимое поведение около 17 из 25 месяцев существования бага было задокументировано как функция, а не ошибка.
Расследование и реагирование
Уязвимость обнаружили исследователи Петер Молнар и Кристиан Хозак (mptrdev.com), давшие ей название GhostPat. Согласно материалам The Hacker News, они дважды воспроизвели эксплуатацию на тестовых аккаунтах с согласия владельцев, подтвердив возможность входа в реестр от имени целевого пользователя, создания репозиториев в его пространстве имён и доступа к приватным репозиториям. Docker, по собственным данным, развернул исправление менее чем за четыре часа после получения отчёта.
По сообщению Docker, компания проверила все конвертации аккаунтов за период существования бага и проанализировала порядка 304 000 операций загрузки образов, выполненных с использованием переданных токенов. Все эти загрузки, по данным вендора, направлялись в репозитории конвертированной организации или её назначенного владельца, причём в подавляющем большинстве случаев оба аккаунта принадлежали одному лицу или команде. Для случаев, где это не удалось подтвердить, Docker проанализировал публичные образы повышенного риска и не обнаружил вредоносного кода. Следует учитывать, что эти данные не прошли независимую верификацию, а в отчёте Docker не раскрыты результаты проверки операций скачивания и удаления образов.
Практические рекомендации
2 октября 2026 года Docker уведомил пользователей, к аккаунтам которых были привязаны чужие токены, а также владельцев затронутых организаций. 8 октября потенциально опасные токены были деактивированы (за исключением тех, владельцы которых явно запросили сохранение). Пользователям, не получившим уведомления, по данным Docker, действий предпринимать не требуется.
Для тех, кто получил уведомление или хочет провести самостоятельную проверку:
- Откройте настройки аккаунта → Personal access tokens. Проверьте дату создания и последнего использования каждого токена.
- Отзовите токены, которые вы не создавали или больше не используете. Описание токена задаёт его создатель, поэтому знакомое имя не гарантирует легитимность.
- Проверьте список организаций в переключателе аккаунтов — неизвестная организация может быть следом конвертации.
- Для автоматизации на уровне организации используйте организационные токены доступа (требуется подписка Docker Team или Docker Business) вместо персональных PAT.
- Владельцы организаций на платных подписках могут проверить историю загрузок через журналы активности (хранятся 30 дней в интерфейсе, более ранние доступны через API).
- Если вы подписываете образы — проверьте подписи опубликованных образов и сопоставьте их с записями CI/CD-конвейера.
Docker сообщает, что теперь система требует явного согласия пользователя перед назначением его владельцем организации, уведомляет о таком назначении и фиксирует все изменения владельца токенов. Главное действие для пользователей Docker Hub — провести аудит своих PAT и перейти на организационные токены для любой автоматизации, связанной с организациями. Для потребителей публичных образов инцидент подчёркивает ценность верификации подписей образов: именно подпись, а не имя издателя, остаётся надёжным индикатором целостности в экосистеме контейнерных реестров.
