Tu CI/CD tiene las llaves de producción. Y lo tratas como una herramienta de desarrollo

El 27 de julio JetBrains publicó un aviso corto sobre TeamCity On-Premises. Un 9,8. Sin autenticación. Todas las versiones. Un atacante con acceso HTTP al servidor ejecuta comandos del sistema operativo y se acabó la conversación. El fallo se parchea en una tarde; lo que cuesta más es asumir dónde ha caído. En la máquina que guarda las credenciales para escribir en el resto de tus servidores y que, además, firma y publica lo que tus clientes acaban ejecutando. Ahí el compromiso deja de ser un problema de acceso y pasa a serlo de integridad: no es que te entren, es que a partir de ese momento no sabes qué has entregado. Y esa máquina casi nunca aparece en el inventario de sistemas críticos de nadie. No tenemos una encuesta que lo cuantifique. Tenemos los servidores que hemos visto.

CVE-2026-63077, en una pantalla

Antes de opinar, los hechos tal como los publica el fabricante. Sin adornos y sin la palabra «catastrófico», que no aporta nada:

Lo reportó en privado el 10 de julio el investigador Antoni Tremblay, JetBrains lo publicó el 27 y Rapid7 sacó comprobaciones para sus productos al día siguiente pidiendo priorizarlo con urgencia. Diecisiete días entre el aviso privado y el público: eso es una divulgación coordinada hecha como toca, y conviene decirlo cuando pasa.

La frase que hay que leer dos veces es la del propio fabricante sobre el impacto: un ataque con éxito puede «exponer datos, configuraciones y credenciales almacenadas de TeamCity, modificar el estado del servidor y potencialmente comprometer la integridad de los artefactos de compilación y de las cadenas CI/CD posteriores». Ahí está todo el artículo resumido por JetBrains: credenciales almacenadas, integridad de los artefactos, cadenas posteriores.

Qué caduca antes: el «sin explotación conocida» o tu ventana de mantenimiento

Esa línea del aviso es la que hace que un CVE se quede en la lista de «para septiembre». Con TeamCity concretamente, el historial no da para ese lujo, y son dos episodios documentados por organismos públicos y por respuesta a incidentes, no rumores de foro.

• CVE-2023-42793 (también un 9,8, también un salto de autenticación, corregido en 2023.05.4). El 13 de diciembre de 2023, CISA, el FBI, la NSA, el servicio de contrainteligencia militar polaco, CERT.PL y el NCSC británico firmaron un aviso conjunto: actores del SVR ruso —APT29, Cozy Bear, Midnight Blizzard, el mismo grupo con muchos nombres— llevaban desde septiembre de 2023 usándolo para entrar, escalar privilegios, moverse lateralmente, dejar puertas traseras y quedarse. A escala, y con las empresas tecnológicas como objetivo preferente.
• CVE-2024-27198, otro salto de autenticación de 9,8, publicado el 4 de marzo de 2024 junto a CVE-2024-27199. Ese mismo mes GuidePoint documentó a los operadores del ransomware BianLian entrando por TeamCity, dándose de alta usuarios en el propio producto y ejecutando órdenes bajo su cuenta de servicio. Sus analistas dejaron escrito que no pudieron determinar si la entrada fue por CVE-2024-27198 o por la CVE-2023-42793 anterior, porque los registros necesarios ya no estaban: un detalle que dice bastante sobre cuánto se conserva de lo que pasa en un servidor de build. Por el mismo agujero de 2024 pasaron después, según Trend Micro, el ransomware Jasmin, mineros XMRig y puertas traseras SparkRAT.

Seamos justos con el argumento: esto no demuestra que CVE-2026-63077 vaya a explotarse. Puede que no pase nada. Lo que dice el historial es otra cosa, más modesta y más útil: cuando aparece un salto de autenticación con ejecución remota en un servidor de compilación expuesto, el hueco entre el aviso y el primer incidente se ha medido antes en semanas, no en trimestres. Con ese antecedente, dejarlo para la ventana de mantenimiento de septiembre es una decisión que alguien firma. Que se firme sabiendo lo que se firma.

Por qué un servidor de build es un objetivo tan bueno

Piensa en lo que hay dentro del CI/CD de tu empresa ahora mismo. No en teoría: abre la pantalla de variables y mira. Suele haber claves SSH que entran en los servidores de producción, tokens del registro de contenedores con permiso de escritura, credenciales de la base de datos para las migraciones, un token de la API del proveedor de cloud, la firma de los artefactos y, con suerte, algún secreto de cliente que alguien puso «temporalmente» hace dos años.

Ahora súmale la segunda propiedad, que es la que lo hace especial: un servidor de CI/CD ejecuta código arbitrario como función principal. Un agente de compilación es, literalmente, ejecución remota autorizada. No hay un «modo seguro» que activar, porque ejecutar es el producto. Por eso, quien entra en el servidor de build no necesita moverse lateralmente hacia ningún sitio: ya está en la única máquina de la casa que tiene permiso para escribir en todas las demás, y encima cualquier cosa rara que haga se parecerá bastante a un despliegue.

El tercer ingrediente no lo arregla ninguna versión, y es el que de verdad hace daño: es de gobernanza. El CI/CD no es de nadie. Lo montó desarrollo hace años porque hacía falta ya. Lo mantiene sistemas cuando falla. No lo audita nadie. Vive en el inventario mental de «herramientas», junto al Jira y al wiki, mientras el controlador de dominio —que tiene menos poder sobre lo que se publica— sí entra en la lista corta. Ya nos pasó lo mismo con los BMC e IPMI expuestos, aunque aquello se quedaba en el arranque de la máquina; esto llega hasta el binario que se descarga tu cliente.

Lo que no se restaura: la integridad de lo que ya has publicado

Aquí es donde este plano se separa de todos los demás, y es la razón por la que le dedicamos un artículo. Si alguien te toca el cortafuegos, revisas reglas, rotas claves y sigues. Si alguien te toca el servidor de compilación, el daño viaja hacia delante en el tiempo y hacia fuera de tu empresa: cada artefacto construido desde entonces es sospechoso, y ya no lo tienes tú, lo tienen tus clientes. Por eso JetBrains no habla solo de credenciales robadas y menciona expresamente la integridad de los artefactos y de las cadenas posteriores.

La consecuencia práctica es incómoda: restaurar una copia del servidor no arregla esto. La copia te devuelve la máquina; no te devuelve la versión que se descargó tu cliente el 14 de julio. Después de un incidente así, la pregunta que decide el coste no es «¿cuándo cerramos el agujero?» sino «¿desde cuándo estamos publicando, y a quién». Y esa la contesta el registro de compilaciones y los hashes que guardaste —o no la contesta nadie. Nosotros no hemos vivido este caso en una pyme española, y no vamos a fingir lo contrario; los dos episodios documentados son los de arriba. Pero el mecanismo es el mismo y no depende del tamaño de la empresa.

Y que quede claro: el problema no es TeamCity

Sería muy cómodo cerrar el artículo diciendo que TeamCity tiene mala suerte. No va de eso. El aviso lo firma JetBrains porque le tocó a JetBrains esta vez; la categoría entera comparte el mismo diseño y por tanto el mismo riesgo. Servidores de compilación autoalojados, orquestadores de despliegue, runners que corren en tu red: todos ejecutan código por definición y todos guardan las llaves para llegar a producción. Si estás pensando «nosotros no usamos TeamCity», la pregunta que toca es quién puede llegar por HTTP al que sí usas.

Qué haríamos esta semana

Seis cosas, por orden. Las tres primeras son las que recomienda el propio fabricante, que además pide correr el servidor en un host dedicado y separado de los agentes de compilación; las otras tres son criterio nuestro y llevan más trabajo, así que no fingimos que se hacen el martes.

1. Actualiza a 2025.11.7 o 2026.1.3. Si no puedes tocar la versión hoy, JetBrains publica un plugin de parche válido desde 2017.1. Cuidado con este punto: en las ramas 2024.03 y posteriores TeamCity se descarga el plugin solo y avisa al administrador si tiene las notificaciones configuradas, pero hay que entrar en Administration | Updates, en «Available security updates», y aplicarlo a mano. Descargarlo no es instalarlo. Entre 2017.1 y 2018.1 hay que reiniciar el servidor; de 2018.2 en adelante, no.
2. Sácalo de Internet. El aviso es rotundo con lo primero y prudente con lo segundo: limita el acceso a redes de confianza siempre que puedas y, si el servidor da a Internet, plantéate exigir VPN o una capa de seguridad adicional. Y añade una frase que merece un póster en la pared: incluso exponer la pantalla de inicio de sesión o la API REST de TeamCity puede dar a los atacantes puntos de entrada potenciales para explotar vulnerabilidades recién publicadas. Un formulario de login publicado ya es superficie de ataque, aunque en el diagrama esté pintado como «acceso restringido».
3. Mira con qué privilegios corre el proceso. El fallo ejecuta órdenes «con los privilegios del proceso del servidor». Traducido: si tu servicio arranca como root o como SYSTEM porque un día era lo más rápido, el 9,8 se te convierte en un diez redondo. Bajarlo a una cuenta de servicio dedicada es una tarde de trabajo y cambia el resultado de un incidente.
4. Añádelo al inventario, hoy. No al de herramientas: al de sistemas críticos, con dueño, con ventana de parcheo y con monitorización que avise si alguien crea un usuario administrador un domingo. Si el servidor de build no tiene un nombre y un apellido detrás, el siguiente aviso también se te pasará.
5. Separa lo que compila de lo que despliega. El agente que construye código de terceros y el que tiene la llave de producción no deberían ser el mismo, y menos aún compartir credenciales de larga vida. Agentes efímeros que nacen y mueren con el trabajo, secretos con caducidad corta, y el permiso de escritura en producción en un solo sitio auditable. Es más trabajo, sí. También es la diferencia entre un susto y una reinstalación.
6. Escribe qué harías si te lo hubieran cogido. Una hoja. Qué credenciales hay dentro, en qué orden se rotan, quién avisa a qué cliente, y cómo verificas que los artefactos publicados en las últimas semanas son los que creías. Si esa hoja no existe, el día que haga falta se improvisa a las tres de la madrugada.

Sobre el punto sexto conviene ser explícito, porque es el que más se salta: parchear no es limpiar. Actualizar cierra la puerta; no deshace lo que entró antes de cerrarla ni caduca las credenciales que ya se leyeron. Lo escribimos hace poco a cuenta de los symlinks que sobrevivían al parche en FortiOS y aquí aplica igual: si tu servidor de compilación llevaba meses publicado en Internet, actualizar la versión y dar el tema por cerrado es contar la mitad de la historia.

Cómo lo tenemos montado nosotros (y qué no vendemos)

Toca declararse parte interesada. Nosotros tenemos plataforma de contenedores propia en producción —Docker Swarm con Portainer y Traefik— y desplegamos con CI/CD GitOps sobre GitLab, así que este artículo lo escribe alguien que también tiene una máquina que, si se la quedan, se queda con el despliegue. No usamos TeamCity y no somos resellers de ninguna plataforma de CI/CD ni de virtualización: recomendamos según el caso y no según la comisión, y eso es justo lo que nos permite decir «esto no lo pongas» sin que nos cueste dinero.

La disciplina que sí defendemos es aburrida y ya la contamos entera cuando explicamos por qué «latest» no es una versión: despliegues reproducibles, reversibles y con la etiqueta exacta que se puso, para que la pregunta «¿qué había corriendo el martes a las seis?» tenga una respuesta y no una conjetura. Esa trazabilidad, que se monta pensando en los errores propios, resulta ser también lo que te salva el día que la pregunta la hace un forense. Y la parte de quién entra al panel es, en el fondo, un problema de identidad y de mínimo privilegio: es Zero Trust aplicado a un plano de gestión, y va antes que cualquier producto de ciberseguridad que puedas comprar encima.

La pregunta que deja este 9,8

La mayoría de los planes de seguridad que vemos protegen muy bien dónde están los datos: copias, cifrado, permisos, retención. Bastantes menos protegen quién puede cambiar el código que toca esos datos, que es una vía mucho más corta y bastante más silenciosa. Un atacante no necesita entrar en tu base de datos si puede modificar la aplicación que ya tiene permiso para leerla.

Así que la pregunta no es «¿estamos parcheados?». Es esta: si alguien se queda con la máquina que despliega, ¿qué se lleva, cuánto tarda en notarse y quién lo nota? Si esa respuesta hoy es un encogimiento de hombros, ya sabes qué toca esta semana. Y si prefieres que la miremos contigo —el inventario, quién llega a qué y qué credenciales hay dentro—, nos escribes. Sin producto que colocar.

Fuentes (verificadas el 3 de agosto de 2026): los datos de la vulnerabilidad salen del aviso de seguridad de JetBrains del 27 de julio de 2026 (versiones afectadas y corregidas, plugin de parche desde 2017.1 y su comportamiento por rama, TeamCity Cloud no afectado, ausencia de explotación conocida, recomendaciones de red, de privilegios mínimos y de host dedicado separado de los agentes de compilación, la advertencia de que incluso exponer la pantalla de inicio de sesión o la API REST puede dar puntos de entrada potenciales, y el crédito a Antoni Tremblay por el reporte del 10 de julio), del análisis de Rapid7 (CVSS 9,8, deserialización de datos no confiables sobre el protocolo de sondeo del agente, y la petición de priorizarlo con urgencia) y de la cobertura de The Hacker News y Help Net Security, de donde tomamos la cita literal de JetBrains sobre el impacto y el aviso sobre la pantalla de login y la API REST. El historial: el aviso conjunto AA23-347A de CISA, FBI, NSA, SKW, CERT.PL y NCSC del 13 de diciembre de 2023 para CVE-2023-42793 y la atribución al SVR ruso desde septiembre de 2023, y la investigación de GuidePoint Security de marzo de 2024 sobre BianLian, incluida la advertencia de sus propios analistas de que no pudieron determinar si la entrada fue por CVE-2024-27198 o por la CVE-2023-42793 anterior, porque los registros ya no estaban. La cadena posterior sobre CVE-2024-27198 —ransomware Jasmin, mineros XMRig y puertas traseras SparkRAT— la documentó Trend Micro, no GuidePoint. El aviso de CISA se sirve tras una comprobación anti-bot; el mismo documento está en el espejo del FBI. Son criterio y opinión nuestros, no de las fuentes: que el problema de fondo es de gobierno y no de producto, que un servidor de CI/CD es ejecución remota autorizada por diseño, la lista de seis medidas y su orden, la separación entre agentes que compilan y agentes que despliegan, y la lectura de que el historial no predice explotación pero sí acorta el plazo razonable para parchear. No hemos contado cuántos servidores de TeamCity hay expuestos en Internet ni cuántas empresas tienen su CI/CD fuera del inventario, y no nos lo vamos a inventar. Foto de portada: «Worker assembles metal parts in factory» de Nenad Stojković (Shixart1985), Wikimedia Commons, CC BY 2.0.