Dokploy: 35 CVE odsłania ryzyko panelu sterującego wdrożeniami

10 sierpnia 2026 roku bazy podatności opublikowały 35 rekordów CVE dotyczących Dokploy, platformy do samodzielnego wdrażania aplikacji i baz danych na serwerach oraz klastrach Docker Swarm. Seria obejmuje między innymi wstrzyknięcia poleceń systemowych, pomijanie granic organizacji, niebezpieczną obsługę ścieżek i braki autoryzacji w funkcjach administracyjnych. Wiele ocen otrzymało 9,9 w CVSS 3.1, ale nie oznacza to jednego, nieuwierzytelnionego exploita działającego w każdej instalacji. Poszczególne luki mają inne warunki i często wymagają konta o niskich uprawnieniach albo dostępu do konkretnego projektu.

Najważniejsza wiadomość operacyjna jest prostsza: administratorzy powinni sprawdzić, czy używają co najmniej wersji 0.29.13, której wydanie zawiera zbiorczy zestaw poprawek. Sam fakt, że CVE opublikowano później, nie oznacza, że trzeba czekać na nowy pakiet. W tym przypadku poprawki poprzedziły skoordynowane ujawnienie. Organizacja musi jednak potwierdzić wdrożony artefakt, dostępność panelu, konta użytkowników oraz potencjalne ślady nadużycia sprzed aktualizacji.

Co właściwie zawiera seria 35 CVE

Dokploy jest control plane’em: przyjmuje dane uwierzytelniające do rejestrów i dostawców Git, tworzy konfiguracje Dockera i Traefika, uruchamia zadania kopii zapasowych, zarządza terminalami WebSocket oraz planuje wdrożenia. Właśnie dlatego pojedynczy błąd ma większy promień rażenia niż w zwykłym panelu treści. Proces może dysponować prawem do uruchamiania kontenerów, zapisu plików konfiguracyjnych, kontaktu z API chmury i odczytu sekretów.

Rekordy takie jak CVE-2026-72733 opisują wstrzyknięcie poleceń w przepływach kopii zapasowej i odtwarzania. Inne dotyczą klonowania repozytoriów z różnych dostawców Git, generowania konfiguracji Traefika, nazw obrazów lub ścieżek Docker Compose. CVE-2026-72863 należy do grupy problemów z przekraczaniem granic autoryzacji, natomiast kolejne rekordy obejmują terminale, harmonogramy, certyfikaty, rejestry i funkcje Swarm. Pełna lista ma sens jako inwentarz napraw, lecz sama liczba nie wyjaśnia architektury ryzyka.

Wspólny wzorzec jest dwojaki. Po pierwsze, dane kontrolowane przez użytkownika trafiały do operacji o skutkach systemowych bez dostatecznego rozdzielenia danych od poleceń. Po drugie, nie wszystkie procedury konsekwentnie sprawdzały, czy użytkownik należący do jednej organizacji może działać na wskazanym zasobie. Control plane musi egzekwować oba typy granic: składniową granicę między wartością a kodem oraz biznesową granicę między tenantami.

Dlaczego 9,9 nie znaczy „bez logowania”

W wielu rekordach wektor CVSS zakłada niskie wymagane uprawnienia i zmianę zakresu wpływu. To dobrze pasuje do sytuacji, w której zwykły użytkownik panelu może doprowadzić do wykonania kodu na hoście albo dotknąć zasobów innej organizacji. CVSS 9,9 mówi, że po spełnieniu tych warunków wpływ może być krytyczny; nie mówi, że panel da się przejąć anonimowo z Internetu.

To rozróżnienie zmienia detekcję. Zespół nie powinien szukać wyłącznie błędnych logowań z obcych adresów. Trzeba przejrzeć aktywność istniejących kont, zaproszenia do organizacji, zmiany ról, nietypowe nazwy gałęzi, repozytoriów, usług, ścieżek i zadań backupu. Jeżeli konto dewelopera zostało wcześniej przejęte, legalna sesja mogła stać się punktem wejścia do wrażliwej funkcji.

Nie ma też podstaw, by każdą instalację uznać za naruszoną. Publiczne rekordy potwierdzają klasy podatności i wersje, a nie powszechną kampanię. Breachroad wnioskuje jednak, że ekspozycja panelu i liczba niezaufanych użytkowników powinny wpływać na priorytet dochodzenia równie mocno jak sam numer wersji.

Co naprawia 0.29.13

Informacje o wydaniu Dokploy 0.29.13 wymieniają obszerny pakiet zmian bezpieczeństwa. Obejmują one między innymi command injection przy klonowaniu repozytoriów u wielu dostawców, ujawnianie poświadczeń przez błędy dostępu między organizacjami i twardszą walidację operacji administracyjnych. Część wcześniejszych problemów usunięto już w 0.29.8, ale 0.29.13 jest praktycznym punktem odniesienia dla tej fali ujawnień.

Nie wystarczy porównać numer zapisany w dokumencie CMDB. Sprawdź wersję działającego kontenera lub obrazu, jego digest, datę ostatniego wdrożenia i wszystkie repliki. W środowisku z ręcznym pinowaniem tag mógł zostać zaktualizowany w rejestrze, lecz stary digest nadal działać. W środowisku wysokiej dostępności jedna zapomniana replika może wciąż obsługiwać żądania.

Aktualizacja powinna odbyć się według instrukcji projektu i po wykonaniu zweryfikowanej kopii danych. Control plane zarządza produkcją, więc chaotyczny restart może przerwać wdrożenia lub zadania. Kopia nie może jednak trafiać do tego samego niezabezpieczonego miejsca ani wymagać uruchomienia podatnej funkcji w sposób zwiększający ekspozycję. Najpierw ogranicz dostęp sieciowy, potem twórz punkt odtworzenia i aktualizuj.

Plan reakcji dla administratora

1. Ustal wszystkie instancje Dokploy, także testowe, prywatne i uruchamiane przez zespoły bez centralnej rejestracji.
2. Odczytaj rzeczywistą wersję i digest obrazu. Oznacz każdą instancję starszą niż 0.29.13 jako wymagającą pilnej obsługi.
3. Ogranicz panel do VPN, bramy tożsamości lub zaufanej sieci administracyjnej. Nie traktuj ukrytego adresu jako kontroli.
4. Zaktualizuj zgodnie z dokumentacją, potwierdź migracje i sprawdź, czy wszystkie repliki korzystają z nowego obrazu.
5. Przejrzyj użytkowników, role, tokeny, integracje Git, rejestry, harmonogramy, zadania backupu i ostatnie zmiany konfiguracji.
6. Porównaj uruchomione kontenery, sieci, wolumeny, reguły Traefika i klucze SSH ze znanym stanem oczekiwanym.
7. Jeżeli panel był publiczny lub miał wielu użytkowników o niskich uprawnieniach, rotuj sekrety dostępne z control plane’u i poszerz analizę o hosty wykonawcze.

Rotacja powinna uwzględnić tokeny Git, klucze rejestrów, dane dostępu do baz, klucze API chmury, poświadczenia DNS i sekrety aplikacji. Nie wszystkie musiały zostać ujawnione, ale po potwierdzonym wykonaniu kodu na hoście założenie o ich poufności jest słabe. Wydawaj nowe wartości po usunięciu trwałości, inaczej napastnik może odczytać je ponownie.

Telemetria, która może zachować dowody

Najbardziej użyteczne są logi spoza samego Dokploy: zdarzenia uwierzytelnienia z bramy SSO, historia dostawcy Git, audit log rejestru, dzienniki API chmury, logi DNS i ślady na hoście. Proces z prawem zapisu może zmienić lokalny dziennik, dlatego centralna kopia ma większą wartość dowodową. Szukaj nietypowych procesów potomnych powłoki, nowych kluczy SSH, połączeń wychodzących, kontenerów bez znanego wdrożenia i zmian w godzinach niepasujących do pracy zespołu.

Nie buduj detekcji wyłącznie na znakach specjalnych w parametrach HTTP. Możliwe ścieżki obejmują wiele pól i sposobów kodowania, a rekordy nie stanowią kompletnego podpisu ataku. Lepsze jest połączenie zachowania: konto tworzy lub modyfikuje zasób, po czym control plane uruchamia nietypowy proces albo łączy się z nowym celem. Takie reguły mają szansę wykryć również przyszłe warianty.

Po aktualizacji wykonaj kontrolowany test uprawnień na dwóch tenantach: użytkownik organizacji A nie może odczytać, zmienić ani uruchomić zasobu organizacji B, nawet jeżeli zna jego identyfikator. Sprawdź też, czy pola nazw i ścieżek są walidowane po stronie serwera. Test ma potwierdzić granice, nie odtwarzać publicznego exploita na produkcji.

Wniosek architektoniczny

Fala Dokploy pokazuje, że platforma wdrożeniowa jest elementem uprzywilejowanym, nawet jeśli jej interfejs przypomina zwykłą aplikację SaaS. Powinna mieć osobną strefę sieciową, silne MFA, krótkie sesje, minimalne role, zewnętrzne logowanie i ograniczone sekrety. Host nie powinien automatycznie posiadać dostępu do całej organizacji tylko dlatego, że upraszcza to pierwszą konfigurację.

Zespoły tworzące własne panele DevOps powinny wyciągnąć dwie lekcje. Operacje systemowe należy budować przez bezpieczne API argumentów, bez składania poleceń powłoki. Każda procedura przyjmująca identyfikator zasobu musi samodzielnie sprawdzać członkostwo w organizacji, zamiast ufać wcześniejszemu widokowi interfejsu. Testy negatywne dla obu granic powinny być częścią CI.

Fakty o zakresach CVE i poprawkach pochodzą z rekordów CVE oraz wydania projektu. Zalecenia dotyczące segmentacji, rotacji i detekcji są oceną Breachroad wynikającą z roli control plane’u. Jeśli chcesz przełożyć podobne przypadki na praktykę zespołu, zobacz szkolenia cyberbezpieczeństwa dla organizacji. Weryfikację ekspozycji i konfiguracji platform wdrożeniowych można uzupełnić o audyt bezpieczeństwa chmury.