Wprowadzenie do problemu / definicja
Krytyczna podatność zdalnego wykonania kodu w platformie Gitea została wykorzystana w rzeczywistych atakach wymierzonych w publicznie dostępne instancje tego rozwiązania. Sprawa pokazuje, że samodzielnie hostowane platformy deweloperskie pozostają celem o wysokiej wartości, ponieważ przechowują kod źródłowy, sekrety konfiguracyjne, tokeny dostępu oraz dane umożliwiające dalszą eskalację uprawnień.
Według opublikowanych ustaleń za kampanią stoi grupa określana jako Red Heron. Atakujący nie ograniczali się do prostego przejęcia repozytoriów, lecz prowadzili działania charakterystyczne dla dojrzałych operacji cyberwywiadowczych, obejmujące utrwalenie dostępu, kradzież poświadczeń, ruch boczny i wdrażanie złośliwego oprogramowania w środowiskach Linux.
W skrócie
- W atakach wykorzystano lukę CVE-2026-60004 w Gitea.
- Ofiarami padło co najmniej 13 organizacji w sześciu krajach.
- Cele obejmowały sektory obronny, wyborczy, energetyczny, telekomunikacyjny, administracyjny i badawczy.
- Po eksploatacji napastnicy kradli repozytoria, zbierali sekrety i uzyskiwali trwały dostęp.
- W kampanii powiązano backdoora JITTERLY oraz rootkita LD_PRELOAD o nazwie SIXZUT.
Kontekst / historia
Gitea to lekka platforma do hostowania repozytoriów Git, często wdrażana lokalnie przez organizacje chcące zachować kontrolę nad kodem i infrastrukturą CI/CD. Z perspektywy bezpieczeństwa takie systemy są szczególnie wrażliwe, ponieważ poza kodem przechowują również klucze SSH, tokeny API, pliki konfiguracyjne oraz artefakty integracyjne.
Analizowana kampania wpisuje się w model zagrożenia typu N-day. Oznacza to, że po publicznym ujawnieniu podatności i dostępności proof-of-concept atakujący bardzo szybko przeszli do automatyzacji eksploatacji. Tego rodzaju tempo działania sugeruje dobrze przygotowany proces operacyjny: od rozpoznania infrastruktury, przez rozwój narzędzi ofensywnych, po wybór ofiar o wysokiej wartości wywiadowczej.
Analiza techniczna
Z opisu kampanii wynika, że Red Heron skanował 1386 instancji Gitea w siedmiu krajach, a dodatkowo utrzymywał osobny zbiór 477 systemów z Tajwanu. Publiczny exploit dla CVE-2026-60004 miał zostać rozbudowany do zautomatyzowanego skryptu obsługującego rejestrację kont, eksploatację podatnych serwerów, kradzież repozytoriów oraz usuwanie wybranych śladów aktywności.
Po uzyskaniu możliwości wykonania kodu atakujący realizowali typowy łańcuch działań post-exploitation. Obejmował on rozpoznanie środowiska, zbieranie poświadczeń, eksfiltrację danych, ustanowienie trwałości, pivoting do innych systemów oraz eskalację uprawnień do poziomu root.
- enumeracja hosta i środowiska,
- kradzież sekretów oraz danych dostępowych,
- eksfiltracja repozytoriów i konfiguracji,
- utrwalanie dostępu do zainfekowanego systemu,
- ruch boczny do kolejnych zasobów infrastruktury,
- eskalacja uprawnień do kont uprzywilejowanych.
W jednym z opisanych przypadków punkt wejścia przez podatny serwer Gitea miał doprowadzić do uzyskania administracyjnego dostępu root do trzywęzłowego klastra Proxmox. To scenariusz szczególnie groźny, ponieważ przejęcie warstwy wirtualizacji może otwierać drogę do szerokiej kompromitacji wielu systemów uruchomionych w danym środowisku.
Na serwerze stagingowym przypisywanym operatorom zidentyfikowano implant Linux napisany w C++, nazwany JITTERLY. Backdoor ten ma obsługiwać ponad 30 komend, w tym uruchamianie powłoki, transfer plików, kończenie procesów, tunelowanie ruchu, dostęp interaktywny i poruszanie się wewnątrz sieci ofiary. W praktyce oznacza to narzędzie zaprojektowane do długotrwałych operacji, a nie jednorazowego wdrożenia malware.
Dodatkowo wykryto nieudokumentowany wcześniej rootkit LD_PRELOAD o nazwie SIXZUT. Tego typu mechanizm przechwytuje wywołania bibliotek współdzielonych i może ukrywać procesy, pliki oraz połączenia sieciowe przed standardowymi narzędziami administracyjnymi. Dla obrońców oznacza to większe trudności w analizie incydentu, wykrywaniu śladów obecności napastnika i skutecznym usuwaniu komponentów złośliwego oprogramowania.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem eksploatacji Gitea jest uzyskanie dostępu do zasobów stanowiących centrum procesu wytwórczego oprogramowania. Przejęcie repozytoriów i sekretów może prowadzić nie tylko do utraty własności intelektualnej, lecz także do kompromitacji całego łańcucha dostaw oprogramowania.
- ujawnienie kodu źródłowego i know-how organizacji,
- pozyskanie sekretów zapisanych w kodzie i pipeline’ach,
- przejęcie kont uprzywilejowanych oraz kluczy dostępowych,
- kompromitacja środowisk build, CI/CD i deployment,
- możliwość wstrzyknięcia złośliwych komponentów do procesu wydawniczego.
Jeżeli instancja Gitea ma połączenia z rejestrami kontenerów, chmurą, runnerami CI/CD lub platformami wirtualizacyjnymi, skutki incydentu szybko wykraczają poza pojedynczy host. Opisane przejście do klastra Proxmox dobrze pokazuje, że podatność w systemie deweloperskim może stać się początkiem pełnoskalowej kompromitacji infrastruktury.
Rekomendacje
Organizacje korzystające z Gitea powinny potraktować tego typu kampanię jako zagrożenie wysokiego priorytetu. Kluczowe jest połączenie szybkiego patchowania z kontrolą ekspozycji usług, analizą śladów powłamaniowych oraz rotacją wszystkich sekretów, które mogły zostać naruszone.
- Natychmiast zaktualizować Gitea do wersji zawierającej poprawkę dla CVE-2026-60004.
- Ograniczyć dostęp do instancji internet-facing przy użyciu VPN, segmentacji i kontroli dostępu.
- Przeprowadzić threat hunting pod kątem nietypowej rejestracji kont, masowego klonowania repozytoriów i manipulacji logami.
- Zweryfikować integralność hostów Linux, zwłaszcza pod kątem anomalii związanych z LD_PRELOAD i mechanizmami persistence.
- Rotować tokeny API, klucze SSH, hasła serwisowe i sekrety wykorzystywane w CI/CD.
- Sprawdzić systemy powiązane z Gitea, takie jak runnery, rejestry kontenerów, hosty administracyjne i platformy wirtualizacyjne.
- Wdrożyć monitoring nietypowych połączeń wychodzących, tunelowania ruchu i procesów uruchamianych przez konto usługi Gitea.
- Przeskanować repozytoria oraz historię commitów pod kątem ujawnionych sekretów.
- Stosować zasadę minimalnych uprawnień dla hosta i kont usługi.
- Przygotować scenariusz reagowania zakładający pełną kompromitację środowiska deweloperskiego.
Podsumowanie
Kampania Red Heron pokazuje, że platformy do zarządzania kodem są dziś celem strategicznym. Publicznie ujawniona luka w Gitea została szybko przekształcona w zautomatyzowane narzędzie ofensywne, a skutki ataków objęły kradzież repozytoriów, utrwalenie dostępu oraz ruch boczny do kolejnych warstw infrastruktury.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: systemy deweloperskie należy traktować jak zasoby krytyczne. Wymagają one szybkiego patchowania, ścisłej segmentacji sieci, ograniczania ekspozycji do internetu oraz stałego monitoringu pod kątem działań po eksploatacji.
Źródła
- The Hacker News — Red Heron Exploits Gitea RCE to Compromise 13 Organizations Across Six Countries — https://thehackernews.com/2026/09/red-heron-exploits-gitea-rce-to.html
- Acronis TRU — Red Heron campaign analysis — https://www.acronis.com/en-us/tru/posts/red-heron-exploits-gitea-rce-to-compromise-13-organizations/
- CVE Record — CVE-2026-60004 — https://www.cve.org/CVERecord?id=CVE-2026-60004
- GitHub Security / Gitea advisory resources — https://github.com/go-gitea/gitea/security
- Research notes on JITTERLY / Linux post-exploitation tooling — https://dmpdump.github.io/posts/AgainstTheWind/