Przejdź do treści
Luki i patche

Luka w Gitea ujawniała prywatne obrazy kontenerów w tysiącach wdrożeń

Krytyczna podatność w samodzielnie hostowanym serwisie Git Gitea mogła pozwolić nieuwierzytelnionym atakującym na pobranie prywatnych obrazów kontenerów z ponad 30 000 wdrożeń. Administratorzy powinni niezwłocznie zaktualizować system do wersji 1.26.2.

4 min read
An abstract composition of layered, translucent container shapes in blue and grey, some marked with a faint padlock symbol, while a network of thin red lines probes toward them from the outside. The background is a dark, cloud-like mass suggesting the internet.

CVE-2026-27771 to luka w mechanizmie kontroli dostępu wbudowanego rejestru kontenerów w Gitea – popularnym, otwartoźródłowym narzędziu do samodzielnego hostowania repozytoriów Git. Jak ostrzega firma NoScope, podatność pozwalała każdemu użytkownikowi Internetu na pobranie prywatnych obrazów kontenerów bez żadnego uwierzytelnienia. Problem istnieje również w forku Forgejo i może dotyczyć innych pochodnych wersji.

Jak działała podatność i co było zagrożone

Gitea oferuje wbudowany rejestr kontenerów, który domyślnie przechowuje obrazy oznaczone jako prywatne. NoScope odkryło, że reguły uwierzytelniania nie były egzekwowane dla tych obrazów – rejestr odpowiadał na standardowe, anonimowe żądania pull z użyciem protokołu Docker/OCI. „Gitea’s container registry has allowed any person on the internet, with no account, no password, and no prior access, to pull what would be considered private container images at first glance from affected instances as if they were public” – czytamy w analizie firmy.

Obrazy kontenerów często zawierają poufne dane: kod źródłowy, klucze dostępu, hasła czy szczegóły infrastruktury produkcyjnej. Wykorzystanie luki mogło prowadzić do wycieku tych informacji bez pozostawiania śladów w logach autoryzacji.

Skala problemu: tysiące narażonych wdrożeń

Badacze z NoScope przeprowadzili skanowanie za pomocą wyszukiwarki Shodan i zidentyfikowali ponad 34 000 instancji Gitea dostępnych z publicznego Internetu. Z tej liczby około 93% (czyli około 31 750) było podatnych na atak. Jak podkreśla NoScope: „The data is unambiguous. These aren’t hobby machines. These are organisations that made a deliberate decision to self-host their development infrastructure, running it on production-grade compute, for real workloads.” Spośród potencjalnie zagrożonych wdrożeń około 4 000 to systemy produkcyjne działające na głównych platformach chmurowych. Co istotne, luka znajdowała się w kodzie Gitea od około czterech lat, zanim została załatana.

„Gitea’s container registry has allowed any person on the internet, with no account, no password, and no prior access, to pull what would be considered private container images at first glance from affected instances as if they were public.” – NoScope

Dla kogo zagrożenie jest największe

Ryzyko dotyczy przede wszystkim organizacji i zespołów programistycznych, które hostują własne repozytoria Git i wykorzystują wbudowany rejestr kontenerów do przechowywania obrazów z danymi wrażliwymi. Dotyczy to zarówno firm, startupów, jak i instytucji publicznych. Ponieważ luka umożliwia dostęp bez uwierzytelnienia, atakujący nie musi posiadać żadnych kont w systemie – wystarczy, że zna publiczny adres instancji Gitea. W przypadku Forgejo, które współdzieli kod rejestru, sytuacja jest analogiczna; administratorzy tego forka również powinni sprawdzić, czy używają podatnej wersji.

Jak się zabezpieczyć – konkretne kroki

Głównym i najskuteczniejszym działaniem jest aktualizacja do wersji 1.26.2, która zawiera poprawkę usuwającą lukę. Wersja ta została wydana pod koniec maja 2026 roku. Dla administratorów, którzy nie mogą natychmiast zaktualizować, NoScope sugeruje zmianę konfiguracji tak, aby wymagać uwierzytelniania dla całego dostępu do rejestru. Należy jednak pamiętać, że to ustawienie może nie być odpowiednie dla instancji, które celowo udostępniają publiczne obrazy kontenerów. W takiej sytuacji trzeba starannie rozważyć kompromis między bezpieczeństwem a funkcjonalnością.

Dodatkowym, wartym rozważenia krokiem jest regularne monitorowanie logów dostępu do rejestru kontenerów pod kątem nietypowych żądań pull oraz weryfikacja, czy w ostatnim czasie nie doszło do nieautoryzowanego pobrania obrazów. W przypadku podejrzenia wycieku poufnych danych (np. kluczy API w obrazach), należy je natychmiast unieważnić i wygenerować nowe.

Szerszy kontekst – w stronę bezpieczeństwa łańcucha dostaw

Podatność w Gitea to kolejny sygnał, jak ważne jest zabezpieczanie nie tylko samego kodu źródłowego, ale również całego łańcucha narzędzi programistycznych. Rejestry kontenerów stały się krytycznym elementem infrastruktury DevOps – ich naruszenie może mieć dalekosiężne skutki, od wycieku własności intelektualnej po kompromitację środowisk produkcyjnych. Wpisuje się to w szerszy trend ataków na łańcuch dostaw oprogramowania, który obserwujemy od kilku lat.

Administratorzy systemów opartych na Gitea i Forgejo powinni traktować tę aktualizację jako priorytetową. Zaleca się również przeprowadzenie przeglądu konfiguracji pod kątem innych potencjalnych błędów kontroli dostępu oraz stosowanie zasady minimalnych uprawnień. W przypadku wątpliwości warto skorzystać z bezpłatnych narzędzi, takich jak moje.cert.pl od CERT Polska, które pomaga wykrywać podatności i błędne konfiguracje w infrastrukturze domenowej.

Sytuacja pokazuje, że nawet dojrzałe, otwartoźródłowe projekty mogą zawierać krytyczne błędy przez lata. Systematyczne aktualizacje i świadomość zagrożeń to podstawa bezpieczeństwa w dzisiejszym cyfrowym środowisku.

Redakcja sekuret.pl

Redakcja sekuret.pl

AUTHOR