El teu CI/CD té les claus de producció. I el tractes com una eina de desenvolupament

El 27 de juliol JetBrains va publicar un avís curt sobre TeamCity On-Premises. Un 9,8. Sense autenticació. Totes les versions. Un atacant amb accés HTTP al servidor executa ordres del sistema operatiu i s'ha acabat la conversa. La fallada es pedaça en una tarda; el que costa més és assumir on ha caigut. A la màquina que guarda les credencials per escriure a la resta dels teus servidors i que, a més, signa i publica el que els teus clients acaben executant. Aquí el compromís deixa de ser un problema d'accés i passa a ser-ho d'integritat: no és que t'entrin, és que a partir d'aquell moment no saps què has lliurat. I aquesta màquina gairebé mai no apareix a l'inventari de sistemes crítics de ningú. No tenim cap enquesta que ho quantifiqui. Tenim els servidors que hem vist.

CVE-2026-63077, en una pantalla

Abans d'opinar, els fets tal com els publica el fabricant. Sense adorns i sense la paraula «catastròfic», que no aporta res:

El va reportar en privat el 10 de juliol l'investigador Antoni Tremblay, JetBrains el va publicar el 27 i Rapid7 va treure comprovacions per als seus productes l'endemà demanant prioritzar-ho amb urgència. Disset dies entre l'avís privat i el públic: això és una divulgació coordinada feta com cal, i convé dir-ho quan passa.

La frase que cal llegir dues vegades és la del mateix fabricant sobre l'impacte: un atac amb èxit pot «exposar dades, configuracions i credencials emmagatzemades de TeamCity, modificar l'estat del servidor i potencialment comprometre la integritat dels artefactes de compilació i de les cadenes CI/CD posteriors». Aquí hi ha tot l'article resumit per JetBrains: credencials emmagatzemades, integritat dels artefactes, cadenes posteriors.

Què caduca abans: el «sense explotació coneguda» o la teva finestra de manteniment

Aquesta línia de l'avís és la que fa que una CVE es quedi a la llista de «per al setembre». Amb TeamCity concretament, l'historial no permet aquest luxe, i són dos episodis documentats per organismes públics i per resposta a incidents, no rumors de fòrum.

• CVE-2023-42793 (també un 9,8, també un salt d'autenticació, corregit a 2023.05.4). El 13 de desembre del 2023, CISA, l'FBI, l'NSA, el servei de contraintel·ligència militar polonès, CERT.PL i l'NCSC britànic van signar un avís conjunt: actors de l'SVR rus —APT29, Cozy Bear, Midnight Blizzard, el mateix grup amb molts noms— des del setembre del 2023 el feien servir per entrar, escalar privilegis, moure's lateralment, deixar portes del darrere i quedar-s'hi. A escala, i amb les empreses tecnològiques com a objectiu preferent.
• CVE-2024-27198, un altre salt d'autenticació de 9,8, publicat el 4 de març del 2024 juntament amb la CVE-2024-27199. Aquell mateix mes GuidePoint va documentar els operadors del ransomware BianLian entrant per TeamCity, donant-se d'alta usuaris al mateix producte i executant ordres sota el seu compte de servei. Els seus analistes van deixar escrit que no van poder determinar si l'entrada va ser per la CVE-2024-27198 o per la CVE-2023-42793 anterior, perquè els registres necessaris ja no hi eren: un detall que diu força sobre quant es conserva del que passa en un servidor de build. Pel mateix forat del 2024 hi van passar després, segons Trend Micro, el ransomware Jasmin, miners XMRig i portes del darrere SparkRAT.

Siguem justos amb l'argument: això no demostra que la CVE-2026-63077 s'acabi explotant. Potser no passa res. El que diu l'historial és una altra cosa, més modesta i més útil: quan apareix un salt d'autenticació amb execució remota en un servidor de compilació exposat, el buit entre l'avís i el primer incident s'ha mesurat abans en setmanes, no en trimestres. Amb aquest antecedent, deixar-ho per a la finestra de manteniment del setembre és una decisió que algú signa. Que se signi sabent què se signa.

Per què un servidor de build és un objectiu tan bo

Pensa en el que hi ha dins del CI/CD de la teva empresa ara mateix. No en teoria: obre la pantalla de variables i mira-ho. Sol haver-hi claus SSH que entren als servidors de producció, tokens del registre de contenidors amb permís d'escriptura, credencials de la base de dades per a les migracions, un token de l'API del proveïdor de núvol, la signatura dels artefactes i, amb sort, algun secret de client que algú va posar «temporalment» fa dos anys.

Ara suma-hi la segona propietat, que és la que ho fa especial: un servidor de CI/CD executa codi arbitrari com a funció principal. Un agent de compilació és, literalment, execució remota autoritzada. No hi ha cap «mode segur» per activar, perquè executar és el producte. Per això, qui entra al servidor de build no necessita moure's lateralment enlloc: ja és a l'única màquina de la casa que té permís per escriure a totes les altres, i a sobre qualsevol cosa rara que faci s'assemblarà força a un desplegament.

El tercer ingredient no l'arregla cap versió, i és el que de debò fa mal: és de governança. El CI/CD no és de ningú. El va muntar desenvolupament fa anys perquè feia falta ja. El manté sistemes quan falla. No l'audita ningú. Viu a l'inventari mental d'«eines», al costat del Jira i del wiki, mentre que el controlador de domini —que té menys poder sobre el que es publica— sí que entra a la llista curta. Ja ens va passar el mateix amb els BMC i IPMI exposats, encara que allò es quedava a l'arrencada de la màquina; això arriba fins al binari que es descarrega el teu client.

El que no es restaura: la integritat del que ja has publicat

Aquí és on aquest pla se separa de tots els altres, i és la raó per la qual li dediquem un article. Si algú et toca el tallafoc, revises regles, rotes claus i continues. Si algú et toca el servidor de compilació, el dany viatja endavant en el temps i cap enfora de la teva empresa: cada artefacte construït des d'aleshores és sospitós, i ja no el tens tu, el tenen els teus clients. Per això JetBrains no parla només de credencials robades i esmenta expressament la integritat dels artefactes i de les cadenes posteriors.

La conseqüència pràctica és incòmoda: restaurar una còpia del servidor no arregla això. La còpia et torna la màquina; no et torna la versió que es va descarregar el teu client el 14 de juliol. Després d'un incident així, la pregunta que decideix el cost no és «quan vam tancar el forat?» sinó «des de quan estem publicant, i a qui». I aquesta la contesta el registre de compilacions i els hashos que vas guardar —o no la contesta ningú. Nosaltres no hem viscut aquest cas en una pime catalana, i no fingirem el contrari; els dos episodis documentats són els de dalt. Però el mecanisme és el mateix i no depèn de la mida de l'empresa.

I que quedi clar: el problema no és TeamCity

Seria molt còmode tancar l'article dient que TeamCity té mala sort. No va d'això. L'avís el signa JetBrains perquè aquesta vegada li ha tocat a JetBrains; la categoria sencera comparteix el mateix disseny i per tant el mateix risc. Servidors de compilació autoallotjats, orquestradors de desplegament, runners que corren a la teva xarxa: tots executen codi per definició i tots guarden les claus per arribar a producció. Si estàs pensant «nosaltres no fem servir TeamCity», la pregunta que toca és qui pot arribar per HTTP al que sí que fas servir.

Què faríem aquesta setmana

Sis coses, per ordre. Les tres primeres són les que recomana el mateix fabricant, que a més demana córrer el servidor en un host dedicat i separat dels agents de compilació; les altres tres són criteri nostre i porten més feina, així que no fingim que es facin dimarts.

1. Actualitza a 2025.11.7 o 2026.1.3. Si no pots tocar la versió avui, JetBrains publica un connector de pedaç vàlid des de 2017.1. Compte amb aquest punt: a les branques 2024.03 i posteriors TeamCity es descarrega el connector tot sol i avisa l'administrador si té les notificacions configurades, però cal entrar a Administration | Updates, a «Available security updates», i aplicar-lo a mà. Descarregar-lo no és instal·lar-lo. Entre 2017.1 i 2018.1 cal reiniciar el servidor; de 2018.2 endavant, no.
2. Treu-lo d'Internet. L'avís és rotund amb el primer i prudent amb el segon: limita l'accés a xarxes de confiança sempre que puguis i, si el servidor dóna a Internet, planteja't exigir VPN o una capa de seguretat addicional. I afegeix una frase que mereix un pòster a la paret: fins i tot exposar la pantalla d'inici de sessió o l'API REST de TeamCity pot donar als atacants punts d'entrada potencials per explotar vulnerabilitats acabades de publicar. Un formulari de login publicat ja és superfície d'atac, encara que al diagrama estigui pintat com a «accés restringit».
3. Mira amb quins privilegis corre el procés. La fallada executa ordres «amb els privilegis del procés del servidor». Traduït: si el teu servei arrenca com a root o com a SYSTEM perquè un dia era el més ràpid, el 9,8 se't converteix en un deu rodó. Baixar-lo a un compte de servei dedicat és una tarda de feina i canvia el resultat d'un incident.
4. Afegeix-lo a l'inventari, avui. No al d'eines: al de sistemes crítics, amb propietari, amb finestra de pedaçat i amb monitoratge que avisi si algú crea un usuari administrador un diumenge. Si el servidor de build no té un nom i un cognom al darrere, el següent avís també se t'escaparà.
5. Separa el que compila del que desplega. L'agent que construeix codi de tercers i el que té la clau de producció no haurien de ser el mateix, i encara menys compartir credencials de llarga vida. Agents efímers que neixen i moren amb la feina, secrets amb caducitat curta, i el permís d'escriptura a producció en un sol lloc auditable. És més feina, sí. També és la diferència entre un ensurt i una reinstal·lació.
6. Escriu què faries si te l'haguessin agafat. Un full. Quines credencials hi ha a dins, en quin ordre es roten, qui avisa quin client, i com verifiques que els artefactes publicats les últimes setmanes són els que et pensaves. Si aquest full no existeix, el dia que faci falta s'improvisa a les tres de la matinada.

Sobre el punt sisè convé ser explícit, perquè és el que més se salta: pedaçar no és netejar. Actualitzar tanca la porta; no desfà el que va entrar abans de tancar-la ni caduca les credencials que ja es van llegir. Ho vam escriure fa poc arran dels symlinks que sobrevivien al pedaç a FortiOS i aquí s'aplica igual: si el teu servidor de compilació feia mesos que estava publicat a Internet, actualitzar la versió i donar el tema per tancat és explicar la meitat de la història.

Com ho tenim muntat nosaltres (i què no venem)

Toca declarar-se part interessada. Nosaltres tenim plataforma de contenidors pròpia en producció —Docker Swarm amb Portainer i Traefik— i desplegem amb CI/CD GitOps sobre GitLab, així que aquest article l'escriu algú que també té una màquina que, si se la queden, es queden amb el desplegament. No fem servir TeamCity i no som resellers de cap plataforma de CI/CD ni de virtualització: recomanem segons el cas i no segons la comissió, i això és justament el que ens permet dir «això no ho posis» sense que ens costi diners.

La disciplina que sí que defensem és avorrida i ja la vam explicar sencera quan vam dir per què «latest» no és una versió: desplegaments reproduïbles, reversibles i amb l'etiqueta exacta que s'hi va posar, perquè la pregunta «què hi havia corrent dimarts a les sis?» tingui una resposta i no una conjectura. Aquesta traçabilitat, que es munta pensant en els errors propis, resulta ser també el que et salva el dia que la pregunta la fa un forense. I la part de qui entra al panell és, en el fons, un problema d'identitat i de mínim privilegi: és Zero Trust aplicat a un pla de gestió, i va abans que qualsevol producte de ciberseguretat que puguis comprar a sobre.

La pregunta que deixa aquest 9,8

La majoria dels plans de seguretat que veiem protegeixen molt bé on són les dades: còpies, xifratge, permisos, retenció. Bastants menys protegeixen qui pot canviar el codi que toca aquestes dades, que és una via molt més curta i força més silenciosa. Un atacant no necessita entrar a la teva base de dades si pot modificar l'aplicació que ja té permís per llegir-la.

Així que la pregunta no és «estem pedaçats?». És aquesta: si algú es queda amb la màquina que desplega, què s'endú, quant triga a notar-se i qui ho nota? Si aquesta resposta avui és arronsar les espatlles, ja saps què toca aquesta setmana. I si prefereixes que ho mirem amb tu —l'inventari, qui arriba a què i quines credencials hi ha a dins—, ens escrius. Sense cap producte per col·locar.

Fonts (verificades el 3 d'agost del 2026): les dades de la vulnerabilitat surten de l'avís de seguretat de JetBrains del 27 de juliol del 2026 (versions afectades i corregides, connector de pedaç des de 2017.1 i el seu comportament per branca, TeamCity Cloud no afectat, absència d'explotació coneguda, recomanacions de xarxa, de privilegis mínims i de host dedicat separat dels agents de compilació, l'advertiment que fins i tot exposar la pantalla d'inici de sessió o l'API REST pot donar punts d'entrada potencials, i el crèdit a Antoni Tremblay pel report del 10 de juliol), de l'anàlisi de Rapid7 (CVSS 9,8, deserialització de dades no fiables sobre el protocol de sondeig de l'agent, i la petició de prioritzar-ho amb urgència) i de la cobertura de The Hacker News i Help Net Security, d'on prenem la cita literal de JetBrains sobre l'impacte i l'advertiment sobre la pantalla de login i l'API REST. L'historial: l'avís conjunt AA23-347A de CISA, FBI, NSA, SKW, CERT.PL i NCSC del 13 de desembre del 2023 per a la CVE-2023-42793 i l'atribució a l'SVR rus des del setembre del 2023, i la investigació de GuidePoint Security del març del 2024 sobre BianLian, inclosa l'advertència dels seus propis analistes que no van poder determinar si l'entrada va ser per la CVE-2024-27198 o per la CVE-2023-42793 anterior, perquè els registres ja no hi eren. La cadena posterior sobre la CVE-2024-27198 —ransomware Jasmin, miners XMRig i portes del darrere SparkRAT— la va documentar Trend Micro, no GuidePoint. L'avís de CISA se serveix després d'una comprovació anti-bot; el mateix document és al mirall de l'FBI. Són criteri i opinió nostres, no de les fonts: que el problema de fons és de govern i no de producte, que un servidor de CI/CD és execució remota autoritzada per disseny, la llista de sis mesures i el seu ordre, la separació entre agents que compilen i agents que despleguen, i la lectura que l'historial no prediu explotació però sí que escurça el termini raonable per pedaçar. No hem comptat quants servidors de TeamCity hi ha exposats a Internet ni quantes empreses tenen el seu CI/CD fora de l'inventari, i no ens ho inventarem. Foto de portada: «Worker assembles metal parts in factory» de Nenad Stojković (Shixart1985), Wikimedia Commons, CC BY 2.0.