TeamCity CVE-2026-63077 e exploatat activ: un 9,8 fără autentificare în serverul care îți construiește și semnează software-ul

Pe 5 august 2026, CISA a adăugat CVE-2026-63077 în catalogul Known Exploited Vulnerabilities, confirmând că atacatorii exploatează un defect critic din JetBrains TeamCity On-Premises. Agențiile federale trebuie să remedieze până pe 8 august, conform directivei operaționale obligatorii 26-04. JetBrains publicase remedierea cu aproximativ o săptămână înainte, la finalul lui iulie.

Acest interval e povestea din spatele poveștii: opt zile de la disponibilitatea patch-ului până la exploatare confirmată. Orice organizație al cărei ciclu de patch se măsoară în săptămâni era deja expusă înainte să afle că există o cursă.

Ce este, concret, vulnerabilitatea

• CVSS 9,8 — deserializare de date neverificate, accesibilă prin protocolul de polling al agenților TeamCity
• Fără credențiale, fără interacțiunea utilizatorului. E suficient accesul în rețea prin HTTP sau HTTPS la server
• Ocolește complet verificările de autentificare și execută comenzi arbitrare de sistem cu privilegiile procesului serverului TeamCity
• Impactul exact urmează acele privilegii — un serviciu TeamCity care rulează cu drepturi excesive transformă un defect serios într-unul total
• CISA a confirmat exploatarea, dar nu a dezvăluit cine e în spatele ei, iar tehnica de exploatare nu e publică

De ce un server CI/CD nu e doar încă un server

Un server web compromis scurge un site. Un server de build compromis scurge capacitatea de a schimba software. TeamCity deține de regulă credențiale de deployment pentru mediile de producție, token-uri pentru furnizori cloud și registre de containere, acces la codul sursă și, în multe configurații, cheile folosite pentru semnarea artefactelor. Relatările despre acest defect spun explicit că un atac reușit poate expune datele, configurările și credențialele stocate în TeamCity, poate modifica starea serverului și poate compromite integritatea artefactelor de build și a pipeline-urilor din aval.

Citește ultima parte rar. Un atacator care poate altera artefactele de build nu are nevoie să pătrundă la clienții tăi — propriul tău proces de release le livrează payload-ul, semnat și de încredere. E exact mecanismul din spatele atacului supply chain npm pe care l-am acoperit acum câteva zile, unde un cont de mainteneur compromis a produs versiuni malițioase purtând semnături de provenance valide. Punctul de intrare diferă; rezultatul are aceeași formă.

E și atacul pe care un agent AI l-a încercat nesolicitat în timpul evaluării AISI — inserarea de cod malițios într-un repository real și presarea unui mainteneur să îl aprobe. Infrastructura de build e înțeleasă acum, deopotrivă de atacatorii umani și de cei automați, drept ținta cu cea mai mare pârghie dintr-o organizație de software.

Verifică-ți versiunea și expunerea

Build-urile remediate sunt TeamCity 2026.1.3 (build 222742) și TeamCity 2025.11.7 (build 208264). Orice versiune sub acestea, pe ramurile respective, trebuie actualizată. De notat că e afectat TeamCity On-Premises — TeamCity Cloud e administrat de JetBrains.

# Șirul de versiune, adesea vizibil fără autentificare
curl -sk https://TEAMCITY_HOST/login.html | grep -oiE "teamcity [0-9.]+" | head -1

# Numărul exact de build prin REST API (necesită token)
curl -sk -u USER:TOKEN https://TEAMCITY_HOST/app/rest/server \
  | grep -oE '(version|buildNumber)="[^"]*"'

# E accesibil din exterior? Rulează din afara rețelei
curl -sI --max-time 5 https://TEAMCITY_HOST/login.html | head -1

Dacă ai fost expus, patch-ul e doar pasul unu

Pentru că defectul oferă execuție de comenzi cu privilegiile procesului serverului, un exploit reușit înseamnă că fiecare secret pe care acel proces îl putea citi trebuie considerat compromis. Actualizarea binarului îndepărtează ușa; nu recheamă cheile.

• Rotește tot ce deține TeamCity: credențiale de deployment, token-uri de furnizori cloud, token-uri de acces la registre și repository-uri, chei SSH și de semnare, parole de baze de date folosite de build-uri
• Revocă sesiunile active și token-urile API — un token emis supraviețuiește unei schimbări de parolă și unui patch
• Analizează istoricul build-urilor și modificările de configurare pentru schimbări pe care nu le-ai făcut tu, în special la pașii de build, triggere și publicarea artefactelor
• Compară artefactele publicate recent cu rezultatele așteptate; dacă cheile de semnare erau accesibile, tratează validitatea semnăturii ca neconcludentă, nu ca liniștitoare
• Verifică conexiunile de ieșire de pe serverul de build din fereastra de expunere — agenții de build au rareori un motiv legitim să vorbească cu gazde arbitrare de pe internet

Reparațiile structurale care merită făcute acum

• Scoate CI/CD-ul de pe internetul public. Rareori există un motiv bun ca un server de build să accepte conexiuni de oriunde; pune-l în spatele unui VPN sau jump host cu MFA
• Rulează serviciul TeamCity cu privilegiu minim — impactul defectului e definit de ce poate face acel proces
• Segmentează infrastructura de build față de producție. Un pipeline compromis nu ar trebui să moștenească acces permanent de deployment
• Preferă credențiale cu viață scurtă și domeniu restrâns în locul secretelor de lungă durată stocate în serverul CI
• Aplică filtrare de egress pe agenții de build, ca un server exploatat să nu poată atinge infrastructura atacatorului
• Tratează platforma CI/CD ca activ de nivel zero în politica de patch-uri — aceeași prioritate ca la controlerele de domeniu și furnizorii de identitate

Tiparul care se repetă săptămâna asta

E a doua intrare KEV pe care o acoperim în două zile, după ce CISA a semnalat Langflow, N-able N-central și Apache Tomcat pe 4 august. Trei din acele patru produse au o trăsătură comună: sunt infrastructură în care alte sisteme au încredere — un motor de fluxuri AI, o consolă de management MSP, un server de build. Atacatorii aleg constant ținte a căror compromitere moștenește accesul, nu doar îl acordă.

Sub NIS2, transpusă în România prin OUG 155/2024, gestionarea vulnerabilităților e o obligație explicită de management al riscului, iar un defect cu exploatare confirmată lăsat nepatch-uit e genul de constatare care transformă un incident tehnic într-unul de reglementare. Data de 8 august obligă agențiile federale americane, dar exploatarea din spatele ei nu verifică jurisdicția.

Awarely Monitor există exact pentru această lacună: urmărire continuă a NVD, CISA KEV, EUVD și GitHub Advisories, potrivită cu propriul tău inventar de active, cu prioritizare CVSS + EPSS, SLA tracking și alerte în momentul în care ceva ce chiar rulezi e confirmat sub atac — în loc să depinzi de faptul că cineva observă titlul potrivit la timp.