Wprowadzenie do problemu / definicja
Docker usunął krytyczną podatność w Docker Hub, która mogła umożliwić wykonywanie operacji na obrazach kontenerowych z uprawnieniami innego użytkownika. Problem dotyczył mechanizmu konwersji konta osobistego do organizacji oraz sposobu obsługi tokenów dostępowych używanych do uwierzytelniania w rejestrze.
Luka została oznaczona jako CVE-2026-105445 i miała szczególne znaczenie dla bezpieczeństwa łańcucha dostaw oprogramowania. W określonych warunkach atakujący mógł zachować aktywny token, który po zmianie własności konta działał już w kontekście innego właściciela.
W skrócie
Podatność istniała od 26 sierpnia 2024 roku do 30 września 2026 roku i została sklasyfikowana jako krytyczna. Scenariusz ataku polegał na utworzeniu tokenu na koncie osobistym, przekształceniu tego konta w organizację oraz przypisaniu innego użytkownika jako właściciela.
- atakujący zachowywał sekret wcześniej utworzonego tokenu,
- token pozostawał aktywny po konwersji konta,
- operacje w rejestrze mogły być wykonywane z tożsamością nowego właściciela,
- możliwe było pobieranie, publikowanie i usuwanie obrazów w zakresie dostępnych uprawnień.
Docker poinformował, że nie znalazł dowodów na aktywne wykorzystanie tej luki, ale sam potencjalny wpływ na integralność obrazów kontenerowych był bardzo poważny.
Kontekst / historia
Funkcja konwersji konta osobistego do organizacji w Docker Hub ma znaczenie operacyjne, ponieważ pozwala zachować tę samą nazwę przestrzeni i ułatwia przeniesienie odpowiedzialności za repozytoria na zespół lub firmę. W praktyce jest to przydatne przy zmianie modelu zarządzania projektami i publikacją obrazów.
Problem polegał jednak na tym, że mechanizm migracji nie wymuszał skutecznego unieważnienia sekretu tokenu po zmianie kontekstu własnościowego. To sprawiło, że błąd administracyjny przerodził się w istotny problem bezpieczeństwa dotyczący publikacji artefaktów w zaufanej przestrzeni nazw.
Choć poprawka została wdrożona po zgłoszeniu przez badaczy bezpieczeństwa, luka pozostawała obecna przez ponad dwa lata. Taki horyzont czasowy zwiększa wagę zagrożenia, zwłaszcza w środowiskach intensywnie korzystających z automatyzacji CI/CD.
Analiza techniczna
Źródłem problemu był sposób obsługi personal access tokens, czyli tokenów używanych zamiast hasła do autoryzacji operacji w rejestrze obrazów. W podatnym scenariuszu użytkownik tworzył token na własnym koncie, a następnie przekształcał konto w organizację i wskazywał innego użytkownika jako właściciela tej organizacji.
Błąd polegał na tym, że zapis własności tokenu ulegał zmianie, ale sam sekret tokenu nie był unieważniany. W efekcie atakujący nadal posiadał ważne dane uwierzytelniające, które umożliwiały komunikację z rejestrem, już jednak z uprawnieniami przypisanymi nowemu właścicielowi.
Zakres podatności nie obejmował pełnego przejęcia konta przez interfejs webowy. Nie chodziło o zmianę hasła, adresu e-mail czy ustawień MFA, lecz o warstwę registry, czyli ten obszar, który bezpośrednio odpowiada za pobieranie i publikowanie obrazów kontenerowych.
- pobieranie prywatnych obrazów,
- publikowanie nowych obrazów,
- nadpisywanie istniejących tagów,
- usuwanie obrazów zgodnie z przypisanymi uprawnieniami,
- wykonywanie operacji w repozytoriach oraz organizacjach dostępnych dla właściciela.
Najbardziej niebezpieczny był scenariusz publikacji obrazu pod zaufaną nazwą. W praktyce mógł on prowadzić do podmiany artefaktów, zatruwania pipeline’ów buildowych oraz dystrybucji złośliwych kontenerów przez repozytoria wyglądające na legalne.
Konsekwencje / ryzyko
Ryzyko związane z tą luką należy analizować przede wszystkim przez pryzmat bezpieczeństwa łańcucha dostaw. Docker Hub jest dla wielu organizacji centralnym elementem procesu dostarczania aplikacji, a zaufanie do publikowanych obrazów bywa podstawą automatycznych wdrożeń.
Jeżeli atakujący może opublikować obraz jako wiarygodny wydawca, konsekwencje mogą wykraczać poza pojedyncze repozytorium. Zagrożone stają się środowiska testowe, produkcyjne oraz klastry Kubernetes automatycznie pobierające najnowsze artefakty.
- dystrybucja trojanizowanych obrazów kontenerowych,
- naruszenie integralności pipeline’ów CI/CD,
- nieautoryzowany dostęp do prywatnych repozytoriów,
- sabotaż poprzez usuwanie artefaktów,
- utrata zaufania do namespace’u wydawcy i procesu publikacji.
Brak potwierdzonych przypadków eksploatacji nie oznacza automatycznie, że ryzyko historyczne było niskie. W wielu środowiskach pełna retrospektywna analiza aktywności tokenów może być utrudniona, zwłaszcza gdy logowanie operacji nie obejmowało wszystkich istotnych zdarzeń.
Rekomendacje
Zespoły bezpieczeństwa, DevOps i administratorzy powinni potraktować ten incydent jako sygnał do przeglądu modelu zarządzania tożsamością techniczną w rejestrze obrazów.
- przeprowadzić audyt wszystkich tokenów dostępowych i usunąć te o niejasnym pochodzeniu lub przeznaczeniu,
- dokonać rotacji tokenów wykorzystywanych w automatyzacji CI/CD,
- unikać używania osobistych tokenów do procesów należących faktycznie do organizacji,
- wdrażać tokeny organizacyjne i rozdzielać tożsamości osobiste od technicznych,
- przeanalizować historię publikacji obrazów pod kątem nietypowych pushów i zmian tagów,
- weryfikować zgodność digestów, podpisów i wdrożonych artefaktów,
- wzmacniać polityki dopuszczania obrazów, podpisywanie artefaktów oraz skanowanie przed wdrożeniem,
- upewnić się, że konta właścicieli organizacji są objęte MFA, monitoringiem aktywności i kontrolą uprawnień.
Szczególną uwagę powinny zwrócić organizacje, które automatycznie pobierają obrazy do środowisk produkcyjnych. W takich przypadkach każda nieprawidłowość w procesie publikacji może bezpośrednio przełożyć się na wdrożenie złośliwego lub zmodyfikowanego komponentu.
Podsumowanie
Usunięta luka w Docker Hub pokazuje, że nawet funkcja o charakterze administracyjnym może stać się wektorem poważnego ataku na łańcuch dostaw. Kluczowym błędem było zachowanie ważności sekretu tokenu po zmianie kontekstu własności, co umożliwiało wykonywanie operacji na obrazach jako inny użytkownik.
Mimo braku potwierdzonej eksploatacji potencjalny wpływ tej podatności był wysoki. Dla organizacji korzystających z Docker Hub to wyraźne ostrzeżenie, aby ograniczać użycie osobistych tokenów, wzmacniać kontrolę nad rejestrem obrazów i regularnie audytować procesy publikacji artefaktów.