TeamCity sub atac: de ce serverul de build este cea mai valoroasă mașină din companie

Pe 5 august 2026, CISA a adăugat CVE-2026-63077 în catalogul vulnerabilităților exploatate activ, cu termen de remediere pentru agențiile federale americane pe 8 august. Trei zile. Termenul obișnuit este de douăzeci și una — iar diferența spune mai mult despre gravitate decât scorul CVSS de 9.8.

Ce este, tehnic

• Clasă: deserializare de date neverificate (CWE-502), în protocolul prin care agenții de build interoghează serverul.
• Afectate: toate versiunile TeamCity On-Premises anterioare lui 2025.11.7 și 2026.1.3.
• Reparat în: TeamCity 2026.1.3 (build 222742) și 2025.11.7 (build 208264), publicate la sfârșitul lui iulie 2026.
• Versiunile găzduite de JetBrains în cloud nu intră în discuție — problema este a instalărilor proprii.

Un detaliu care schimbă modul în care trebuie să reacționezi: la momentul scrierii nu există informații publice despre atacuri — nu se știe cine exploatează, cum și la ce scară. Nu ai indicatori de compromitere după care să cauți. Asta înseamnă că nu poți răspunde cu „verific dacă am fost lovit"; trebuie să răspunzi cu „am fost expus sau nu".

De ce un server de build este ținta perfectă

Într-o organizație obișnuită, serverul de integrare continuă este mașina cu cea mai mare concentrare de putere și cea mai mică atenție de securitate. Are, prin construcție, tot ce îi trebuie unui atacator: credențiale de deploy către producție, chei de semnare, tokenuri către depozitul de cod, secrete pentru cloud și acces în rețea către mediile pe care le livrează. Nimeni nu se autentifică pe el zilnic, deci nimeni nu observă când se comportă altfel.

Consecința nu este o breșă, ci o poziție. Cine controlează serverul de build poate modifica artefactele pe care le produce — iar acele artefacte sunt, prin definiție, cele în care toată lumea din aval are încredere. Codul sursă rămâne curat, revizuirea de cod nu are ce să vadă, semnătura este validă pentru că este produsă de pipeline-ul legitim. Este exact structura atacului asupra pachetelor npm keyv și cacheable de acum două zile, unde versiunile otrăvite au avut semnături de provenance perfect valide pentru că atacatorul a lăsat pipeline-ul autentic să publice.

Nu este prima oară, și tiparul precedent este instructiv

În martie 2024, CVE-2024-27198 — tot TeamCity, tot scor 9.8, tot ocolire de autentificare care ducea la execuție de cod — a intrat în același catalog. A fost folosită în campanii de ransomware, iar atacatorii își creau conturi de utilizator proprii pe serverele compromise, ca să păstreze accesul după aplicarea patchului. Grupări afiliate unor state au exploatat de asemenea infrastructura TeamCity.

Ce faci, în ordinea asta

• Actualizează la 2025.11.7 sau 2026.1.3. Nu programa fereastra de mentenanță pentru săptămâna viitoare — exploatarea este activă acum.
• Verifică dacă serverul a fost accesibil din internet. Vulnerabilitatea cere doar acces HTTP la server, deci expunerea publică transformă o problemă gravă într-una critică. Un server de build nu are ce căuta pe internetul deschis; pune-l în spatele VPN-ului sau al unei liste de acces.
• Dacă a fost expus și nepatchuit, tratează-l ca fiind compromis. Rotește tot ce a deținut: chei de semnare, credențiale de deploy, tokenuri către depozitul de cod, chei cloud, secrete din pipeline. Rotația se face de pe o mașină curată.
• Caută conturi de utilizator pe care nu le-ai creat tu — tiparul din 2024. Verifică și configurațiile de build modificate și agenții necunoscuți înregistrați.
• Uită-te la artefactele produse în fereastra de expunere. Dacă ceva a fost livrat din acel server către clienți, este o discuție de notificare, nu doar de remediere.

Măsura care ține pe termen lung

Cea mai eficientă schimbare structurală este să nu mai existe secrete permanente pe serverul de build. Identitatea federată cu durată scurtă — OIDC — înlocuiește cheile de acces care stau acolo la nesfârșit cu tokenuri valabile câteva minute, limitate la exact ce are nevoie job-ul respectiv. Nu împiedică compromiterea serverului, dar schimbă radical ce obține atacatorul: în loc de chei cloud permanente, un token care expiră înainte să apuce să îl folosească pe scară largă.

A doua măsură este semnarea artefactelor cu chei care nu se află pe mașina care construiește. Iar a treia, cea mai simplă și cel mai des ignorată: pune infrastructura de build în inventarul de active și în procesul de patch management, la același nivel de prioritate cu serverele de producție. În multe organizații, CI/CD-ul este administrat de echipa de dezvoltare și rămâne, tacit, în afara ciclului de securitate — până în ziua în care devine calea de intrare.

Ce înseamnă termenul de trei zile

Catalogul CISA are, pentru majoritatea intrărilor, un termen de remediere de trei săptămâni. Când agenția scurtează la trei zile, semnalează că evaluează exploatarea ca fiind activă, accesibilă și cu impact mare. Pentru organizațiile din afara Statelor Unite, care nu au nicio obligație legală față de acest catalog, termenul rămâne cel mai bun indicator public de prioritizare pe care îl poți obține gratuit. „Este în KEV, cu termen scurt" bate orice scor CVSS.