Gitea runner CVE-2026-73802: wyłączony privileged nie zamyka granicy CI

GitHub Advisory Database zaktualizował 2 października wpis o CVE-2026-73802. Nota dotyczy runnera Gitea wykonującego zadania w Dockerze. Opisuje sytuację, w której wyłączenie trybu uprzywilejowanego nie usuwa innych niebezpiecznych ustawień przekazanych przez autora workflow. Nota projektu była opublikowana 15 sierpnia; październikowy wpis bazy nie jest datą pierwszego ujawnienia.

Według noty Gitea opcje kontenera z workflow mogą zachować dostęp do przestrzeni nazw hosta, dodatkowe uprawnienia i wyłączenia profili ochrony. Autor uruchamianego workflow może w opisanej konfiguracji wykonać polecenia na hoście jako root. To problem granicy między konfiguracją zadania a uprawnieniami infrastruktury CI.

Kto powinien ocenić ekspozycję

Priorytetem są współdzielone runnery obsługujące kod lub workflow pochodzące od osób o niższym poziomie zaufania. Trzeba ustalić, kto może zmienić definicję zadania i doprowadzić do jej wykonania: członek zespołu, współpracownik czy autor zewnętrznego zgłoszenia. Sam fakt, że repozytorium jest prywatne, nie odpowiada na to pytanie.

Nie przenosimy opisu na każdą instalację serwera Gitea ani każdy produkt CI. Ważne są używany runner, ścieżka uruchamiania kontenera i osiągalność opcji kontrolowanych przez workflow. Ocena powinna obejmować rzeczywistą konfigurację, a nie tylko deklarację privileged: false.

Dlaczego jedna flaga to za mało

Dokumentacja Docker Engine opisuje bezpieczeństwo kontenera jako połączenie przestrzeni nazw, uprawnień, konfiguracji i ochrony hosta. Kontrola jednej flagi nie rozstrzyga, jak działają pozostałe mechanizmy.

Wniosek Breachroad: definicję workflow trzeba traktować jako żądanie wykonania kodu. Osoba uprawniona do edycji zadania nie powinna przez dodatkowy parametr samodzielnie poszerzać dostępu do hosta, sieci ani sekretów innych projektów. Polityka runnera powinna ograniczać wynikową konfigurację, także po połączeniu ustawień pochodzących z różnych miejsc.

Jak czytać status poprawki

Baza GitHuba wskazuje dla modułu Go gitea.com/gitea/runner wersje wcześniejsze niż 1.0.9-0.20260731160927-34bfa1915022 i tę wersję jako naprawioną. Karta projektu używa innej numeracji: pole affected zawiera < 3.0.0, a patched > 3.0.0. To rozbieżność metadanych, którą należy uwzględnić przy wyborze wdrażanego artefaktu.

Rekomendujemy potwierdzenie, jakie wydanie lub obraz używany w danej dystrybucji zawiera właściwą zmianę. Nie uznajemy samego napisu „3.0.0” za dowód naprawy. Właściciel CI powinien zapisać wersję, pochodzenie artefaktu i dowód odrzucania niedozwolonych ustawień. Do czasu potwierdzenia ogranicz uruchamianie niezaufanych workflow na współdzielonej infrastrukturze.

Przykład szkoleniowy: test i wdrożenie na jednym hoście

W naszym fikcyjnym przykładzie firma kieruje testy z pull requestów i wdrożenia produkcyjne na jeden host. Osoba utrzymująca platformę widzi wyłączony tryb privileged i zakłada, że zadania nie mogą wpływać na siebie. Zespół powinien zapytać, jakie dane i sieci byłyby osiągalne po przekroczeniu granicy kontenera.

Naszą propozycją jest rozdzielenie tych poziomów zaufania: osobne środowiska wykonawcze, kontrola dozwolonych opcji, ograniczona łączność i poświadczenia dostępne tylko dla konkretnego etapu. Samo utworzenie osobnego katalogu roboczego nie tworzy takiej granicy. Również jednorazowy runner wymaga sprawdzenia, jakie dane, obrazy i cache przenosi do następnego zadania.

Co sprawdzić teraz

1. Zidentyfikuj runnery, ich właścicieli, wersje i repozytoria korzystające z każdego hosta.
2. Ustal, kto może uruchomić zmodyfikowany workflow i które opcje faktycznie trafiają do kontenera.
3. Oddziel zadania o różnym poziomie zaufania i usuń zbędny dostęp do sekretów oraz infrastruktury wdrożeniowej.
4. W kontrolowanym środowisku potwierdź egzekwowanie polityki po aktualizacji. Zachowaj wynik i konfigurację użytego artefaktu.

Jeśli analiza wskaże nieautoryzowane wykonanie na hoście, rozpocznij obsługę incydentu z oceną osiągalnych poświadczeń i innych zadań. Brak widocznych zmian w repozytorium nie rozstrzyga, czy host był bezpieczny.

Szkolenia dla zespołów IT i DevSecOps pozwalają przećwiczyć ocenę zaufania do workflow i eskalację takich ustaleń. Podstawy opisujemy w poradniku o bezpieczeństwie CI/CD.

Źródła i rekomendacje Breachroad

Mechanizm i metadane wersji pochodzą z podlinkowanych not Gitea oraz GitHuba. Dokumentacja Dockera wyjaśnia mechanizmy izolacji. Przykład, kolejność oceny i proponowany podział infrastruktury są naszymi rekomendacjami. Nie twierdzimy, że nota potwierdza aktywny atak na konkretną organizację. Źródła sprawdzono 4 października 2026 roku.