TeamCity CVE-2026-63077: RCE bez logowania przez agent polling

JetBrains ujawnił CVE-2026-63077, krytyczną podatność TeamCity On-Premises. Napastnik posiadający dostęp HTTP(S) do serwera może bez uwierzytelnienia wykorzystać protokół odpytywania agentów, ominąć kontrolę dostępu i wykonać polecenia systemowe z uprawnieniami procesu TeamCity.

Problem dotyczy wszystkich wersji lokalnych. Poprawki są dostępne w liniach 2025.11.7 i 2026.1.3, a dla TeamCity 2017.1+ producent przygotował plugin bezpieczeństwa. TeamCity Cloud został poprawiony po stronie JetBrains i klienci tej usługi nie muszą instalować aktualizacji.

Dlaczego serwer CI/CD jest celem wysokiej wartości

RCE na zwykłym serwerze aplikacyjnym jest poważne. RCE na kontrolerze CI/CD ma dodatkowy wymiar: system budowania często przechowuje tokeny repozytoriów, poświadczenia rejestrów obrazów, klucze podpisywania, zmienne wdrożeniowe i dostęp do środowisk produkcyjnych.

Biuletyn JetBrains wskazuje, że udany atak może ujawnić dane i konfigurację TeamCity, zmienić stan serwera oraz naruszyć integralność artefaktów i dalszych etapów pipeline’u. Oznacza to możliwy łańcuch:

internet → TeamCity → sekrety → repozytorium/registry → artefakt → produkcja

Dlatego zamknięcie samego endpointu po podejrzeniu ataku nie kończy pracy. Trzeba ocenić wszystko, co serwer mógł odczytać, podpisać albo wdrożyć.

Warunki i zakres podatności

Wykorzystanie nie wymaga konta ani interakcji użytkownika. Wystarczy sieciowy dostęp do serwera TeamCity po HTTP(S), a ścieżka prowadzi przez agent polling protocol. Polecenia działają z uprawnieniami procesu serwera, więc praktyczny wpływ zależy również od konta systemowego, dostępu sieciowego i przechowywanych sekretów.

JetBrains otrzymał prywatne zgłoszenie 10 lipca. W chwili publikacji biuletynu producent nie znał aktywnego wykorzystania podatności. To nie jest gwarancja braku ataków; jest to precyzyjnie stan wiedzy producenta w konkretnym momencie.

Co zrobić teraz

Wariant preferowany: pełna aktualizacja

Zaktualizuj serwer do 2025.11.7 albo 2026.1.3 — zależnie od używanej linii. Po instalacji potwierdź wersję w działającym środowisku, nie tylko powodzenie zadania automatyzacji. Sprawdź także, czy reverse proxy lub klaster nie kieruje części ruchu do starej instancji.

Wariant przejściowy: plugin bezpieczeństwa

Jeżeli pełna aktualizacja nie jest natychmiast możliwa, JetBrains udostępnia plugin dla wersji 2017.1 i nowszych. Dla 2017.1–2018.1 wymagany jest restart serwera; od 2018.2 plugin może zostać włączony bez restartu. Producent podkreśla, że plugin naprawia tylko CVE-2026-63077 i nie zastępuje aktualizacji zawierającej inne poprawki.

Ograniczenie ekspozycji

• usuń publiczny dostęp do panelu i API;
• wymagaj VPN albo dodatkowej warstwy kontroli przed TeamCity;
• ogranicz źródłowe adresy agentów i administratorów;
• uruchamiaj serwer z minimalnymi uprawnieniami systemowymi;
• oddziel host serwera od agentów budujących;
• zablokuj niepotrzebny ruch wychodzący do produkcji i systemów sekretów.

Segmentacja nie zastępuje poprawki, ale zmniejsza dostępność wektora i zasięg potencjalnego przejęcia.

Jak sprawdzić, czy doszło do nadużycia

Publiczny biuletyn nie podaje pełnych artefaktów exploita, dlatego dochodzenie powinno łączyć zachowania, logi i zmianę stanu:

1. Zachowaj logi aplikacji, reverse proxy, systemu i EDR przed restartem lub czyszczeniem.
2. Przejrzyj żądania do mechanizmów komunikacji agentów z nietypowych adresów i bez spodziewanego kontekstu agenta.
3. Wyszukaj procesy potomne serwera TeamCity, zwłaszcza interpretery poleceń, narzędzia transferu i skrypty uruchomione poza zadaniami build.
4. Porównaj konfigurację, pluginy, konta, tokeny i projekty z ostatnim zaufanym stanem.
5. Zweryfikuj artefakty zbudowane w oknie ryzyka, ich podpisy, provenance i publikację do rejestrów.
6. Rotuj sekrety osiągalne z procesu TeamCity, jeśli nie można wykluczyć kompromitacji.
7. Sprawdź repozytoria, registry i środowiska docelowe pod kątem użycia tych poświadczeń.

Sama informacja „nie znaleźliśmy pliku malware” jest niewystarczająca. Napastnik mógł wykorzystać legalne mechanizmy pipeline’u, zmienić konfigurację albo ukraść token i działać już z innego systemu.

Długofalowa architektura

Po aktualizacji warto przejść z sekretów długowiecznych na krótkotrwałe tożsamości workload, ograniczyć uprawnienia per projekt i wymagać niezależnego podpisywania lub weryfikacji artefaktów. Temat rozwijamy w przewodnikach po bezpieczeństwie CI/CD i OIDC dla workload identity.

Fakty źródłowe a wnioski Breachroad

Zakres wszystkich wydań On-Premises, brak uwierzytelnienia, agent polling, wersje poprawione i brak znanej aktywnej eksploatacji pochodzą bezpośrednio z JetBrains. Producent nie udostępnił w biuletynie szczegółów wystarczających do niezależnego odtworzenia ataku.

Wnioskiem Breachroad jest traktowanie TeamCity jako punktu kontroli łańcucha dostaw i objęcie dochodzeniem sekretów, artefaktów oraz systemów docelowych. Szkolenia dla zespołów deweloperskich i operacyjnych pomagają przećwiczyć taki scenariusz, a audyt bezpieczeństwa IT może zweryfikować ekspozycję, segmentację, sekrety i integralność pipeline’ów.