Podsumowanie
| Parametr | Wartość |
|---|---|
| CVE ID | CVE-2026-60004 |
| Źródło alertu | CISA KEV - aktywna eksploatacja |
| Rok publikacji CVE | 2026 |
| Data publikacji | 2026-08-25 |
| Producent | Gitea |
| Produkt | Gitea |
| Wersje podatne | >= 1.17, < 1.27.1 |
| Wersja naprawiona | 1.27.1 |
| CVSS Score | brak oceny w NVD; GitHub Security Advisory klasyfikuje jako Critical |
| EPSS Score | Brak danych |
| CISA KEV | Tak - potwierdzona aktywna eksploatacja |
| Ransomware | Nie potwierdzono |
| Termin na reakcję (CISA) | 2026-08-28 |
Opis podatności
Gitea to samodzielnie hostowany serwer Git — odpowiednik GitLaba dla organizacji, które trzymają kod na własnej infrastrukturze.
Endpoint diffpatch (services/repository/files/patch.go) nakłada patche kontrolowane
przez użytkownika w współdzielonym, gołym (bare) klonie tymczasowym. Wysłanie tego samego
patcha dwukrotnie powoduje konflikt typu add/add; trójstronne rozwiązywanie konfliktu
w Gicie wypisuje wtedy plik na dysk mimo użycia flagi --cached. Ponieważ w klonie bare
katalog główny repozytorium jest jednocześnie $GIT_DIR, wpis o nazwie
hooks/post-index-change staje się żywym hookiem Gita. Git wywołuje go przy zapisie
indeksu, a treść kontrolowana przez atakującego wykonuje się jako użytkownik systemowy,
na którym działa Gitea.
Do ataku wystarczy zwykłe prawo zapisu do jednego repozytorium. Przy domyślnie włączonej otwartej rejestracji oznacza to, że nieuwierzytelniony użytkownik z internetu zdobywa wymagane uprawnienia sam — zakłada konto i tworzy własne repozytorium.
Kod dowodowy (PoC) opublikowany razem z biuletynem zapisuje wynik polecenia w obiektach Gita i tworzy gałąź z rezultatem, więc atak nie wymaga połączenia wychodzącego z serwera — mechanizmy wykrywania oparte na ruchu wychodzącym go nie zobaczą.
CISA dodała podatność do katalogu KEV 25 sierpnia 2026 z terminem naprawy 28 sierpnia 2026.
Wymagane działania
- Zaktualizuj Gitea do wersji 1.27.1 lub nowszej — to jedyna pełna naprawa.
- Jeśli aktualizacja nie jest możliwa dziś: wyłącz otwartą rejestrację
(
[service] DISABLE_REGISTRATION = truewapp.ini). To nie usuwa podatności, ale podnosi próg z „każdy z internetu” do „posiadacz konta”. - Ogranicz dostęp do instancji Gitea z sieci publicznej — VPN albo lista dozwolonych adresów. Serwer Git z kodem źródłowym rzadko musi być wystawiony na cały internet.
- Ponieważ luka jest aktywnie wykorzystywana, sprawdź, czy nie doszło do kompromitacji:
pliki w katalogach
hooks/repozytoriów (szczególniepost-index-change), nietypowe procesy uruchomione przez użytkownika systemowego Gitea, nowe konta założone przez rejestrację, świeże repozytoria utworzone przez nieznanych użytkowników, zmiany w kluczach SSH i tokenach API. - Po potwierdzonej kompromitacji potraktuj wszystkie sekrety w repozytoriach i w CI/CD jako ujawnione — konto systemowe Gitea ma dostęp do całego magazynu repozytoriów.
Kogo dotyczy?
Podatność dotyczy organizacji utrzymujących własną instancję Gitea. W polskich firmach Gitea pojawia się wszędzie tam, gdzie kod nie może opuścić infrastruktury organizacji: w sektorze publicznym, w bankowości i ubezpieczeniach, w zespołach R&D oraz u dostawców oprogramowania obsługujących klientów z wymogami on-premise. Bywa też uruchamiana oddolnie przez zespoły deweloperskie jako „lekki GitLab” — i wtedy najczęściej wypada z rejestru systemów objętych zarządzaniem podatnościami.
Serwer Git to szczególny cel: zawiera kod źródłowy, historię, konfiguracje wdrożeniowe i bardzo często sekrety. Wykonanie kodu na tym hoście jest równoznaczne z dostępem do własności intelektualnej organizacji i do jej łańcucha dostaw oprogramowania.
Źródła
Potrzebujesz wsparcia w zabezpieczeniu systemów? Zespół nFlo oferuje usługi zarządzania podatnościami oraz SOC 24/7. Skontaktuj się z nami.
