Kto wejdzie na serwer budujący oprogramowanie, dostaje znacznie więcej niż jedną maszynę. Taka maszyna przechowuje zwykle dane, konfigurację i poświadczenia potrzebne w całym procesie budowania i wdrażania. Bez nich nie złożyłaby ani jednej wersji programu, a zakres szkód po wejściu zależy od tego, jak szeroko jest w danej firmie podpięta. Dokładnie tam prowadzi luka w TeamCity, serwerze ciągłej integracji od JetBrains. Amerykańska agencja CISA wpisała ją 5 sierpnia do katalogu podatności aktywnie wykorzystywanych. Swoim urzędom dała trzy dni na reakcję, do 8 sierpnia. Napastnik nie potrzebuje ani konta, ani hasła, wystarczy mu dostęp sieciowy do serwera. Poprawki wyszły pod koniec lipca, więc pierwsze zadanie na dziś to sprawdzenie wersji serwera.
Co dokładnie łamie luka w TeamCity
Serwer nie pracuje sam. Zadania budowania rozdziela między agentów, czyli osobne maszyny, które pobierają kod, kompilują go i odsyłają wynik. Rozmawiają ze sobą protokołem odpytywania agentów i to w nim siedzi błąd. Serwer odtwarza obiekty z danych przysłanych w tym protokole, a napastnik omija po drodze kontrolę uwierzytelnienia.
Klasa tego błędu nazywa się deserializacją niezaufanych danych i ma w katalogu słabości numer CWE-502. Brzmi to niegroźnie, dopóki nie rozłoży się na czynniki samego odtwarzania obiektu. Program dostaje ciąg bajtów i buduje z niego strukturę w pamięci, uruchamiając po drodze fragmenty własnego kodu. Kto kontroluje te bajty, ten decyduje, który fragment się uruchomi.
Skutek CISA opisuje jednym zdaniem: nieuwierzytelnione zdalne wykonanie kodu przez protokół odpytywania agentów. Polecenia lecą z uprawnieniami procesu serwera. Rapid7 ocenia lukę na 9,8 w dziesięciostopniowej skali CVSS i zwraca uwagę na drugą konsekwencję. Napastnik może sięgnąć po poświadczenia przechowywane na tej maszynie, a więc po klucze do miejsc, w których serwer normalnie pracuje.
Które wersje TeamCity są bezpieczne
Ostrzeżenie producenta opisuje zakres bez półśrodków: podatne są wszystkie wydania TeamCity On-Premises. Poprawki wyglądają tak:
- 2025.11.7 i 2026.1.3 – dwie gałęzie z zamkniętym błędem.
- 2017.1 i nowsze – producent wydał osobną wtyczkę łatającą dla tych, u których pełna aktualizacja nie wchodzi w grę.
- 2024.03 i nowsze – tę wtyczkę można założyć automatycznie z panelu administracyjnego, bez ręcznego pobierania.
- TeamCity Cloud – według producenta klienci nie muszą robić nic, bo zabezpieczenia zostały już wdrożone po stronie usługi.
Numer wydania widać w panelu administracyjnym serwera. Sam numer nie przesądza jednak sprawy, bo wtyczka łatająca działa również na starszych wydaniach. Bezpieczny stan to jedno z dwóch: zaktualizowany serwer albo aktywna wtyczka.
Aktualizacja zamyka drogę wejścia, ale nie odpowiada na drugie pytanie: czy ktoś zdążył z niej skorzystać wcześniej. Publicznej listy śladów po tym ataku nikt na razie nie opublikował, więc gotowej instrukcji sprawdzenia nie ma. Jedno wynika jednak z samej natury poprawki. Nie unieważnia ona poświadczeń, które serwer przechowuje, więc przy podejrzeniu wcześniejszego wejścia trzeba je wymienić osobno.
Termin 8 sierpnia nie dotyczy polskich firm
Katalog, do którego trafiła ta podatność, prowadzi amerykańska agencja do spraw cyberbezpieczeństwa i infrastruktury. Wpis oznacza tam jedno: agencja ma podstawy sądzić, że luka jest wykorzystywana w prawdziwych atakach, a nie opisana wyłącznie w laboratorium. Data 8 sierpnia wynika z dyrektywy o nazwie BOD 26-04 i wiąże amerykańskie urzędy federalne. Polska firma nie ma z tego tytułu żadnego obowiązku prawnego.
Dwóch rzeczy agencja natomiast nie mówi i lepiej powiedzieć to wprost. Nie podaje, kto stoi za atakami ani jaka jest ich skala. W polu opisującym użycie w kampaniach szyfrujących dane katalog ma wpisane “nieznane”. Nie istnieje też żadna publiczna liczba podatnych serwerów w Polsce, więc każdy, kto taką liczbę poda, ją zmyśli.
Osobnego wyjaśnienia wymaga to, dlaczego łatka jest starsza niż alarm. Publikując własne ostrzeżenie w lipcu, JetBrains napisał, że nie ma wiedzy o aktywnym wykorzystaniu tej luki. Między tamtym zdaniem a wpisem do katalogu stan się zmienił. Kiedy dokładnie i w jaki sposób zaczęły się ataki, nie podaje żadne ze źródeł. Praktyczny wniosek zostaje ten sam: okno między wydaniem poprawki a jej założeniem u siebie jest dokładnie tym czasem, o który tu chodzi.
Frontend Master 2026 · Kodożercy
Frontend dla osób, które chcą pisać kod, nie tylko prompty
Frontend Master 2026 to pakiet, który daje Ci fundamenty potrzebne w pierwszej pracy frontendowej. HTML, CSS, JavaScript, Git – polskie wideo, projekty, ścieżka od początku do deploy.
Zobacz program kursów →
Trzeci w sierpniu atak na zaufane ogniwo łańcucha dostaw
Sierpień nie ma jeszcze tygodnia, a to już trzeci opisywany przypadek, w którym celem jest zaufane narzędzie z szerokimi uprawnieniami, nie sam kod. Najpierw zainfekowane paczki npm w kampanii Shai-Hulud, gdzie napastnicy przejęli publikowanie bibliotek. Potem system zdalnego zarządzania N-able N-central, w którym pierwsza poprawka nie zablokowała drugiej drogi do tego samego błędu. Teraz serwer ciągłej integracji.
Wspólny mianownik jest prosty i niewygodny. Ciągła integracja i wdrażanie opierają się na automatyzacji, a automatyzacja potrzebuje stałych dostępów. Człowiek loguje się do repozytorium raz na jakiś czas i po pracy zamyka laptopa. Serwer budujący ma tam wejście przez całą dobę i nikt tego nie kwestionuje, bo inaczej nic by się nie zbudowało.
Stąd bierze się nieproporcjonalność skutków. Zasięg zależy od uprawnień, z jakimi chodzi proces serwera, więc nie jest tak, że jedna niezałatana maszyna automatycznie oddaje całą firmę. Może natomiast ujawnić przechowywane poświadczenia i naruszyć integralność tego, co ta firma wypuszcza na zewnątrz. Jej klienci dostają potem poprawnie zbudowane paczki, którym nie mają powodu nie ufać.
Rosyjski wywiad i ten sam produkt: sprawa sprzed dwóch lat
Nazwa JetBrains pojawiła się już raz w polskich ostrzeżeniach państwowych i jest to osobna historia, nie ciąg dalszy tej. 13 grudnia 2023 CERT Polska razem ze Służbą Kontrwywiadu Wojskowego i partnerami zagranicznymi ostrzegły, że rosyjska Służba Wywiadu Zagranicznego wykorzystuje w tym produkcie podatność o numerze CVE-2023-42793. Zalecenie brzmiało wtedy twardo. Kto nie zaktualizował na czas, powinien założyć, że mógł zostać zhakowany, i szukać śladów u siebie. Tamten błąd ma inny numer i inny rok, a sprawca był tam nazwany. Tu nie jest. Wspólne pozostaje samo pytanie, dlaczego akurat serwery budujące oprogramowanie trafiają na listy ostrzeżeń tak regularnie.
Podsumowanie
Sprawdzenie, w jakim stanie jest serwer TeamCity, zajmuje minutę i dla większości zespołów tym się ta sprawa kończy. Poprawki noszą numery 2025.11.7 oraz 2026.1.3, a kto nie może zaktualizować serwera, zakłada wtyczkę łatającą dostępną dla wydań od 2017.1. Sam numer wydania nie rozstrzyga więc wszystkiego, bo starsza instalacja z aktywną wtyczką również jest zabezpieczona. Wiadomo, że błąd polega na deserializacji niezaufanych danych w protokole odpytywania agentów i że pozwala wykonać polecenia bez logowania. Nie wiadomo natomiast, kto z niego korzysta ani ilu firm to dotknęło, bo agencja podaje sam fakt wykorzystywania i nic ponadto. Termin 8 sierpnia obowiązuje amerykańskie urzędy federalne, nie polskie zespoły. Kolejność zadań wychodzi jednak taka sama: najpierw ta jedna maszyna, potem reszta listy.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
