Ad
Угрозы

Docker Hub два года позволял выдавать себя за другого пользователя

Маша Даровская
By Маша Даровская , IT-редактор и автор
Docker Hub два года позволял выдавать себя за другого пользователя
Обложка © Anonhaven

В Docker Hub обнаружили критическую уязвимость, которая позволяла злоумышленникам получать доступ к чужим репозиториям контейнерных образов без пароля владельца. Для атаки достаточно было создать собственную учетную запись, выпустить токен доступа и воспользоваться ошибкой при преобразовании личного аккаунта в организацию. После этого Docker Hub мог принять токен злоумышленника за учетные данные другого пользователя.

Уязвимость получила идентификатор CVE-2026-105445 и название GhostPat. Она существовала с 26 августа 2024 года до 30 сентября 2026-го. В зависимости от прав пользователя и разрешений токена атакующий потенциально мог скачивать закрытые контейнерные образы, публиковать новые версии и удалять содержимое репозиториев.

Особую опасность представляла возможность размещать вредоносные образы от имени доверенного разработчика или организации. Такие файлы могли попасть в автоматизированные системы сборки и развертывания приложений, которые регулярно загружают обновления из Docker Hub.

Об ошибке сообщили исследователи Питер Молнар (Peter Molnar) и Кристиан Хожак (Krisztian Hozak) из mptrdev. Docker получила уведомление 30 сентября и устранила уязвимость менее чем за четыре часа.

В официальном сообщении от 12 октября компания подтвердила, что проблема затрагивала механизм управления учетными данными. После исправления специалисты проверили около 304 тысяч операций публикации контейнерных образов, выполненных с затронутыми токенами. Признаков эксплуатации уязвимости обнаружено не было.

Потенциально пострадавших пользователей предупредили, а большинство токенов, перенесенных через уязвимый механизм, отключили.

Как работала уязвимость GhostPat

Docker Hub — облачный реестр контейнерных образов. Разработчики используют его для хранения и распространения приложений, библиотек и готовых программных окружений.

Контейнерный образ содержит файловую систему приложения, его компоненты, зависимости и настройки, необходимые для запуска. Образы хранятся в репозиториях, которые принадлежат отдельным пользователям или организациям.

Например, адрес example/app:latest указывает на образ app в пространстве имен example. Тег latest обозначает версию, которую владелец репозитория связал с этим именем.

Docker Hub позволяет преобразовать личную учетную запись в организацию. Такая возможность используется, когда разработчик передает проект команде или хочет управлять репозиториями совместно с коллегами.

При преобразовании сохраняется прежнее имя пространства репозиториев. Поэтому пользователям, которые уже скачивают образы по существующим адресам, не требуется менять команды загрузки.

Для завершения операции необходимо выбрать существующую учетную запись Docker Hub, которая станет владельцем новой организации.

До 30 сентября 2026 года вместе с изменением владельца система переносила и персональные токены доступа, созданные в преобразуемом аккаунте.

Персональный токен доступа, или Personal Access Token (PAT), — секретное значение, которое позволяет программам обращаться к Docker Hub без постоянного ввода пароля. Такие токены используют при работе через командную строку, в сценариях автоматизации и системах непрерывной интеграции и доставки программного обеспечения (CI/CD).

У токена есть разрешения, определяющие доступные операции. Он может использоваться для скачивания контейнерных образов, публикации новых версий или удаления содержимого репозиториев.

При преобразовании аккаунта Docker Hub менял запись о владельце токена, но не отзывал его и не создавал новое секретное значение.

В результате токен, выпущенный одним пользователем, начинал действовать от имени другого. При этом человек, который первоначально создал токен, продолжал знать его секретное значение.

Система не требовала согласия нового владельца организации и не отправляла ему уведомление о переносе учетных данных.

Как злоумышленник мог получить доступ к чужому репозиторию

Исследователи описали сценарий атаки, для которого не требовалось взламывать учетную запись жертвы.

Сначала атакующий создавал собственный аккаунт Docker Hub и выпускал персональный токен доступа с нужными разрешениями.

Затем он преобразовывал аккаунт в организацию. В качестве нового владельца указывалось имя другого пользователя Docker Hub, к репозиториям которого преступник хотел получить доступ.

При завершении операции система переносила токен новому владельцу. Однако секретное значение оставалось прежним и было известно атакующему.

После этого токен можно было использовать для обращения к реестру контейнерных образов от имени выбранного пользователя.

Сервис проверял действительность токена и предоставлял доступ к операциям в пределах его разрешений и прав учетной записи, которой он теперь принадлежал.

Например, если выбранный пользователь мог публиковать образы в репозитории своей организации, перенесенный токен с разрешением на запись потенциально позволял выполнять аналогичные действия.

В результате злоумышленник мог получить доступ к ресурсам, к которым его собственная учетная запись отношения не имела.

Подробности механизма исследователи опубликовали в техническом разборе GhostPat.

Главная особенность атаки заключалась в том, что злоумышленнику не требовалось похищать существующий токен у жертвы. Он создавал собственный, после чего ошибка Docker Hub позволяла использовать его с правами другого пользователя.

При этом GhostPat не предоставляла полный контроль над учетной записью. Через уязвимый токен нельзя было войти в веб-интерфейс Docker Hub, изменить пароль, адрес электронной почты или настройки двухфакторной аутентификации.

Уязвимость затрагивала прежде всего авторизацию при работе с реестром контейнерных образов. Однако для компрометации репозитория такого доступа могло оказаться достаточно.

Злоумышленники могли подменять доверенные контейнерные образы

Возможность публиковать образы от чужого имени создавала угрозу для цепочки поставки программного обеспечения.

Многие разработчики и компании используют Docker Hub как источник готовых компонентов. Образы скачиваются вручную либо автоматически во время сборки и развертывания приложений.

Если злоумышленник получает право записи в репозиторий, которому доверяют другие пользователи, он потенциально может разместить там измененный контейнерный образ.

Такой образ способен содержать посторонний исполняемый код, вредоносный компонент или программу для кражи учетных данных.

Опасность возрастает, когда организация использует автоматизированное развертывание и регулярно загружает образы по одному адресу.

Допустим, система получает приложение из репозитория company/backend:latest. Если атакующий имеет право обновлять этот репозиторий, он может связать тег latest с измененным образом.

При следующей загрузке система получит версию, на которую указывает тег в данный момент.

Сам адрес репозитория останется прежним, что усложнит обнаружение подмены при проверке только имени издателя.

Однако публикация вредоносного образа не означает автоматического заражения пользователей. Для этого измененный контейнер должен быть загружен и запущен. Проверка содержимого, использование цифровых подписей и закрепление конкретных образов по их криптографическим дайджестам помогают снизить риск.

Дайджест — уникальный идентификатор содержимого образа, рассчитываемый с помощью криптографической хеш-функции. Если содержимое изменится, изменится и его дайджест.

Поэтому при развертывании критически важных приложений безопаснее проверять конкретную версию образа, а не полагаться исключительно на изменяемый тег.

CVE-2026-105445 создавала условия для подобных атак, но подтвержденных случаев подмены образов через GhostPat нет.

Почему угроза для CI/CD оказалась серьезной

Системы CI/CD автоматически выполняют сборку, тестирование и публикацию программного обеспечения.

При работе с Docker Hub они используют токены доступа для скачивания зависимостей и загрузки новых контейнерных образов.

Если злоумышленник получает право изменять содержимое доверенного репозитория, вредоносный образ может попасть в следующие сборки или развертывания.

При этом разработчикам не обязательно напрямую взаимодействовать с атакующим. Достаточно, чтобы автоматизированный процесс продолжал загружать образ из скомпрометированного репозитория.

Подобные атаки уже происходили с другими инструментами.

В марте 2026 года злоумышленники атаковали Trivy — популярный сканер уязвимостей контейнеров и программных компонентов, разработанный Aqua Security.

Преступники получили доступ к инфраструктуре публикации и распространили вредоносные версии инструмента. Атака затронула GitHub и Docker Hub.

Как сообщало BleepingComputer, исследователи обнаружили подозрительные контейнерные образы Trivy с тегами 0.69.5 и 0.69.6, которым не соответствовали официальные выпуски проекта.

Этот инцидент не связан с GhostPat. Однако он показывает, чем опасна возможность публиковать измененные образы через доверенные учетные записи.

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

Docker проверила 304 тысячи операций публикации

После получения сообщения об уязвимости команда безопасности Docker начала проверять механизм преобразования аккаунтов.

30 сентября 2026 года в 11:40 по времени восточного побережья США специалисты получили отчет исследователей.

Около 13:30 инженеры самостоятельно воспроизвели ошибку на тестовых учетных записях. К 15:10 исправление уже было установлено в рабочей инфраструктуре Docker Hub.

Таким образом, от сообщения об уязвимости до ее устранения прошло примерно три с половиной часа.

После этого компания начала проверку всех преобразований учетных записей, выполненных с 26 августа 2024 года, когда появился уязвимый механизм переноса токенов.

Специалисты сопоставили сведения о владельцах аккаунтов, записи об авторизации в реестре, операции с контейнерными образами и историю токенов.

Отдельно проверили около 304 тысяч операций публикации образов, выполненных с токенами, которые переносились при преобразовании учетных записей.

Ни одна из этих операций не привела к публикации образа в репозитории постороннего пользователя или организации.

Все проверенные публикации относились к репозиториям преобразованной организации либо нового владельца учетной записи.

В большинстве случаев аккаунт, который преобразовывался в организацию, и учетная запись ее нового владельца принадлежали одному человеку или одной команде. Такой сценарий соответствует обычному использованию функции Docker Hub.

Дополнительно инженеры изучили наиболее рискованные общедоступные образы, опубликованные после преобразования аккаунтов, когда не удалось подтвердить, что обе учетные записи контролировал один владелец.

Для проверки применялся статический анализ — исследование содержимого файлов без запуска контейнеров.

Специалисты искали вредоносное ПО, майнеры криптовалют, программы для кражи учетных данных, механизмы сохранения скрытого доступа и признаки вмешательства в опубликованные файлы. Подозрительных изменений не обнаружили. Docker также не нашла свидетельств компрометации собственной инфраструктуры через GhostPat.

Компания не раскрыла точное количество учетных записей, которым ошибочно передавались токены.

Затронутые токены отключили 8 октября

2 октября Docker отправила уведомления пользователям, чьи учетные записи могли получить токены через уязвимый механизм.

В письме с темой Docker Hub Vulnerability Identified & Resolved перечислялись затронутые токены, включая их названия и даты создания.

Владельцы соответствующих организаций получили отдельные уведомления.

8 октября компания принудительно отключила выявленные токены.

Исключение сделали для владельцев, которые заранее запросили сохранение их активности. Поэтому утверждать, что абсолютно все когда-либо перенесенные токены были аннулированы, нельзя.

Docker также изменила процедуру преобразования личных аккаунтов в организации. Теперь персональные токены прежнего аккаунта не передаются новому владельцу. После преобразования такие токены перестают действовать, а необходимые учетные данные требуется создать заново. Это исключает повторение ошибки в прежнем виде.

Компания также сообщила о дополнительных изменениях в системе управления доступом. В частности, предусмотрено обязательное согласие пользователя перед назначением его владельцем организации и ведение проверяемой истории изменений принадлежности токенов.

Docker намерена проверить и другие процедуры передачи учетных данных, чтобы выявить возможные ошибки аналогичного характера.

Уязвимость CVE-2026-105445 существовала чуть больше двух лет. Причиной стала ошибка в обработке токенов при передаче управления учетной записью.

Docker Hub корректно изменял владельца организации, но вместе с этим передавал ему персональные токены, сохраняя прежние секретные значения.

Из-за этого человек, создавший токен, мог продолжать им пользоваться уже с правами другого пользователя.

Отсутствие обязательного подтверждения со стороны нового владельца позволяло провести такую операцию без его ведома.

Для эксплуатации не требовалось подбирать пароли, обходить двухфакторную аутентификацию или взламывать инфраструктуру Docker. Достаточно было воспользоваться ошибкой в предусмотренной сервисом процедуре преобразования аккаунта.

К 13 октября 2026 года уязвимость закрыта, потенциально затронутые пользователи уведомлены, а большинство перенесенных токенов отключено. Подтвержденных случаев злоупотребления GhostPat нет.

Вопросы и ответы (FAQ)

Что такое GhostPat?

GhostPat — критическая уязвимость Docker Hub с идентификатором CVE-2026-105445. Она позволяла переносить персональный токен доступа на учетную запись другого пользователя без изменения секретного значения. В результате первоначальный владелец токена мог обращаться к реестру с правами нового владельца.

Могли ли злоумышленники изменять чужие Docker-образы?

Да, такая возможность существовала при наличии соответствующих разрешений. Атакующий потенциально мог скачивать закрытые образы, публиковать новые версии и удалять содержимое доступных репозиториев.

Можно ли было полностью захватить учетную запись Docker Hub?

Нет. Уязвимость позволяла выдавать себя за пользователя при обращении к реестру контейнерных образов, но не предоставляла доступ к веб-интерфейсу и настройкам аккаунта. Изменить пароль, почту или двухфакторную аутентификацию через перенесенный токен было нельзя.

Когда появилась уязвимость CVE-2026-105445?

Проблема существовала с 26 августа 2024 года. Docker устранила ее 30 сентября 2026 года, менее чем через четыре часа после получения сообщения исследователей.

Использовали ли хакеры GhostPat в реальных атаках?

Подтвержденных случаев нет. Docker проверила около 304 тысяч операций публикации образов и изучила наиболее рискованные общедоступные файлы. Признаков злоупотребления обнаружено не было.

Сколько пользователей пострадало?

Точное количество публично не раскрыто. Docker сообщила, что уведомила пользователей, чьи учетные записи могли получить токены через уязвимую процедуру преобразования.

Нужно ли менять пароль Docker Hub?

Массовая смена паролей из-за GhostPat не требуется. Ошибка затрагивала токены доступа, а не пароли пользователей. Владельцам затронутых учетных записей рекомендуется проверить токены и заменить те, которые больше не должны использоваться.

Как проверить токены Docker Hub?

Войдите в настройки учетной записи Docker Hub и откройте раздел Personal access tokens. Там можно посмотреть список токенов, их разрешения, статус и время последнего использования. Неизвестные или ненужные токены следует удалить.

Чем PAT отличается от OAT?

PAT — персональный токен, связанный с учетной записью конкретного пользователя. OAT — токен организации, предназначенный для централизованного управления доступом и автоматизированных процессов, включая CI/CD.

Могла ли GhostPat затронуть официальные образы Docker?

Публикация вредоносных образов от доверенного имени рассматривалась как возможный сценарий атаки. Однако подтверждений подмены официальных образов через GhostPat нет. Исследователи не установили, что механизм публикации таких образов был доступен для эксплуатации описанным способом.

Есть новость? Станьте автором.

Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.