Уязвимость GhostPat позволяла пользователю Docker Hub действовать в реестре от имени другого владельца. В зависимости от прав токена можно было скачивать, публиковать и удалять образы в чужих репозиториях, включая приватные. Docker присвоил проблеме номер CVE-2026-105445 и критический статус; опубликованная 13 октября оценка CVSS 4.0 составила 9,4. Исправление развернули на Docker Hub 30 сентября, устанавливать обновление пользователям не требовалось. Docker заявил, что не нашёл признаков эксплуатации.
Ошибка возникала при преобразовании личного аккаунта в организацию. Docker Hub не переносит репозиторий между аккаунтами: вместо этого пользователь превращает личную учётную запись в организацию с тем же именем и назначает владельцем существующего аккаунта. С 26 августа 2024 года до 30 сентября 2026-го при такой операции менялась запись о владельце каждого персонального токена доступа (PAT), но его секрет оставался прежним.
PAT используют вместо пароля для доступа к реестру; токен действует с правами, выбранными при создании, и продолжает работать у создавшего его человека. Поэтому схема атаки была короткой: злоумышленник выпускал PAT на контролируемом аккаунте, превращал аккаунт в организацию и указывал владельцем другого пользователя. После этого токен принимался реестром Docker Hub как токен нового владельца. Тот не должен был подтверждать назначение и, по данным Docker и исследователей, не получал уведомления.
При наличии соответствующих прав токен открывал доступ к репозиториям указанного владельца и организациям, которыми тот мог пользоваться. Через него можно было скачивать образы, отправлять новые и удалять существующие. Доступ ограничивался реестром: токен не давал входа в веб-интерфейс Docker Hub и не позволял менять пароль, адрес электронной почты или настройки двухфакторной аутентификации, а значит, не обеспечивал захват аккаунта целиком. Docker назвал уязвимость критической, поскольку она позволяла «публиковать образы под легитимным именем».
О GhostPat сообщили Docker Питер Молнар и Криштиан Хозак с . По словам компании, исправление было развёрнуто менее чем через четыре часа после их сообщения. В техническом разборе исследователи рассказали, что дважды воспроизвели проблему на тестовых аккаунтах с согласия владельцев: вошли в реестр как целевой пользователь, создали репозиторий в его пространстве имён и отправили туда образ, затем опубликовали образ в организации, к которой принадлежал пользователь, и скачали его приватные репозитории.
В уведомлении безопасности от 12 октября Docker описал проверку всех преобразований аккаунтов за период действия уязвимости. Компания сопоставила их с журналами реестра и записями о токенах, искала токены, использованные под разными личностями, и проверила каждую отправку образа с перенесённым токеном — около 304 тысяч push-операций. «Мы не нашли доказательств эксплуатации уязвимости», — заявил Docker. По данным компании, все изученные публикации шли в репозитории преобразованной организации или её владельца; в подавляющем большинстве случаев оба аккаунта принадлежали одному человеку или команде. Для случаев, где это подтвердить не удалось, Docker проверил наиболее рискованные публичные образы, не запуская их, и не обнаружил вредоносного кода или подмены.
Эти выводы касаются публикаций образов. В уведомлении Docker не указано, что проверка выявила о скачиваниях или удалениях с перенесённых токенов, в том числе о скачивании приватных репозиториев. Кроме того, журналы реестра фиксируют использование токена, но не факт его существования. Неиспользованный перенесённый токен следов не оставлял, поэтому Docker считал потенциально затронутыми все токены, переданные за период уязвимости, независимо от того, применялись они или нет.
2 октября Docker отправил письма пользователям, чьи аккаунты получили перенесённые токены, и отдельно владельцам затронутых организаций. В письмах перечислялись токены, их описания и даты создания; Docker назвал число получателей ограниченным, но точную цифру не сообщил. Компания утверждает, что пользователи, не получившие письма, не подверглись воздействию уязвимости и никаких действий предпринимать не должны. 8 октября Docker отключил обнаруженные перенесённые токены, кроме тех, которые владельцы попросили сохранить.
Проверить PAT можно в настройках аккаунта: Account settings → Personal access tokens. Для каждого токена там указаны даты создания и последнего использования. Молнар и Хозак советуют обратить внимание на незнакомый токен — его описание мог выбрать кто угодно — и на организацию в переключателе аккаунтов, к которой владелец не помнит, чтобы присоединялся. Docker рекомендует отозвать неизвестные или больше не нужные токены, а для автоматизации организации использовать организационные токены доступа, а не PAT конкретного сотрудника.
Организационные токены доступны подписчикам Docker Team и Docker Business. Ими управляет владелец организации, владелец компании или пользователь с соответствующей пользовательской ролью; такие токены не работают с Docker Desktop и Image Access Management. Владельцы этих тарифов могут проверять прошлые публикации в журналах активности: там записаны отправленные теги и использованный токен. Docker Home хранит журналы 30 дней, более старые записи можно получить через Docker Hub API.
Издатель линтера Docker Compose compose-lint Тодд Матенс сообщил, что 2 октября получил два письма: одно как владелец организации, другое на личный аккаунт. Он заменил два токена, использовавшихся в CI, и проверил подписи всех 42 опубликованных образов, установив, какой запуск CI собрал каждый из них. Такой разбор помогает связать опубликованный артефакт с конкретной сборкой, а не ограничиваться проверкой списка токенов.
Docker описывал перенос токенов в документации примерно 17 месяцев из тех около 25, пока существовала уязвимость. 22 апреля 2025 года на странице преобразования аккаунта появилась заметка: назначение пользователя владельцем организации «обеспечит перенос любых PAT, связанных с аккаунтом этого пользователя, владельцу организации». Docker удалил её 30 сентября, спустя минуты после указанного компанией времени исправления; даты истории документации проверило издание The Hacker News. Теперь Docker требует согласия назначаемого владельца, уведомляет его о назначении, записывает каждое изменение владельца токена и проверяет другие функции, способные менять владельца учётных данных. Этот случай произошёл на фоне атак в марте и апреле: по данным Docker, злоумышленники использовали украденные учётные данные издателей, чтобы разместить вредоносные образы Trivy и KICS в собственных репозиториях этих издателей.
Изображение носит иллюстративный характер
Ошибка возникала при преобразовании личного аккаунта в организацию. Docker Hub не переносит репозиторий между аккаунтами: вместо этого пользователь превращает личную учётную запись в организацию с тем же именем и назначает владельцем существующего аккаунта. С 26 августа 2024 года до 30 сентября 2026-го при такой операции менялась запись о владельце каждого персонального токена доступа (PAT), но его секрет оставался прежним.
PAT используют вместо пароля для доступа к реестру; токен действует с правами, выбранными при создании, и продолжает работать у создавшего его человека. Поэтому схема атаки была короткой: злоумышленник выпускал PAT на контролируемом аккаунте, превращал аккаунт в организацию и указывал владельцем другого пользователя. После этого токен принимался реестром Docker Hub как токен нового владельца. Тот не должен был подтверждать назначение и, по данным Docker и исследователей, не получал уведомления.
При наличии соответствующих прав токен открывал доступ к репозиториям указанного владельца и организациям, которыми тот мог пользоваться. Через него можно было скачивать образы, отправлять новые и удалять существующие. Доступ ограничивался реестром: токен не давал входа в веб-интерфейс Docker Hub и не позволял менять пароль, адрес электронной почты или настройки двухфакторной аутентификации, а значит, не обеспечивал захват аккаунта целиком. Docker назвал уязвимость критической, поскольку она позволяла «публиковать образы под легитимным именем».
О GhostPat сообщили Docker Питер Молнар и Криштиан Хозак с . По словам компании, исправление было развёрнуто менее чем через четыре часа после их сообщения. В техническом разборе исследователи рассказали, что дважды воспроизвели проблему на тестовых аккаунтах с согласия владельцев: вошли в реестр как целевой пользователь, создали репозиторий в его пространстве имён и отправили туда образ, затем опубликовали образ в организации, к которой принадлежал пользователь, и скачали его приватные репозитории.
В уведомлении безопасности от 12 октября Docker описал проверку всех преобразований аккаунтов за период действия уязвимости. Компания сопоставила их с журналами реестра и записями о токенах, искала токены, использованные под разными личностями, и проверила каждую отправку образа с перенесённым токеном — около 304 тысяч push-операций. «Мы не нашли доказательств эксплуатации уязвимости», — заявил Docker. По данным компании, все изученные публикации шли в репозитории преобразованной организации или её владельца; в подавляющем большинстве случаев оба аккаунта принадлежали одному человеку или команде. Для случаев, где это подтвердить не удалось, Docker проверил наиболее рискованные публичные образы, не запуская их, и не обнаружил вредоносного кода или подмены.
Эти выводы касаются публикаций образов. В уведомлении Docker не указано, что проверка выявила о скачиваниях или удалениях с перенесённых токенов, в том числе о скачивании приватных репозиториев. Кроме того, журналы реестра фиксируют использование токена, но не факт его существования. Неиспользованный перенесённый токен следов не оставлял, поэтому Docker считал потенциально затронутыми все токены, переданные за период уязвимости, независимо от того, применялись они или нет.
2 октября Docker отправил письма пользователям, чьи аккаунты получили перенесённые токены, и отдельно владельцам затронутых организаций. В письмах перечислялись токены, их описания и даты создания; Docker назвал число получателей ограниченным, но точную цифру не сообщил. Компания утверждает, что пользователи, не получившие письма, не подверглись воздействию уязвимости и никаких действий предпринимать не должны. 8 октября Docker отключил обнаруженные перенесённые токены, кроме тех, которые владельцы попросили сохранить.
Проверить PAT можно в настройках аккаунта: Account settings → Personal access tokens. Для каждого токена там указаны даты создания и последнего использования. Молнар и Хозак советуют обратить внимание на незнакомый токен — его описание мог выбрать кто угодно — и на организацию в переключателе аккаунтов, к которой владелец не помнит, чтобы присоединялся. Docker рекомендует отозвать неизвестные или больше не нужные токены, а для автоматизации организации использовать организационные токены доступа, а не PAT конкретного сотрудника.
Организационные токены доступны подписчикам Docker Team и Docker Business. Ими управляет владелец организации, владелец компании или пользователь с соответствующей пользовательской ролью; такие токены не работают с Docker Desktop и Image Access Management. Владельцы этих тарифов могут проверять прошлые публикации в журналах активности: там записаны отправленные теги и использованный токен. Docker Home хранит журналы 30 дней, более старые записи можно получить через Docker Hub API.
Издатель линтера Docker Compose compose-lint Тодд Матенс сообщил, что 2 октября получил два письма: одно как владелец организации, другое на личный аккаунт. Он заменил два токена, использовавшихся в CI, и проверил подписи всех 42 опубликованных образов, установив, какой запуск CI собрал каждый из них. Такой разбор помогает связать опубликованный артефакт с конкретной сборкой, а не ограничиваться проверкой списка токенов.
Docker описывал перенос токенов в документации примерно 17 месяцев из тех около 25, пока существовала уязвимость. 22 апреля 2025 года на странице преобразования аккаунта появилась заметка: назначение пользователя владельцем организации «обеспечит перенос любых PAT, связанных с аккаунтом этого пользователя, владельцу организации». Docker удалил её 30 сентября, спустя минуты после указанного компанией времени исправления; даты истории документации проверило издание The Hacker News. Теперь Docker требует согласия назначаемого владельца, уведомляет его о назначении, записывает каждое изменение владельца токена и проверяет другие функции, способные менять владельца учётных данных. Этот случай произошёл на фоне атак в марте и апреле: по данным Docker, злоумышленники использовали украденные учётные данные издателей, чтобы разместить вредоносные образы Trivy и KICS в собственных репозиториях этих издателей.
