Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W Docker Engine ujawniono podatność CVE-2026-34040 o wysokiej wadze, która umożliwia obejście wtyczek autoryzacyjnych AuthZ w określonych warunkach. Problem dotyczy środowisk, w których polityki bezpieczeństwa podejmują decyzje na podstawie treści ciała żądania API. W praktyce oznacza to, że mechanizm mający blokować niebezpieczne operacje może zostać ominięty, a atakujący z dostępem do API Dockera może doprowadzić do uruchomienia uprzywilejowanego kontenera i uzyskać dostęp do zasobów hosta.
W skrócie
CVE-2026-34040 to luka w Docker Engine wynikająca z niepełnej poprawki wcześniejszego problemu CVE-2024-41110. Podatność pozwala przygotować żądanie do API w taki sposób, aby demon Dockera przetworzył pełną operację, natomiast wtyczka autoryzacyjna nie otrzymała kompletnego ciała żądania potrzebnego do prawidłowej oceny polityki. W efekcie system kontroli dostępu może zaakceptować akcję, którą normalnie powinien zablokować. Producent udostępnił poprawkę w wersji Docker Engine 29.3.1. Szczególnie narażone są środowiska korporacyjne i platformy CI/CD korzystające z AuthZ do egzekwowania restrykcji bezpieczeństwa.
Kontekst / historia
Nowa podatność stanowi kontynuację problemów wokół autoryzacji w Docker Engine. Jej źródłem jest niekompletne usunięcie słabości znanej wcześniej jako CVE-2024-41110, która również dotyczyła obchodzenia decyzji wtyczek AuthZ. Mechanizm autoryzacyjny w Dockerze pełni ważną rolę w środowiskach wieloużytkownikowych, gdzie sam dostęp do interfejsu API nie powinien automatycznie oznaczać pełnej swobody operacyjnej.
W wielu organizacjach AuthZ służy do blokowania tworzenia kontenerów uprzywilejowanych, montowania systemu plików hosta, użycia niebezpiecznych flag uruchomieniowych czy dostępu do wskazanych ścieżek. Każda luka, która pozwala ominąć ocenę polityki, ma więc znaczenie wykraczające poza pojedynczy błąd implementacyjny. W praktyce osłabia jedną z ostatnich warstw kontroli przed eskalacją uprawnień w środowiskach kontenerowych.
Analiza techniczna
Istota problemu sprowadza się do rozbieżności między tym, co widzi demon Dockera, a tym, co trafia do wtyczki autoryzacyjnej. W typowym modelu działania klient wysyła żądanie do API Dockera, demon przekazuje dane do pluginu AuthZ, a następnie – zależnie od decyzji pluginu – operacja jest dozwolona lub blokowana.
W przypadku CVE-2026-34040 możliwe jest jednak przygotowanie specjalnie spreparowanego żądania HTTP z odpowiednio powiększonym ciałem. Jeśli żądanie przekroczy określony próg rozmiaru, komponent odpowiedzialny za przekazanie danych do pluginu może nie dostarczyć pełnego body do warstwy autoryzacji. Plugin podejmuje wtedy decyzję na podstawie niepełnych informacji albo nie widzi krytycznych parametrów operacji, podczas gdy demon Dockera nadal przetwarza właściwe żądanie.
To otwiera drogę do obejścia kontroli dostępu. Atakujący, który ma ograniczony dostęp do Docker API, może wysłać żądanie utworzenia kontenera z parametrami, które normalnie powinny zostać zablokowane przez politykę. Jeżeli plugin nie otrzyma danych opisujących bind mounty, tryb privileged lub inne wrażliwe parametry wykonania, istnieje ryzyko, że zaakceptuje operację.
Najgroźniejszy scenariusz zakłada utworzenie kontenera uprzywilejowanego z dostępem do systemu plików hosta. Taki kontener może odczytać pliki z serwera, w tym poświadczenia do chmury, klucze SSH, konfiguracje Kubernetes, tokeny aplikacyjne, sekrety CI/CD lub inne materiały umożliwiające dalszy ruch boczny. Nie jest to klasyczny exploit pamięci czy wykonanie kodu w daemonie, lecz obejście logicznej kontroli bezpieczeństwa, którego skutki mogą być równie poważne jak pełna kompromitacja hosta.
Dodatkowym aspektem jest możliwość automatyzacji ataku. W środowiskach, gdzie narzędzia developerskie, agenci automatyzacji lub pipeline’y mają dostęp do Docker API, luka może zostać wykorzystana pośrednio przez złośliwe dane wejściowe, prompt injection albo wymuszenie działań debugujących. To zwiększa ryzyko w nowoczesnych środowiskach DevOps, gdzie automaty często posiadają szerokie uprawnienia operacyjne.
Konsekwencje / ryzyko
Najważniejszą konsekwencją CVE-2026-34040 jest możliwość przejścia od ograniczonego dostępu do API Dockera do praktycznej kontroli nad hostem. Jeżeli host uruchamia krytyczne workloady, skutki mogą obejmować utratę poufności danych, eskalację uprawnień i trwałe osadzenie się napastnika w infrastrukturze.
- kradzież sekretów i poświadczeń z systemu plików,
- przejęcie kont w usługach chmurowych,
- dostęp do klastrów Kubernetes,
- kompromitację serwerów produkcyjnych przez wykorzystanie kluczy SSH,
- sabotaż pipeline’ów CI/CD i obrazów kontenerowych,
- utrzymanie trwałej obecności w środowisku.
Ryzyko jest najwyższe tam, gdzie organizacja zakłada, że same wtyczki AuthZ skutecznie ograniczają niebezpieczne operacje. Jeżeli polityki bezpieczeństwa opierają się na analizie body żądania, a dostęp do Docker API posiadają użytkownicy, automaty, runnerzy lub narzędzia integracyjne, podatność może znacząco obniżyć poziom zabezpieczeń.
Warto podkreślić, że nawet jeśli dostęp do API nie jest publiczny, wektor wewnętrzny nadal pozostaje realny. W wielu incydentach to nie zewnętrzny atak, lecz przejęty token, skompromitowany pipeline, złośliwy insider albo podatna aplikacja z dostępem do lokalnego socketa Dockera staje się punktem wejścia.
Rekomendacje
Podstawowym działaniem naprawczym jest aktualizacja Docker Engine do wersji zawierającej poprawkę, czyli co najmniej 29.3.1. Organizacje powinny potraktować ten update priorytetowo, szczególnie w środowiskach korzystających z AuthZ.
- ograniczyć dostęp do Docker API zgodnie z zasadą najmniejszych uprawnień,
- przeprowadzić przegląd wszystkich integracji, agentów, runnerów i narzędzi mających dostęp do demona Dockera,
- zweryfikować, czy używane wtyczki AuthZ opierają decyzje na analizie body żądań,
- monitorować operacje tworzenia kontenerów uprzywilejowanych, nietypowe mounty hosta oraz użycie wrażliwych flag uruchomieniowych,
- rozważyć uruchamianie Dockera w trybie rootless, aby ograniczyć skutki potencjalnej kompromitacji,
- tam, gdzie rootless nie jest możliwy, rozważyć mapowanie przestrzeni użytkowników, aby zredukować wpływ eskalacji na host,
- przeprowadzić audyt logów pod kątem podejrzanych żądań do API, zwłaszcza związanych z tworzeniem kontenerów i mountowaniem ścieżek hosta,
- odseparować sekrety, poświadczenia i konfiguracje klastra od systemów, które nie muszą mieć do nich bezpośredniego dostępu.
Z perspektywy obrony warstwowej istotne jest również odejście od założenia, że sam plugin autoryzacyjny stanowi wystarczającą kontrolę bezpieczeństwa. Blokowanie privileged containers, ograniczanie mountów hosta, segmentowanie uprawnień i dodatkowa telemetria powinny funkcjonować równolegle.
Podsumowanie
CVE-2026-34040 pokazuje, jak niebezpieczne mogą być błędy w logice autoryzacji, szczególnie w platformach kontenerowych będących fundamentem nowoczesnej infrastruktury. Podatność nie wymaga skomplikowanego łańcucha exploitów, lecz wykorzystuje niespójność między warstwą wykonawczą a warstwą kontroli dostępu. W środowiskach, które dopuszczają dostęp do Docker API i polegają na pluginach AuthZ, skutkiem może być uruchomienie uprzywilejowanego kontenera oraz przejęcie hosta.
Dla zespołów bezpieczeństwa i administratorów oznacza to konieczność pilnego patchowania, przeglądu modelu uprawnień oraz weryfikacji, czy istniejące zabezpieczenia rzeczywiście działają w warunkach granicznych. W praktyce najważniejsze są szybka aktualizacja, minimalizacja dostępu do API oraz wdrożenie dodatkowych mechanizmów ograniczających skutki ewentualnego obejścia autoryzacji.
Źródła
- https://thehackernews.com/2026/04/docker-cve-2026-34040-lets-attackers.html
- https://docs.docker.com/engine/release-notes/29/
- https://docs.docker.com/engine/extend/plugins_authorization/
- https://docs.docker.com/engine/security/rootless/
- https://www.cyera.com/blog/cyera-research-discovers-docker-authorization-bypass-that-silently-disables-security-policies