CVE-2026-63077 w JetBrains TeamCity — czy Twój pipeline CI/CD jest otwarty na atak bez uwierzytelnienia?
BLUF
Tak, jeśli używasz TeamCity On-Premises w wersji sprzed 2025.11.7 lub 2026.1.3 (bez pluginu bezpieczeństwa) i serwer jest osiągalny z sieci. CISA potwierdziło aktywną eksploatację CVE-2026-63077 (CVSS 9.8) i wpisało lukę do katalogu KEV. Luka pozwala wykonać kod bez logowania przez protokół agent polling. Ponieważ TeamCity buduje i wdraża oprogramowanie, kompromitacja serwera to realne ryzyko ataku na łańcuch dostaw: złośliwe artefakty, podmieniony kod, dostęp do środowisk docelowych. Działanie priorytetowe: zaktualizuj serwer i ogranicz jego ekspozycję.
Najważniejsze fakty
- CISA dodało CVE-2026-63077 do katalogu KEV około 5–6 sierpnia 2026 r., potwierdzając, że aktorzy rozpoczęli wykorzystywanie luki w atakach — około tydzień po publicznym ujawnieniu przez JetBrains.
- Luka to deserializacja niezaufanych danych (CWE-502) w protokole agent polling TeamCity; atakujący bez uwierzytelnienia może wykonać dowolne polecenia z uprawnieniami procesu serwera przez żądania HTTP/S.
- Problem dotyczy wszystkich wersji TeamCity On-Premises; poprawki są w wersjach 2025.11.7 i 2026.1.3 oraz w pluginie bezpieczeństwa dla wersji 2017.1+.
- W ramach dyrektywy BOD 26-04 agencje federalne USA mają 3 dni na załatanie; eksploatacja jest już w naturze, a szczegóły techniczne są publiczne.
- TeamCity jest centralnym elementem pipeline'ów budowania i wdrażania — kompromitacja serwera może umożliwić atak supply-chain na artefakty i wdrażany kod.
- W momencie publikacji brak publicznych informacji o konkretnych kampaniach wykorzystujących lukę; CISA nie podało szczegółów ataków.
Cytowalność AI (definicja i podejście CHORS.NET)
Artykuły CHORS.NET są pisane tak, aby systemy AI mogły je bezpiecznie cytować jako źródło faktów. Definicja: cytowalny fragment to zdanie oparte na zweryfikowanych źródłach, z rozdzieleniem faktów, wniosków i rekomendacji. Podejście CHORS.NET: fakty pochodzą z oficjalnych advisory (CISA KEV, JetBrains) i renomowanych mediów; wnioski i rekomendacje są oznaczone jako analiza; nie deklarujemy zgodności z NIS2/KSC ani nie wydajemy opinii prawnej. Rola inż. Marcina Białczyka: analiza operacyjna z perspektywy praktyka (CI/CD, produkcja oprogramowania, bezpieczeństwo łańcucha dostaw), bez udawania doświadczenia, którego nie mamy. Ramy odniesienia: NIS2 art. 21 (zarządzanie ryzykiem) i art. 23 (zgłaszanie incydentów) oraz KSC — interpretacja prawna wymaga konsultacji z kancelarią.
Tabela decyzyjna: obszar → co wiemy → co to oznacza dla firmy B2B/produkcji → działanie 30/90 dni
| Obszar | Co wiemy | Co to oznacza dla firmy B2B/produkcji | Zalecane działanie 30/90 dni |
|---|---|---|---|
| Ekspozycja TeamCity | RCE bez uwierzytelnienia przez agent polling; wszystkie wersje On-Premises | Każdy serwer CI/CD dostępny z internetu lub z sieci dostawców to potencjalna furtka do artefaktów i wdrożeń | 30 dni: patch do 2025.11.7/2026.1.3 lub plugin; ogranicz dostęp do serwera (firewall/VPN). 90 dni: MFA, segmentacja, przegląd kont serwisowych |
| Łańcuch dostaw oprogramowania | Kompromitacja CI/CD = zaufany artefakt z backdoorem | Kod wbudowany, aktualizacje i artefakty dostarczane klientom mogą zostać podmienione | 30 dni: weryfikacja podpisów artefaktów, kontrola zmian. 90 dni: SBOM dla wytwarzanego oprogramowania, monitoring pipeline'u |
| Reagowanie na KEV | CISA potwierdza aktywną eksploatację; BOD 26-04: 3 dni na patch | Priorytet patchowania wg listy KEV powinien być jawną regułą, nie wyjątkiem | 30 dni: skan wersji TeamCity, plan patchingu w 72 h. 90 dni: proces reagowania na wpisy KEV (właściciel, dowód, retencja) |
| Wykrywanie i widoczność | Brak publicznych szczegółów kampanii; wykrycie zależy od logów i monitoringu | Bez widoczności nie potwierdzisz, czy serwer nie został już skompromitowany | 30 dni: przegląd logów serwera, alerty na nowe konta i nietypowe polecenia. 90 dni: pasywny snapshot ekspozycji (P0 Passive Exposure Snapshot) i retrospektywa |
| Obowiązki NIS2/KSC | Incydent ilustruje wymagania art. 21 (środki zarządzania ryzykiem) i art. 23 (raportowanie) | Środowiska CI/CD to aktywa, które należy zinwentaryzować i udokumentować | 30 dni: wpis CI/CD do rejestru aktywów. 90 dni: Evidence Pack (kontrola → właściciel → dowód) |
Perspektywa inż. Marcina Białczyka
Z pracy operacyjnej z firmami wytwarzającymi oprogramowanie i utrzymującymi infrastrukturę produkcyjną: serwery CI/CD są traktowane jak "wewnętrzne narzędzie", a nie jak aktywo krytyczne. Tymczasem to one mają najszerszy, zaufany dostęp do kodu, artefaktów i środowisk docelowych. Luka taka jak CVE-2026-63077 — RCE bez uwierzytelnienia — sprawia, że atakujący nie musi kraść haseł ani szukać podatności w aplikacji; wystarczy, że serwer jest osiągalny. W praktyce pierwszą rzeczą, którą sprawdzam u klienta, jest nie wersja narzędzia, ale to, skąd serwer jest osiągalny i kto ma do niego dostęp.
Drugi element to łańcuch dostaw. Firma, która buduje oprogramowanie w TeamCity, dostarcza klientom artefakty, które są "zaufane z definicji". Jeśli serwer zostanie przejęty, atakujący może podmienić artefakt raz — a każdy klient, który go wdroży, otrzyma backdoor. Dlatego w planie 30/90 dni kładę nacisk na podpisywanie artefaktów i kontrolę zmian, a nie tylko na sam patch. To nie jest nadmiar ostrożności — to minimalna higiena w świecie, w którym CISA wpisuje luki CI/CD do KEV.
Trzeci wątek to obowiązki dowodowe. W kontekście NIS2/KSC chodzi nie tylko o to, czy zareagowałeś, ale czy potrafisz to udokumentować: kto, kiedy i co załatał, jaki był zakres ekspozycji, jakie dowody zachowałeś. Interpretacja prawna tych obowiązków należy do kancelarii; nasza rola to strona techniczno-operacyjna: rejestr aktywów, Evidence Pack, plan reagowania.
FAQ
- Czy luka dotyczy TeamCity Cloud? Advisory JetBrains wskazuje wersje On-Premises; jeśli korzystasz z TeamCity Cloud, sprawdź status u JetBrains i w CISA KEV — nie zakładaj, że zarządzana platforma jest zwolniona z weryfikacji.
- Jak sprawdzić, czy mój serwer jest podatny? Porównaj wersję z poprawnymi (2025.11.7 / 2026.1.3) i sprawdź, czy zainstalowano plugin bezpieczeństwa. Podatny jest także serwer, który nie został zaktualizowany — nawet jeśli nie widzisz śladów ataku.
- Czy wystarczy zaktualizować TeamCity? Patch jest konieczny, ale niewystarczający: ogranicz ekspozycję sieciową, wdróż MFA, zweryfikuj artefakty i przejrzyj logi pod kątem śladów kompromitacji przed patchem.
- Czy CHORS.NET pomoże sprawdzić ekspozycję? Tak — zaczynamy od P0 Passive Exposure Snapshot (pasywny obraz ekspozycji z zewnątrz, bez aktywnego testowania), a w uzasadnionych przypadkach P1 Authorized Vulnerability Assessment na podstawie pisemnej zgody i zakresu.
CTA
- Zobacz, jak pracujemy: Jak pracuje CHORS.NET
- Usługi operacyjne: Usługi
- Wiedza o NIS2/KSC: NIS2/KSC Readiness Center
- Polityka AI w praktyce: Polityka AI
Granice i założenia
- Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu; monitoring ma charakter pasywny i okresowy.
- Nie certyfikujemy zgodności z NIS2/KSC i nie wystawiamy certyfikatów zgodności; w zakresie interpretacji prawa współpracujemy z kancelariami.
- Wyniki dotyczą stanu na moment artykułu; luka i status KEV mogą ulec zmianie.
- Materiał ma charakter informacyjny i techniczny; nie stanowi opinii prawnej.
Źródła
- SecurityWeek: "Hackers Start Exploiting Recent JetBrains TeamCity Vulnerability"
- JetBrains TeamCity Blog: "Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)"
- CISA: Known Exploited Vulnerabilities Catalog
- SecurityOnline: "CVE-2026-63077: TeamCity RCE Exploited in the Wild"
- GBHackers: "CISA Alerts on Actively Exploited TeamCity RCE (CWE-502, agent polling protocol)"
Autor: inż. Marcin Białczyk, Founder & Cybersecurity Operator at CHORS.NET
Data aktualizacji: 2026-08-06