Docker Hub CVE-2026-105445: tokeny po konwersji konta

12 października Docker opisał CVE-2026-105445 w Docker Hub. Firma wdrożyła poprawkę po stronie usługi 30 września i poinformowała, że nie znalazła dowodów wykorzystania błędu. To wynik przeglądu dostawcy. Źródło: komunikat bezpieczeństwa Docker.

Rekord CVE opublikowany przez Docker opisuje nieprawidłowe przypisanie uprawnień przy konwersji konta na organizację. Token PAT mógł otrzymać właściciela będącego innym użytkownikiem, zachowując dotychczasowy sekret. W granicach swoich uprawnień umożliwiał następnie pobieranie, publikowanie lub usuwanie obrazów jako ten użytkownik.

Wniosek Breachroad: właściciele kont objętych komunikatem powinni ustalić, jakie tokeny i procesy były z nimi związane. Zespoły publikujące obrazy potrzebują również jasnego zapisu, kto odpowiada za uprawnienia automatyzacji i jak potwierdza się pochodzenie artefaktu. Poniższy plan przeglądu jest naszą rekomendacją.

Najpierw zakres powiadomienia

Docker wskazuje, że 2 października powiadomił narażonych użytkowników i właścicieli organizacji. Według dostawcy osoby, które nie otrzymały tego powiadomienia, nie były narażone przez ten mechanizm i nie mają działań do wykonania w związku z tym CVE.

Zalecamy, aby odbiorca firmowego powiadomienia przypisał je do właściwego konta i organizacji oraz zachował zakres wskazany przez dostawcę. Jeśli treść budzi wątpliwości, zweryfikuj sprawę przez znany kanał wsparcia i właściciela usługi. Nie przenoś ustaleń dotyczących jednego konta automatycznie na cały rejestr firmowy.

Rekord CVE oznacza problem jako dotyczący wyłącznie usługi hostowanej. W naszej ocenie zadanie związane z tym komunikatem powinno więc skupiać się na koncie, tokenach i dostępnych zapisach. Aktualizacja lokalnego silnika kontenerów nie stanowi dowodu wykonania tych ustaleń.

Token potrzebuje właściciela biznesowego i technicznego

W naszym planie przegląd automatyzacji odpowiada na cztery pytania:

1. Jaki proces korzysta z uprawnienia? Wskaż pipeline, harmonogram lub integrację oraz środowisko, w którym działa. Sama nazwa tokenu nie wyjaśnia tego powiązania.
2. Kto zatwierdził dostęp? Ustal opiekuna konta i osobę odpowiedzialną za publikowane obrazy. Zapis powinien przetrwać zmianę pracownika lub zespołu.
3. Jakie działania są potrzebne? Rozróżnij odczyt, publikację i usuwanie oraz zakres repozytoriów. Przyznanie dostępu powinno odpowiadać rzeczywistemu zadaniu.
4. Jak kończy się użycie? Określ warunki wycofania uprawnienia, sposób zmiany sekretu i potwierdzenie działania zależnego procesu.

To ogólny przegląd higieny dostępu, który można przeprowadzać także poza obsługą tego CVE. Nie oznacza, że wszystkie tokeny lub wszystkie obrazy Docker Hub zostały naruszone.

Zmiana sekretu powinna mieć sprawdzony wynik

Jeżeli zakres powiadomienia lub firmowa decyzja wymaga zmiany tokenu, zalecamy ustalić kolejność z właścicielem pipeline’u. Trzeba wiedzieć, gdzie znajduje się powiązane poświadczenie, kto aktualizuje konfigurację i jak sprawdzi zakończenie procesu.

Po zmianie zapisz potwierdzenie wymaganej funkcji oraz wycofania wcześniejszego uprawnienia zgodnie z ustalonym planem. Zachowaj identyfikatory i wyniki kontroli, bez umieszczania wartości sekretów w zgłoszeniu. Sam komunikat o udanej zmianie jednego wpisu nie opisuje wszystkich zależnych integracji.

Pochodzenie obrazu wymaga dowodów

Proponujemy powiązać zatwierdzone publikacje z procesem budowania, identyfikatorem artefaktu i dostępnym zapisem działania. Nazwa repozytorium lub tag opisuje miejsce i etykietę publikacji; właściciel wydania potrzebuje również dowodu, jaki wynik procesu został dopuszczony do użycia.

Przy nieoczekiwanej publikacji uruchom ustaloną obsługę incydentu. Zachowaj dostępne logi, porównaj zakres uprawnień i ustal, które środowiska mogły użyć danego artefaktu. Nie zakładaj, że późniejsza zmiana tokenu wyjaśnia całą wcześniejszą historię.

Scenariusz szkoleniowy dla zespołu CI/CD

Firma używa tokenu dawnego pracownika, ale nikt nie potrafi wskazać wszystkich pipeline’ów, które od niego zależą. To hipotetyczny przykład do dyskusji, nie opis ofiary tego CVE.

Poproś uczestników o ustalenie właściciela, potrzebnego zakresu dostępu i dowodu poprawnej zmiany. Celem jest przećwiczenie odpowiedzialności za publikację oraz kontroli nad poświadczeniami automatyzacji.

Więcej o tych granicach znajdziesz w przewodniku po bezpieczeństwie CI/CD. Zespoły developerskie i administratorzy mogą omówić podobne scenariusze podczas szkoleń z cyberbezpieczeństwa dla organizacji.