Organizacje korzystające z samodzielnie hostowanych instancji Gitea są wzywane do natychmiastowej aktualizacji po tym, jak amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA) dodała CVE-2026-60004 do swojego katalogu znanych wykorzystywanych luk w zabezpieczeniach (KEV) w dniu 25 sierpnia 2026 r.
Krytyczna luka ma wynik CVSS 9,8 i może pozwalać atakującym na wykonywanie dowolnych poleceń na podatnych serwerach Gitea. Decyzja CISA o umieszczeniu luki w katalogu KEV oznacza, że istnieją dowody na to, iż podatność jest wykorzystywana w rzeczywistych atakach.
Gitea to popularna platforma do hostowania repozytoriów Git o otwartym kodzie źródłowym, powszechnie wdrażana przez organizacje, które chcą zarządzać repozytoriami kodu źródłowego we własnej infrastrukturze.
Co się stało?
Luka, śledzona jako CVE-2026-60004, dotyczy funkcjonalności diffpatch w Gitea.
Zgodnie z oficjalnym komunikatem bezpieczeństwa Gitea podatny endpoint może zostać nadużyty przez użytkownika ze zwykłymi uprawnieniami zapisu do repozytorium, aby zainstalować i uruchomić złośliwy hook Git. Powstałe polecenia są wykonywane z uprawnieniami konta systemu operacyjnego używanego przez usługę Gitea.
Podatne wersje to Gitea od 1.17 do 1.27.0
Lukę naprawiono w Gitea 1.27.1. Następnie Gitea wydała wersję 1.27.2 w dniu 14 sierpnia 2026 r., więc organizacje aktualizujące się obecnie powinny co do zasady przejść na aktualnie wspieraną wersję z poprawką, zamiast poprzestawać na minimalnej wersji naprawionej.
CISA wyznaczyła 28 sierpnia 2026 r. jako termin usunięcia luki dla dotkniętych nią amerykańskich federalnych agencji cywilnych.
Jak działa ta luka
Problem ma swoje źródło w zdefiniowanym w Gitea:
POST /api/v1/repos/{owner}/{repo}/diffpatch
endpoincie.
Funkcja ta pozwala stosować łatki do repozytorium. W podatnych wersjach Gitea przetwarza łatki kontrolowane przez atakującego wewnątrz tymczasowego repozytorium bare Git.
Repozytorium bare różni się od zwykłej kopii roboczej Git tym, że jego katalog repozytorium faktycznie staje się katalogiem kontrolnym Git.
W określonych warunkach starannie przygotowana łatka może więc spowodować umieszczenie pliku wykonywalnego w katalogu hooków Git. Hooki Git to skrypty, które Git automatycznie uruchamia przy określonych operacjach na repozytorium.
Komunikat bezpieczeństwa Gitea wyjaśnia, że atak może wykorzystać to zachowanie tak, aby został zainstalowany, a następnie uruchomiony złośliwy hook post-index-change.
Skutkiem jest wykonanie dowolnych poleceń z uprawnieniami użytkownika systemu operacyjnego Gitea.
Co ważne, wykorzystanie luki wymaga Git 2.32 lub nowszego, włączonej trasy diffpatch oraz tymczasowego systemu plików z uprawnieniami do zapisu i wykonywania.
Czy luka naprawdę nie wymaga uwierzytelnienia?
Nie bezpośrednio.
Endpoint diffpatch wymaga uprawnień zapisu do repozytorium. Atakujący musi więc mieć uprawnienia do modyfikowania repozytorium, zanim będzie mógł wywołać podatną operację.
Jednak domyślna konfiguracja Gitea może znacząco osłabić tę barierę.
Komunikat bezpieczeństwa Gitea zaznacza, że przy włączonej otwartej rejestracji zewnętrzny użytkownik może założyć zwykłe konto, utworzyć repozytorium i automatycznie uzyskać uprawnienia zapisu do tego repozytorium.
Oznacza to, że atakujący, który wcześniej nie miał żadnych poświadczeń, po dotarciu do serwera może samodzielnie uzyskać dostęp potrzebny do przeprowadzenia ataku.
W przypadku serwerów Gitea dostępnych z internetu, które pozwalają na publiczną rejestrację i nieograniczone tworzenie repozytoriów, to rozróżnienie zapewnia stosunkowo niewielką ochronę.
Potwierdzone aktywne wykorzystanie
Ryzyko nie jest już teoretyczne.
CISA dodała CVE-2026-60004 do katalogu KEV 25 sierpnia, po ustaleniu, że istnieją dowody aktywnego wykorzystania.
CISA nie przypisała publicznie ataków konkretnemu aktorowi zagrożeń ani nie ujawniła szczegółowych informacji o atakach.
Jednak w osobnych doniesieniach opisano co najmniej jednego administratora Gitea, który miał zaobserwować wykorzystanie luki zgodne z CVE-2026-60004.
Według tej relacji dostępny publicznie serwer Gitea z otwartą rejestracją został przejęty i wdrożono na nim skrypt przypominający dropper koparki kryptowalut. Przejęty serwer odnotował długotrwałe, wysokie obciążenie procesora, zanim dostawca hostingu ograniczył jego zasoby.
Ostateczny ładunek, infrastruktura koparki, portfel, rodzina złośliwego oprogramowania i tożsamość atakującego nie zostały potwierdzone, dlatego incydentu nie należy traktować jako rozstrzygającej atrybucji szerszej kampanii kryptojackingu.
Niejasne jest również, czy ten konkretny incydent był dowodem, który skłonił CISA do dodania luki do KEV.
Dlaczego ta luka jest niebezpieczna
Platformy kodu źródłowego zajmują szczególnie wrażliwe miejsce w nowoczesnych organizacjach.
Serwer Gitea może zawierać prywatne repozytoria, konfigurację aplikacji, skrypty wdrożeniowe, szablony infrastruktury jako kodu oraz poświadczenia używane przez systemy CI/CD.
Według komunikatu bezpieczeństwa Gitea skuteczne wykorzystanie luki może potencjalnie ujawnić informacje dostępne dla konta usługi Gitea, w tym sekrety aplikacji, sekrety środowiska procesu, zamontowane repozytoria, poświadczenia do baz danych, poświadczenia OAuth i inne połączone usługi wewnętrzne.
Sprawia to, że skutki mogą być potencjalnie poważniejsze niż utrata kontroli nad pojedynczym serwerem.
Atakujący, który uzyska dostęp do infrastruktury deweloperskiej, może też próbować ingerować w kod źródłowy, kraść własność intelektualną, zdobywać poświadczenia lub wykorzystać przejęte środowisko jako punkt wyjścia do kolejnych ataków.
Dokładny wpływ zależy ostatecznie od tego, jak izolowany jest serwer Gitea oraz jakie uprawnienia, sekrety i dostęp sieciowy przyznano jego koncie usługi.
Co powinny zrobić organizacje
Organizacje korzystające z Gitea powinny traktować CVE-2026-60004 jako pilny priorytet naprawy.
- Natychmiast zaktualizuj do Gitea 1.27.1 lub nowszej, najlepiej do najnowszej stabilnej wersji odpowiedniej dla Twojego środowiska.
- Sprawdź, czy włączona jest publiczna rejestracja kont, i wyłącz ją, o ile nie ma uzasadnionej potrzeby biznesowej.
- Ogranicz krąg osób, które mogą tworzyć repozytoria i uzyskiwać uprawnienia zapisu do repozytoriów.
- Przejrzyj logi dostępu pod kątem nietypowych żądań dotyczących API
/diffpatch. - Zbadaj nieoczekiwane konta lub repozytoria utworzone na instancjach dostępnych z internetu.
- Monitoruj nietypowe procesy uruchamiane przez konto usługi Gitea oraz niewyjaśnioną aktywność procesora lub sieci.
- Sprawdź serwer pod kątem nieautoryzowanych hooków Git, modyfikacji repozytoriów i mechanizmów utrzymania dostępu (persistence).
- Jeśli podejrzewasz przejęcie, potraktuj poświadczenia dostępne dla procesu Gitea jako potencjalnie ujawnione i po opanowaniu incydentu zmień odpowiednie sekrety baz danych, OAuth, CI/CD i integracji.
Ponieważ wykorzystanie luki zaobserwowano już w praktyce, samo zainstalowanie aktualizacji może nie wystarczyć w przypadku systemów, które wcześniej były wystawione na atak. Organizacje powinny też ustalić, czy atakujący mogli uzyskać dostęp do serwera, zanim został załatany.
Infrastruktura deweloperska jest częścią obwodu bezpieczeństwa
Ten incydent uwypukla coraz ważniejszy problem bezpieczeństwa: platformy deweloperskie to infrastruktura o wysokiej wartości.
Serwery Git są ściśle powiązane z kodem źródłowym, systemami CI/CD, rejestrami kontenerów, środowiskami chmurowymi i produkcyjnymi potokami wdrożeniowymi. Przejęcie jednego z tych systemów może więc otworzyć możliwości daleko wykraczające poza pierwotnie podatną aplikację.
Narzędzia deweloperskie dostępne z internetu powinny w związku z tym podlegać takiej samej uwadze w zakresie zarządzania podatnościami, monitorowania i kontroli dostępu jak inna infrastruktura krytyczna.
Organizacje powinny ograniczać zbędną ekspozycję publiczną, wyłączać nieużywane funkcje, ograniczać tworzenie kont i dbać o szybkie wdrażanie aktualizacji bezpieczeństwa po ujawnieniu krytycznych luk.
Podsumowanie
CVE-2026-60004 łączy kilka niebezpiecznych cech: krytyczne zdalne wykonanie kodu, publicznie znaną ścieżkę wykorzystania, stosunkowo łatwy dostęp przy włączonej otwartej rejestracji oraz potwierdzone już wykorzystanie w rzeczywistych atakach.
Organizacje korzystające z Gitea od 1.17 do 1.27.0 powinny niezwłocznie przeprowadzić aktualizację i sprawdzić dostępne z internetu instancje pod kątem oznak wcześniejszego przejęcia.
Platformy deweloperskie i repozytoria kodu źródłowego należy traktować jak infrastrukturę krytyczną. Łataj je szybko, ograniczaj publiczny dostęp i nigdy nie traktuj wymogu posiadania konta jako realnej granicy bezpieczeństwa, gdy publiczna rejestracja może to konto przyznać automatycznie.
