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 і перейти на організаційні токени для будь-якої автоматизації, повʼязаної з організаціями. Для споживачів публічних образів інцидент підкреслює цінність верифікації підписів образів: саме підпис, а не імʼя видавця, лишається надійним індикатором цілісності в екосистемі реєстрів контейнерів.
