28 sierpnia 2026 JetBrains opublikował informację, która powinna zainteresować każdego, kto zajmuje się Vulnerability Management bardziej niż kolejnym Critical CVE. Problem był znany. Miał CVE. Vendor opublikował poprawkę i security patch plugin. Później pojawiły się raporty o aktywnej eksploatacji, a JetBrains ostrzegał użytkowników TeamCity, by aktualizowali natychmiast. A jednak jeden z serwerów używanych przez JetBrains pozostał podatny — i został skutecznie zaatakowany.
W komunikacie o incydencie Cadence JetBrains napisał wprost: „The server should have been patched as part of our response to the vulnerability, but it was not." To jedno zdanie jest bardzo mocną lekcją. Bo proces nie kończy się na CVE identified → advisory published → patch available → ticket created. Kończy się dopiero, gdy jesteśmy w stanie udowodnić:
Cadence pokazuje, co dzieje się między „powinno być naprawione" a „rzeczywiście jest naprawione".
Co wydarzyło się z TeamCity?
CVE-2026-63077 dotyczy TeamCity On-Premises — krytyczna luka pozwalająca nieuwierzytelnionemu atakującemu z dostępem HTTP(S) do serwera na wykonanie dowolnych poleceń systemowych z uprawnieniami procesu TeamCity. Wg advisory: problem dotyczył wszystkich wersji On-Premises, poprawki w 2025.11.7 i 2026.1.3, dla klientów bez pełnego upgrade'u przygotowano security patch plugin (TeamCity 2017.1+), a TeamCity Cloud nie wymagał działań klienta. To ważne: nie mieliśmy „critical vulnerability / patch unavailable / vendor silent", tylko „critical vulnerability / vendor knows / fixed versions available / alternative patch available / guidance published". Klasyczny VM powinien poradzić sobie relatywnie dobrze. A jednak nie poradził w 100%.
W pierwotnym komunikacie nie było jeszcze informacji o exploitation — standardowa sytuacja. Dojrzały VM powinien wtedy ocenić severity, exposure, criticality, rolę TeamCity w CI/CD, możliwość patcha i mitigation. Już wtedy TeamCity trzeba traktować poważnie, bo CI/CD to nie zwykła aplikacja — serwer buildowy może mieć dostęp do repozytoriów, tokeny package registries, klucze deploymentowe, dostęp do chmury, sekrety buildów i kontrolę nad artifact pipeline. Kompromitacja TeamCity może więc nie kończyć się na TeamCity — może stać się punktem wejścia do software supply chain. Gdy pojawiły się realne ataki, threat context zmienił się fundamentalnie: proces powinien przejść z „high-priority vulnerability" do confirmed active exploitation → emergency re-triage. Każdy otwarty finding dla CVE-2026-63077 należy ponownie ocenić, każdy exception sprawdzić, a każdy asset oznaczony „patched" powinien mieć weryfikowalny dowód.
Cadence: vendor padł ofiarą własnego CVE
Cadence to usługa JetBrains związana z PyCharm, pozwalająca uruchamiać projekty na zasobach chmurowych; do orkiestracji workloadów używała TeamCity. 28 sierpnia JetBrains potwierdził, że serwer api.cadence.jetbrains.com był podatny na CVE-2026-63077 i został wykorzystany przez threat actors. Aktywność zidentyfikowano od 8 sierpnia 2026, JetBrains odkrył exploitation 23 sierpnia, a dzień później wyłączył serwer — affected period 8–24 sierpnia. To szerokie okno i nie był to incydent ograniczony do samego hosta. JetBrains potwierdził m.in. dostęp do danych osobowych, przejęcie pełnego backupu Cadence z 2024 roku, kompromitację wielu AWS IAM users i ich secrets, dostęp do plików w bucketach S3 oraz możliwy dostęp do kodu synchronizowanego z projektów PyCharm.
Vendor nakazał traktować jako potencjalnie przejęte m.in.: AWS/Azure/GCP credentials, tokeny GitHub/GitLab/Bitbucket, credentials npm/Maven/NuGet/PyPI, container registry credentials, Slack tokens, webhooks, API tokens, SSH/deployment keys, service account credentials oraz signing keys i certyfikaty. To pokazuje, jak szeroki może być blast radius jednej nienaprawionej podatności w CI/CD. Szczególnie pouczający jest backup z 2024 roku — na pierwszy rzut oka „stary", ale dla atakującego wciąż wartościowy (konfiguracje, historyczne tokeny, hasła, klucze, sekrety, logi). Nie każdy sekret będzie aktualny, ale część może być — dlatego JetBrains zalecił traktować przechowywane w nim credentials jako potencjalnie przejęte. Lekcja: backup jest również elementem attack surface, nie tylko aktywny serwer produkcyjny.
Remediation failure, a nie tylko vulnerability failure
Łatwo powiedzieć „TeamCity miał krytyczne RCE" — ale to nie najważniejsza historia. Luka była znana, poprawka była znana, alternatywny security patch istniał, vendor ostrzegał (także o aktywnych atakach), a mimo to konkretny asset pozostał podatny. To remediation failure — nie w sensie „patch didn't work", tylko „proces nie zapewnił, że patch dotarł do każdego wymaganego assetu". Fundamentalna różnica. W wielu organizacjach workflow to scanner → ticket → owner → In Progress → Done, a problem w tym, że Done jest deklaracją workflow, nie technicznym dowodem. Owner mógł zaktualizować zły serwer, pominąć jeden node klastra, poprawić staging zamiast produkcji, zainstalować patch bez aktywacji, zaplanować upgrade, który nie doszedł do skutku, zaktualizować CMDB zamiast hosta, oznaczyć ticket jako Done na podstawie change requestu albo nie wiedzieć o istnieniu dodatkowego assetu.
Dowodem remediation — zależnie od typu podatności — może być rescan, potwierdzenie wersji, runtime inventory, attestation z pipeline, configuration evidence, API check, package manager state, agent telemetry, test exploitability albo ręczna walidacja. Dla CVE-2026-63077 prosto: TeamCity version >= fixed version albo security patch plugin installed and active — ale i tak trzeba sprawdzić każdy asset, nie tylko dokumentację zmiany. Dlatego warto rozdzielić dwa statusy: Owner status: REMEDIATION_REPORTED od Security status: REMEDIATION_VERIFIED. Jeśli owner zgłasza „patch deployed", a automated validation wykrywa „still vulnerable" → VERIFICATION_FAILED, finding nie powinien zostać zamknięty.
Coverage jest ważniejsze niż sam closure rate
Jeszcze poważniejszy niż nieskuteczny patch jest asset, o którym VM nie wie — nie ma go w CMDB, nie obejmuje go scanner, nie zna zespół security, funkcjonuje jako shadow infrastructure. Wtedy dashboard może pokazać „100% findings remediated", a podatny system pozostaje poza mianownikiem — najbardziej niebezpieczna forma „100% compliance". Przykład: Known TeamCity assets: 99 / Patched: 99 / Compliance: 100%, ale istnieje setny serwer → realnie Actual: 100 / Patched: 99 / Exposure: 1 vulnerable. Dlatego VM powinien mierzyć równocześnie inventory completeness, detection coverage, remediation coverage i verification coverage. Po pojawieniu się active exploitation właściwy workflow to nie zwykłe patch management, lecz połączenie VM, asset management, detection engineering i incident response:
Sekrety i artefakty są częścią remediation
Patchowanie hosta po kompromitacji nie kończy problemu. Jeśli attacker zdążył uzyskać token, hasło, access key, SSH key albo signing key, to patch usuwa wejście, ale credential może nadal działać. Po realnej exploitation remediation staje się dwutorowe: vulnerability remediation + compromise remediation — patch, containment, credential/token/secret rotation, audyt systemów zewnętrznych, przegląd repo i artefaktów oraz cloud IAM review. Co więcej, TeamCity jest częścią procesu wytwarzania oprogramowania — jeśli attacker przejął CI/CD, pytanie brzmi nie tylko „co ukradł?", ale „co mógł zmienić?" (build scripts, artifacts, dependencies, deployment packages, container images, pipeline configuration). Dlatego JetBrains zalecił traktowanie wykonanych procesów, ich inputs i outputs jako potencjalnie niezaufanych — ogromna różnica wobec kompromitacji zwykłego serwera WWW.
Kiedy finding naprawdę można zamknąć? Gdy: asset still exists, affected state confirmed, remediation deployed i technically verified, asset inventory updated, exposure re-evaluated, no additional affected nodes remain. Jeśli wystąpiła exploitation, dochodzi: compromise assessment completed, credentials rotated/revoked, connected systems reviewed, artifacts/code assessed. Dopiero wtedy „closed" ma realne znaczenie. Dotyczy to też wyjątków — jeśli zespół miał 30-dniowy exception, a później vendor potwierdza active exploitation, to formalnie może być ważny, ale threat context się zmienił: material_change_in_risk → mandatory_exception_review (triggery: active exploitation, publiczny exploit, KEV, nowy attack path, zmiana exposure, wzrost criticality).
KPI też trzeba zmienić
Klasyczne KPI (MTTR, liczba open Critical, SLA compliance) są potrzebne, ale Cadence pokazuje, że warto mierzyć również: Verified Remediation Rate (jaki % zamkniętych ma techniczne potwierdzenie?), Asset Coverage (jaki % rzeczywistych assetów jest w procesie VM?), Revalidation Coverage (czy po zmianie threat context sprawdziliśmy ponownie wszystkie affected assets?), Exception Reassessment Rate i Secret Exposure Response Time. A po takim incydencie VE nie powinien sprawdzić tylko własnego TeamCity — warto zrobić retrospektywę procesu: czy znamy wszystkie instancje, czy skaner je widzi, czy CI/CD ma właścicieli, czy po patchu robimy rescan, czy zamknięcie wymaga dowodu, czy Critical można zamknąć ręcznie bez walidacji, czy exceptions są re-oceniane po exploitation, czy mamy osobny workflow dla KEV, czy backupy są w inventory, czy wiemy jakie sekrety są w CI/CD i czy umiemy je szybko rotować.
Najważniejsza lekcja
Remediation, której nie zweryfikowaliśmy, jest tylko deklaracją.
Vendor może znać CVE, stworzyć patch, opublikować advisory i ostrzec przed atakami — a mimo to zostawić własny asset podatny. To nie kompromituje idei Vulnerability Management. Pokazuje, gdzie VM najczęściej zawodzi: między wiedzą a wykonaniem. Dlatego dojrzały proces nie kończy się statusem PATCH PLANNED, CHANGE COMPLETED ani nawet OWNER CONFIRMED. Kończy się na REMEDIATION VERIFIED — a dla systemu takiego jak TeamCity jeszcze później: REMEDIATION VERIFIED + COMPROMISE ASSESSED + SECRETS ROTATED + DOWNSTREAM TRUST RESTORED. Dopiero wtedy podatność naprawdę przestaje być tylko numerem w backlogu.
Źródła
- JetBrains — „Security Incident Affecting JetBrains Cadence" (aktualizacja 28 sierpnia 2026, 11:50 CEST) — blog.jetbrains.com
- JetBrains TeamCity — „Critical Security Issue Affecting TeamCity On-Premises (CVE-2026-63077)" — blog.jetbrains.com/teamcity
- JetBrains TeamCity — „CVE-2026-63077: Additional Guidance Following Reports of Active Exploitation" — blog.jetbrains.com/teamcity
Nota redakcyjna: artykuł opisuje publicznie dostępny stan informacji na 28 sierpnia 2026, 14:30 CEST. JetBrains zaznacza, że dochodzenie dotyczące Cadence nadal trwa i może publikować kolejne ustalenia. Wnioski procesowe dotyczące VM są analizą VMRT opartą na potwierdzonych faktach i komunikatach producenta.