Wprowadzenie do problemu / definicja
Docker usunął krytyczną podatność w Docker Hub, która mogła umożliwić wykonywanie operacji na obrazach kontenerów z uprawnieniami innego użytkownika. Problem dotyczył sposobu obsługi personal access tokenów podczas konwersji konta osobistego do organizacji, co czyni go szczególnie istotnym z perspektywy bezpieczeństwa łańcucha dostaw oprogramowania.
W skrócie
Podatność oznaczona jako CVE-2026-105445 otrzymała ocenę krytyczną oraz wynik CVSS 4.0 na poziomie 9,4. Błąd istniał od 26 sierpnia 2024 r. do 30 września 2026 r. i pozwalał zachować aktywność tokenu PAT po zmianie własności konta w procesie przekształcania go w organizację.
W praktyce mogło to umożliwić atakującemu publikowanie, pobieranie lub usuwanie obrazów jako inny użytkownik, bez przejmowania jego hasła czy dostępu do interfejsu webowego. Docker poinformował, że po zgłoszeniu szybko wdrożył poprawkę i nie odnotował dowodów aktywnego wykorzystania luki.
Kontekst / historia
Źródłem problemu był mechanizm konwersji konta osobistego do organizacji, wykorzystywany m.in. wtedy, gdy użytkownik chciał zachować ten sam namespace dla repozytoriów. W trakcie takiego procesu należało wskazać istniejące konto jako właściciela nowej organizacji.
Badacze bezpieczeństwa wykazali, że wcześniej utworzone tokeny PAT mogły po konwersji zmienić przypisanego właściciela logicznego, ale nadal pozostawały aktywne z tym samym sekretem. To otwierało drogę do nadużycia, w którym napastnik tworzył własne konto, generował token, a następnie konwertował konto do organizacji i przypisywał je ofierze jako właścicielowi. W rezultacie token pozostawał pod kontrolą atakującego, lecz backend rejestru traktował go jak poświadczenie ofiary.
Luka została zgłoszona odpowiedzialnie i otrzymała nazwę GhostPat. Docker podał, że poprawka trafiła do środowiska produkcyjnego w mniej niż cztery godziny od zgłoszenia, po czym rozpoczęto analizę wcześniejszych konwersji kont oraz aktywności związanej z tokenami.
Analiza techniczna
Sedno problemu polegało na rozdzieleniu sekretu tokenu PAT od tożsamości właściciela. W podatnym modelu konwersja konta zmieniała przypisanie właściciela tokenu, ale nie powodowała jego unieważnienia ani regeneracji wartości kryptograficznej.
Powodowało to sytuację typu identity confusion. Token wygenerowany przez atakującego mógł po konwersji działać jako ważne poświadczenie przypisane do innego użytkownika lub organizacji. W praktyce oznaczało to możliwość wykonywania operacji na poziomie rejestru obrazów bez potrzeby przejęcia pełnego konta ofiary.
- publikowania obrazów pod zaufaną nazwą,
- nadpisywania istniejących tagów,
- usuwania obrazów z repozytoriów,
- pobierania prywatnych obrazów w zakresie przyznanych uprawnień,
- potencjalnego oddziaływania na organizacje, do których ofiara miała dostęp.
Według dostępnych informacji luka nie umożliwiała zmiany hasła, adresu e-mail, ustawień MFA ani przejęcia dostępu do panelu webowego. Mimo to jej wpływ był bardzo poważny, ponieważ atak na warstwę rejestru obrazów może bezpośrednio przełożyć się na kompromitację pipeline’ów CI/CD, środowisk testowych i produkcyjnych oraz szerzej całego łańcucha dostaw.
Docker przeanalizował historyczne konwersje wykonane w okresie ekspozycji, a także logi rejestru i rekordy tokenów. Firma sprawdziła przypadki użycia tokenów pod więcej niż jedną tożsamością oraz przejrzała około 304 tysięcy operacji push wykonanych z użyciem przeniesionych tokenów. W części przypadków przeprowadzono również dodatkową analizę publicznych obrazów pod kątem potencjalnych złośliwych modyfikacji.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko wynikało z możliwości publikacji spreparowanych obrazów pod legalną i rozpoznawalną nazwą. Dla organizacji automatycznie pobierających obrazy z zaufanych namespace’ów oznacza to realne zagrożenie atakiem supply chain, w tym wdrożeniem backdoorów, malware, cryptominerów lub komponentów kradnących dane.
- kompromitacja pipeline’ów budujących i wdrażających kontenery,
- naruszenie integralności oficjalnych lub wewnętrznych obrazów,
- nieautoryzowany dostęp do prywatnych repozytoriów obrazów,
- sabotaż poprzez usuwanie lub nadpisywanie tagów,
- spadek zaufania do mechanizmów podpisywania i potwierdzania pochodzenia artefaktów.
Szczególnie narażone były organizacje wykorzystujące osobiste tokeny użytkowników w automatyzacji zamiast dedykowanych tokenów organizacyjnych i ścisłej segmentacji uprawnień. Nawet bez pełnego przejęcia konta taki scenariusz mógł prowadzić do incydentu o wysokiej skali operacyjnej i biznesowej.
Rekomendacje
Incydent powinien skłonić organizacje korzystające z Docker Hub do przeglądu praktyk związanych z zarządzaniem tożsamością, tokenami i integralnością artefaktów kontenerowych.
- przeprowadzić audyt wszystkich aktywnych tokenów PAT,
- unieważnić tokeny nieznanego pochodzenia, nieużywane lub zbędne,
- rotować tokeny używane w CI/CD i automatyzacji,
- zweryfikować historię push, pull i usuwania obrazów,
- sprawdzić, czy na kontach nie pojawiły się nieoczekiwane organizacje lub zmiany właścicielskie,
- zastąpić osobiste PAT-y tokenami organizacyjnymi tam, gdzie to możliwe,
- wdrożyć zasadę najmniejszych uprawnień,
- stosować podpisywanie obrazów, attestation i walidację provenance,
- utrzymywać niezależne skanowanie obrazów pod kątem złośliwego kodu i nieautoryzowanych zmian,
- monitorować nietypowe publikacje tagów oraz usunięcia obrazów.
Dobrą praktyką pozostaje również rozdzielenie tożsamości deweloperskich od tożsamości automatyzacji. Procesy CI/CD nie powinny opierać się na osobistych sekretach użytkowników, ponieważ utrudnia to audyt, zwiększa ryzyko nadużyć i komplikuje reakcję na incydenty.
Podsumowanie
CVE-2026-105445 pokazuje, że krytyczne zagrożenia w ekosystemie kontenerowym mogą wynikać nie tylko z błędów w samym silniku, ale także z logiki zarządzania tożsamością i poświadczeniami w rejestrze obrazów. Luka GhostPat nie prowadziła do klasycznego przejęcia konta, jednak umożliwiała wykonywanie operacji na obrazach jako inny użytkownik, co tworzyło poważne ryzyko dla software supply chain.
Szybkie wdrożenie poprawki przez Docker ograniczyło ryzyko po zgłoszeniu, ale długi okres istnienia błędu pokazuje, jak ważne są regularne przeglądy mechanizmów IAM, tokenów dostępowych oraz kontroli integralności publikowanych artefaktów.