Cloud czy self-hosting? Podatność Gitea pokazuje, gdzie naprawdę jest ryzyko

Chmura bywa przedstawiana jako bezpieczniejsza i wygodniejsza alternatywa dla infrastruktury utrzymywanej samodzielnie. Self-hosting daje z kolei kontrolę nad danymi, konfiguracją i ciągłością działania. Żaden z tych modeli nie usuwa jednak podatności. Zmienia przede wszystkim to, kto odpowiada za ich wykrycie, usunięcie i ograniczenie skutków.

Dobrym przykładem jest Gitea, popularna otwartoźródłowa platforma do hostowania repozytoriów Git. Jest wybierana między innymi przez organizacje, które chcą uniezależnić się od publicznej usługi, zachować kod we własnym środowisku albo lepiej kontrolować integracje. Nie oznacza to jednak, że jest z definicji bezpieczniejsza od GitHuba. Gitea pozostaje rozbudowaną platformą z API, mechanizmami uprawnień, webhookami, hookami Git i integracjami CI/CD. Każdy z tych elementów powiększa powierzchnię ataku.

Niedawno ujawniona podatność CVE-2026-60004 dobrze pokazuje, dlaczego decyzja „cloud czy self-hosting” nie może zastąpić procesu zarządzania bezpieczeństwem.

Co wydarzyło się w Gitea?

Podatność otrzymała ocenę krytyczną, CVSS 9.8. Dotyczyła Gitea od wersji 1.17 do 1.27.0. Poprawkę udostępniono w wersji 1.27.1.

Problem znajdował się w funkcji diffpatch, która pozwala stosować łatki do repozytorium. Odpowiednio przygotowana zawartość repozytorium mogła doprowadzić do zapisania wykonywalnego hooka post-index-change w tymczasowym klonie Git typu bare. Podczas kolejnej operacji Git uruchamiał hook, a atakujący uzyskiwał możliwość wykonania poleceń systemowych z uprawnieniami użytkownika procesu Gitea.

Do ataku potrzebne były między innymi uprawnienia zapisu do repozytorium, Git 2.32 lub nowszy, aktywna trasa diffpatch oraz zapisywalny i wykonywalny katalog tymczasowy. W instalacji z otwartą rejestracją napastnik mógł jednak sam utworzyć konto i repozytorium, a więc zdobyć wymagane uprawnienia bez wcześniejszego dostępu administracyjnego.

Skutki nie ograniczały się do jednego repozytorium. Proces Gitea może mieć dostęp do plików konfiguracyjnych, sekretów aplikacji, poświadczeń bazy danych, tokenów integracji i zamontowanych repozytoriów. Firma runZero opisała również ryzyko dla artefaktów i dalszych etapów pipeline’u. 25 sierpnia 2026 podatność została dodana do katalogu aktywnie wykorzystywanych podatności CISA, co zmieniło ją z teoretycznego scenariusza w pilny problem operacyjny.

Najważniejszy wniosek jest prosty: self-hosted nie oznacza odizolowany, a uwierzytelnianie nie oznacza bezpieczny. Usługa wystawiona do internetu może zawierać rzadko używany endpoint, którego administrator nie uwzględnił w modelu zagrożeń.

Od wykonania kodu do uprawnień roota: możliwy łańcuch eskalacji

CVE-2026-60004 pozwalała wykonywać polecenia jako użytkownik usługi Gitea, a nie automatycznie jako root. To istotne rozróżnienie, ale nie powinno prowadzić do bagatelizowania problemu.

Po uzyskaniu lokalnego wykonania kodu atakujący może szukać kolejnej podatności w systemie operacyjnym. Przykładem jest RefluXFS, CVE-2026-64600: błąd wyścigu w mechanizmie copy-on-write systemu plików XFS, który mógł umożliwić lokalnemu użytkownikowi nadpisanie chronionych plików i eskalację uprawnień.

Taki łańcuch był możliwy tylko wtedy, gdy host spełniał dodatkowe warunki: korzystał z podatnego jądra, systemu plików XFS z reflink=1, zawierał odpowiedni cel ataku i udostępniał lokalnemu użytkownikowi zapisywalny katalog na tym samym systemie plików. Kontenery i sposób montowania systemów plików również mogły ograniczać lub wykluczać skuteczność eskalacji. Nie każda podatna instalacja Gitea była więc automatycznie podatna na RefluXFS.

Ten przykład pokazuje jednak, dlaczego ryzyka nie można oceniać wyłącznie na poziomie aplikacji. Realny scenariusz ataku łączy warstwy:

1. publicznie dostępny endpoint aplikacji;
2. wykonanie kodu jako konto usługi;
3. dostęp do sekretów, repozytoriów lub systemu plików;
4. ewentualną eskalację przez podatność jądra;
5. wpływ na pipeline CI/CD i artefakty trafiające dalej do środowisk produkcyjnych.

Cloud hosting i self-hosting: korzyści oraz koszty obu modeli

Chmura nie jest po prostu „lepsza”, a self-hosting nie jest po prostu „bezpieczniejszy”. Są to dwa różne sposoby podziału odpowiedzialności.

Usługa chmurowa może więc ograniczyć dług operacyjny związany z aktualizacjami i dostępnością. Nadal nie chroni przed błędnym przydziałem uprawnień, wyciekiem tokenu, złośliwą integracją, podatnym kodem uruchamianym w pipeline’ie czy błędami konfiguracji organizacji.

Self-hosting daje większą kontrolę, ale wraz z nią przejmuje się odpowiedzialność za całą warstwę techniczną. Jeśli organizacja nie ma inwentaryzacji wersji, ustalonego czasu wdrażania poprawek i monitoringu prób wykorzystania podatności, kontrola pozostaje pozorna.

AI zwiększa tempo po obu stronach

Wzrost ilości kodu tworzonego z pomocą AI nie oznacza automatycznie wzrostu liczby infekcji. Zwiększa jednak tempo zmian, liczbę zależności i obciążenie procesu review. Jeśli możliwości wytwarzania kodu rosną szybciej niż testy, analiza bezpieczeństwa i wiedza zespołu o systemie, rośnie prawdopodobieństwo, że błąd trafi do produkcji.

AI pomaga również w pracy ofensywnej. Badacze Qualys opisali, że podczas eksperymentu model Claude Mythos Preview pomógł im znaleźć błąd RefluXFS i przygotować proof of concept, który następnie został zweryfikowany przez ekspertów. To nie jest argument przeciwko AI. To dowód, że narzędzia obniżają koszt analizy ogromnych baz kodu zarówno dla obrońców, jak i potencjalnych atakujących.

W praktyce zmienia się ekonomia bezpieczeństwa:

• łatwiej tworzyć kod, integracje i automatyzacje;
• łatwiej analizować projekty w poszukiwaniu powtarzalnych klas błędów;
• łatwiej adaptować publiczny proof of concept do konkretnego środowiska;
• trudniej ręcznie przejrzeć każdą zmianę z taką samą dokładnością;
• rośnie znaczenie automatycznych kontroli, ograniczania uprawnień i izolacji.

Sama platforma może być regularnie aktualizowana, a mimo to pozostawać częścią ryzykownego systemu. O bezpieczeństwie decyduje cały łańcuch: aplikacja, host, konfiguracja, konta usługowe, sekrety, runner CI/CD, sieć i proces reagowania.

Co powinno znaleźć się w audycie takiego środowiska?

Skan podatności jest ważny, ale nie jest pełnym audytem. Dobrze udokumentowana ocena powinna objąć co najmniej:

• inwentaryzację instancji, wersji, komponentów i zależności;
• mapę ekspozycji sieciowej, endpointów oraz mechanizmów rejestracji;
• konfigurację ról, kont administracyjnych, kont usługowych i tokenów;
• izolację procesu, kontenerów, systemów plików i sekretów;
• konfigurację repozytoriów, hooków, webhooków oraz runnerów CI/CD;
• politykę aktualizacji aplikacji, systemu operacyjnego i jądra;
• logowanie zdarzeń, detekcję nadużyć i gotowość do reakcji;
• kopie zapasowe i sprawdzone procedury odtwarzania;
• priorytetyzację ustaleń według prawdopodobieństwa i wpływu;
• właścicieli działań naprawczych, terminy i retest po wdrożeniu zmian.

Zakres i kryteria powinny być jawne. W zależności od środowiska punktem odniesienia mogą być NIST Cybersecurity Framework 2.0, CIS Controls v8.1 oraz wytyczne producentów poszczególnych komponentów. Raport powinien oddzielać potwierdzone podatności od ryzyk warunkowych i zaleceń typu hardening.

Warto też okresowo korzystać z zewnętrznego zespołu. Niezależny konsultant nie zastępuje właściciela systemu, ale wnosi świeże spojrzenie, porównanie ze standardem i mniejszą skłonność do uznawania historycznych decyzji za oczywiste. Efektem powinien być materiał, na podstawie którego można zaplanować działania, wykazać ich wykonanie i wrócić do ustaleń przy kolejnym przeglądzie.

Przykładem takiego podejścia jest nasz opis zakresu audytu wdrożenia Keycloak. Obejmuje on nie tylko konfigurację serwera autoryzacji, lecz także integracje aplikacji, walidację tokenów, przechowywanie poświadczeń, PKCE, nagłówki bezpieczeństwa i ocenę ryzyka. Choć Gitea i Keycloak pełnią inne role, zasada jest ta sama: audyt trzeba prowadzić na styku platformy, aplikacji i infrastruktury.

Najważniejsza decyzja nie dotyczy miejsca hostowania

Podatność Gitea nie dowodzi, że self-hosting jest błędem. Awarie usług SaaS nie dowodzą też, że chmura jest złym wyborem. Prawdziwe pytanie brzmi: czy organizacja potrafi udźwignąć odpowiedzialność wynikającą z wybranego modelu?

Jeśli wybierasz chmurę, sprawdź model współdzielonej odpowiedzialności, uprawnienia, eksport danych, logi, integracje i plan na niedostępność dostawcy. Jeśli wybierasz self-hosting, zaplanuj patchowanie, izolację, monitoring, backup, testy odtworzeniowe i zastępowalność osób utrzymujących system.

W świecie, w którym AI przyspiesza zarówno rozwój oprogramowania, jak i analizę podatności, bezpieczeństwo nie może być jednorazową kontrolą przed uruchomieniem. Musi być powtarzalnym, udokumentowanym procesem: od inwentaryzacji i aktualizacji po niezależny audyt oraz weryfikację poprawek.