Un atacante sin credenciales, con solo acceso HTTP(S) al servidor, puede ejecutar comandos del sistema operativo en una instalación de JetBrains TeamCity On-Premises. Es CVE-2026-63077, un fallo de gravedad 9,8 sobre 10 que no pide usuario, contraseña ni interacción de nadie. Y no cae en un servidor cualquiera: cae en la máquina que compila, firma y despliega tu software.
JetBrains lo parcheó el 27 de julio de 2026, tras un aviso privado y coordinado. La explotación vino después, contra servidores que no habían actualizado, y fue suficiente para que CISA lo llevara a su catálogo KEV de vulnerabilidades explotadas. Ese orden —parche primero, ataques después— cambia cómo hay que leer el caso.
Este artículo explica, en clave defensiva, qué se puede explotar y desde cuándo, por qué un servidor de build es un objetivo tan codiciado, cómo detectar señales de compromiso y cómo cerrar la puerta. No incluye código de explotación.
¿Qué es CVE-2026-63077 y por qué es crítico?
El fallo es una deserialización de datos no confiables —CWE-502— en el protocolo de sondeo de agentes de TeamCity, la conversación que el servidor mantiene con las máquinas que ejecutan las compilaciones. Ese canal procesa objetos serializados con la biblioteca XStream, y una petición manipulada permite que el servidor reconstruya y ejecute lógica elegida por el atacante. El resultado es ejecución remota de código sin autenticar, con los privilegios del propio proceso de TeamCity.
Afecta a todas las versiones de TeamCity On-Premises anteriores a las correcciones. La modalidad gestionada por el fabricante queda al margen, porque es JetBrains quien administra y actualiza ese servidor; el riesgo recae en quien opera su propia instancia. Con CVSS 9,8, sin requisito de autenticación y con un objetivo de alto valor detrás, es una prioridad de parcheo inmediata.
La cronología: parche primero, explotación después
La secuencia importa. El 27 de julio JetBrains publicó las versiones corregidas —2026.1.3 y 2025.11.7— después de recibir el aviso por un canal privado. El 28 de julio la cobertura especializada ya recogía el parche. En los días siguientes aparecieron intentos de explotación contra instancias sin actualizar, y el 5 de agosto CISA añadió la vulnerabilidad al KEV —elevando su evaluación de explotación de «ninguna» a «activa»—, con fecha límite de corrección para las agencias federales el 8 de agosto.
Esa cronología reequilibra el caso. No fue un zero-day explotado antes de existir defensa: hubo divulgación coordinada, parche disponible y una ventana para aplicarlo. Lo que empujó la vulnerabilidad al KEV no fue la ausencia de arreglo, sino la cantidad de instancias que seguían sin él. La lección se repite: la ventana entre el parche y la explotación se mide en días, no en semanas.
Cómo funciona, a nivel conceptual
El análisis técnico de Rapid7 describe la causa sin necesidad de convertirla en receta. Al atender las peticiones no autenticadas de los agentes, el servidor construía una lista de permitidos de XStream para restringir qué clases Java podían deserializarse; lo que falla es que añadía las clases del protocolo de TeamCity sin retirar antes los permisos por defecto de la biblioteca. Esa lista, pensada para ser restrictiva, dejaba un resquicio suficiente para encadenar objetos hasta lograr ejecución.
La corrección es tan reveladora como el fallo: la versión parcheada antepone una regla de «no permitir nada» antes de la lista, de modo que solo se admita lo explícitamente autorizado. Es el patrón recurrente de la deserialización insegura —una lista de permitidos que no parte de denegar por defecto—, el mismo terreno conceptual que vimos en el zero-day de Fastjson. No es un descuido exótico de un fabricante concreto, sino una trampa conocida de todo el que procesa objetos serializados que llegan de fuera.
Por eso el desglose técnico se detiene aquí, en el «qué lo permite» y no en el «cómo se arma»: el detalle de la cadena de gadgets pertenece al terreno de la investigación de defensa, no al de una guía reproducible.
¿Por qué un servidor de build es un objetivo de alto valor?
Un servidor de integración y entrega continua no es un servidor más. Es el punto donde convergen las credenciales de despliegue, los secretos de acceso a producción, las claves de firma de artefactos, el código fuente y los registros de artefactos. Quien controla esa máquina no solo entra en un sistema: hereda las llaves de toda la línea de montaje del software.
De ahí que el impacto sea de cadena de suministro. Un compromiso del CI/CD permite inyectar código en las compilaciones que después se distribuyen a clientes y a otros sistemas internos, firmar artefactos maliciosos como si fueran legítimos o robar los secretos que abren producción. Es la misma lógica que convirtió un paquete olvidado en un problema de cientos de proyectos en el ataque a la cadena de npm easy-day-js, solo que aquí el punto de entrada es la propia infraestructura de construcción.
¿Cómo detectar una explotación?
Como el vector es una petición al canal de agentes, la detección se concentra en el comportamiento del servidor tras recibirla. Estas son las señales que merece la pena cazar, correlacionadas y no por separado.
La más directa es la aparición de procesos hijo inesperados que cuelgan del proceso de TeamCity: un servidor de build que de pronto abre un intérprete de comandos o herramientas de red es una anomalía que rara vez tiene explicación benigna. A su lado, hay que vigilar las conexiones salientes hacia destinos desconocidos —posible C2—, la creación de usuarios administradores o tokens de acceso nuevos, y cambios no justificados en configuraciones y scripts de compilación.
Dado que el parche es del 27 de julio, cualquier revisión retrospectiva debería cubrir desde esa fecha: peticiones anómalas al canal de sondeo de agentes desde orígenes no autenticados, ficheros nuevos en el servidor y artefactos alterados. Convertir estos indicadores de compromiso en cacerías reproducibles —y revisar el histórico en busca de esa actividad— es justo el trabajo de un equipo de caza de amenazas como el de Hard2bit Cybersecurity.
Parcheo, mitigación y contención
La acción principal es actualizar a TeamCity 2026.1.3 o 2025.11.7. Para quien no pueda hacerlo de inmediato, JetBrains ofrece un parche de seguridad provisional en forma de plugin que cubre las versiones 2017.1 y posteriores; las ramas entre 2017.1 y 2018.1 requieren reiniciar el servidor tras instalarlo, mientras que 2018.2 y siguientes lo aplican sin reinicio. Es una red temporal, no un sustituto de la actualización.
Más allá del parche, un servidor de build no debería estar expuesto a Internet. Reducir su superficie de ataque y segmentarlo del resto de la red limita quién puede siquiera hablar con el canal de agentes, y el bastionado del sistema y una cuenta de servicio con privilegios mínimos acotan el daño si algo entra. Estas medidas encajan en un programa de gestión de vulnerabilidades que priorice por explotación real, como plantean los marcos KEV, EPSS y SSVC, y en una práctica de DevSecOps que trate la cadena de construcción del software como un activo crítico. Es el enfoque con el que Hard2bit —desde 2013, con ENS categoría ALTA e ISO 27001 propias— aborda la exposición del CI/CD: priorizar por explotación real y reducir lo que el atacante puede alcanzar.
Si el servidor estuvo expuesto y sin parchear durante la ventana de explotación, la prudencia obliga a asumir compromiso: rotar todas las credenciales, secretos y claves de firma que custodiaba, revisar las compilaciones recientes en busca de manipulación y activar la respuesta a incidentes que Hard2bit presta para escenarios de cuenta o servidor comprometido. Con un servidor de build, restaurar el servicio no basta; hay que dar por quemado lo que guardaba.
Qué vigilar los próximos días
El riesgo inmediato no es el fallo en sí, que tiene parche, sino el número de servidores TeamCity que siguen sin aplicarlo y expuestos. A medida que se generalice la explotación, esas instancias serán el objetivo. Y merece atención el patrón de fondo: la deserialización insegura en protocolos de gestión y de agentes se repite producto tras producto, porque el canal que da servicio a componentes internos suele recibir menos escrutinio que la interfaz de usuario.
Queda una incógnita razonable: los detalles de la actividad observada en circulación aún se están perfilando y las atribuciones pueden cambiar. La prioridad, en cambio, no admite duda: un servidor que construye software merece la misma protección que producción, empezando por no dejarlo al alcance de cualquiera que sepa su dirección.
Este artículo describe una vulnerabilidad con explotación activa a partir de fuentes públicas disponibles en la fecha de publicación, con fines defensivos. No incluye código de explotación ni pasos reproducibles. La causa técnica se explica a nivel conceptual siguiendo el análisis del fabricante y de terceros; las versiones, fechas y recomendaciones deben verificarse contra los avisos oficiales de JetBrains y de CISA antes de actuar.
