CVE-2026-63077: Vulnerabilidad crítica en TeamCity permite ejecución remota de código
El 27 de julio de 2026, JetBrains publicó una alerta de seguridad crítica que sacudió a los equipos de operaciones y seguridad que mantienen pipelines de integración continua en producción: una vulnerabilidad de deserialización de datos no confiables, catalogada como CVE-2026-63077, permite a un atacante remoto no autenticado, con acceso HTTP o HTTPS al servidor de TeamCity On-Premises, evadir por completo las comprobaciones de autenticación y ejecutar comandos arbitrarios del sistema operativo con los privilegios del proceso del propio servidor. La falla recibió una puntuación CVSS de 9.8 sobre 10 —la máxima criticidad posible— y apenas nueve días después de su divulgación pública, la Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) la incorporó a su catálogo de Vulnerabilidades Conocidas Explotadas (KEV), confirmando que ya está siendo aprovechada activamente por actores maliciosos en la naturaleza. Help Net Security, The Hacker News y SecurityWeek dieron cuenta del caso en las horas posteriores a la divulgación, mientras que el equipo de respuesta de JetBrains trabajó contrarreloj para desplegar las versiones parcheadas y publicar un plugin de mitigación temporal.
El problema, según el análisis técnico publicado por Rapid7 Labs, reside en el protocolo de sondeo de agentes (agent polling protocol) que TeamCity utiliza para mantener sincronizados los runners distribuidos con el servidor central. La implementación del lado del servidor crea una lista permisiva de clases permitidas en XStream —la biblioteca de serialización XML que TeamCity emplea para intercambiar mensajes entre el servidor y los agentes remotos— que añade clases del protocolo de TeamCity sin retirar las permisiones por defecto preexistentes de XStream. Esa acumulación de permisos, diseñada para soportar el protocolo interno, abre la puerta a que cualquier petición XML especialmente construida aproveche cadenas de gadgets que terminan en ejecución remota de código, sin que el atacante necesite identificarse. El problema es estructural, no de configuración: la falla reside en el propio código del servidor, en la forma en que se construye el allowlist de XStream, por lo que cualquier instancia de TeamCity On-Premises bajo esa versión es vulnerable por defecto, sin importar las medidas de hardening que el operador haya aplicado a nivel de sistema operativo, red o autenticación perimetral.
Según la propia descripción de JetBrains en su blog corporativo, un atacante que pueda llegar al servidor de TeamCity sobre HTTP o HTTPS puede explotar la falla a través del protocolo de polling de agentes, sin necesidad de credenciales, y ejecutar comandos arbitrarios del sistema operativo con los privilegios del proceso del servidor de TeamCity. La exposición no se limita a una sola ruta de acceso: cualquier endpoint que use el agente poller —incluidos los servidores expuestos directamente a Internet, los que están tras un balanceador o proxy inverso, e incluso los instalados en redes internas con agentes remotos— es vulnerable. La superficie de ataque es, en la práctica, cualquier instalación de TeamCity On-Premises que atienda conexiones en el puerto HTTP/HTTPS habitual. Y aquí aparece un matiz que ha subrayado el equipo de Rapid7 en su análisis: la mayoría de las organizaciones despliegan TeamCity esperando que esté protegido por una VPN corporativa o un firewall de aplicación web, pero el agente poller necesita conectividad persistente entre agentes distribuidos y el servidor central, por lo que rara vez se bloquea completamente, lo que deja la superficie expuesta en muchos casos incluso cuando la interfaz de administración está detrás de capas de autenticación adicionales.
Lo que vuelve a CVE-2026-63077 especialmente grave para los equipos de DevSecOps es su alcance sistémico. TeamCity no es solo un servidor de integración continua: es la pieza central que orquesta pipelines de compilación, pruebas, despliegue y entrega continua, y por diseño acumula credenciales para firmar artefactos, desplegar en producción, hablar con registries de contenedores, sistemas de control de código fuente y servicios cloud. Un atacante que obtenga ejecución remota en el servidor de TeamCity hereda todos esos privilegios. The Hacker News, SecurityWeek y Help Net Security coinciden en que el riesgo no se limita al servidor afectado, sino que se propaga aguas abajo, comprometiendo potencialmente la cadena de suministro de software de todas las aplicaciones que dependen de ese pipeline. Como advirtió Help Net Security, el servidor de TeamCity almacena tokens de despliegue, claves SSH, credenciales de nube y tokens de registro que, una vez en manos del atacante, pueden usarse para insertar backdoors en artefactos firmados o reescribir el código fuente en repositorios a los que TeamCity tiene acceso. El incidente SolarWinds de 2020 dejó lessons aprendidas sobre cómo una sola intrusión en un pipeline de CI/CD puede propagarse a miles de organizaciones downstream, y CVE-2026-63077 tiene todas las características técnicas para replicar ese patrón: ejecución silenciosa, persistencia vía acceso legítimo a credenciales privilegiadas y capacidad de inyectar código malicioso en artefactos firmados que las víctimas consumen con plena confianza criptográfica.
El contexto histórico importa porque TeamCity no es ajeno a las vulnerabilidades críticas de RCE. En 2024, el proyecto enfrentó una serie de fallos similares que también llevaron a CISA a tomar cartas en el asunto, lo que convierte a TeamCity en un objetivo recurrente para los actores que buscan comprometer cadenas de suministro de software. Esa repetición, sumada al hecho de que las instancias corporativas de TeamCity rara vez están en el radar de los equipos rojos (que suelen concentrarse en el perímetro externo), hace que la probabilidad de detección por parte de los defensores sea baja durante la fase inicial de explotación. Los analistas de Qualys ThreatPROTECT han comparado CVE-2026-63077 con incidentes previos que han utilizado servidores de CI como punto de pivote hacia redes internas, y el paralelismo no es casual.
Las versiones afectadas son todas las instalaciones On-Premises de TeamCity publicadas hasta la fecha de divulgación —el aviso de JetBrains no excluye ninguna rama—. TeamCity Cloud no está afectado, ya que la compañía aplica los parches directamente en su infraestructura administrada. Para las versiones On-Premises, JetBrains publicó las correcciones en TeamCity 2026.1.3 (build 222742) y en TeamCity 2025.11.7 (build 208264), y simultáneamente publicó un plugin de parche de seguridad que cubre todas las versiones desde 2017.1 en adelante, pensado para las organizaciones que, por motivos de compatibilidad o de ventanas de cambio, no pueden actualizar el servidor completo de forma inmediata. La compañía desaconseja aplicar el plugin como solución permanente y recomienda encarecidamente planificar la actualización completa a una de las versiones parcheadas como camino más rápido hacia la mitigación total. La disponibilidad del plugin es relevante porque muchas organizaciones mantienen instancias de TeamCity en versiones antiguas por motivos de compatibilidad con plugins de terceros, políticas de cambio estrictas o simplemente inercia operativa, y el plugin permite cubrir esa brecha mientras se planifica una actualización mayor.
El vector de ataque documentado por Rapid7 y replicado en pruebas de concepto públicas hace que la ventana de exposición sea extremadamente corta. A diferencia de vulnerabilidades que requieren interacción del usuario, phishing o credenciales válidas, CVE-2026-63077 puede ser aprovechada por un único paquete HTTP enviado a un endpoint público del servidor. Esto coloca a cualquier instancia expuesta en Internet —directamente o a través de un proxy— en riesgo inmediato de compromiso. Bleeping Computer, Qualys ThreatPROTECT y los avisos de SentinelOne han confirmado de forma independiente la facilidad con que la falla es aprovechable, y el hecho de que CISA la haya añadido al KEV con plazo de mitigación del 8 de agosto para las agencias federales de EE. UU. deja pocas dudas sobre la gravedad operativa del incidente. La propia CISA, en su notificación, describió la vulnerabilidad como una que permite a un atacante no autenticado tomar el control completo del servidor con un único request, lo que la coloca en la categoría más alta de riesgo operativo.
La recomendación operativa es inmediata y en tres capas, en línea con lo que publicaron JetBrains, CISA y los analistas independientes. Primero, identificar inventario: localizar todas las instancias de TeamCity On-Premises bajo la administración de la organización, sin confiar únicamente en el CMDB, porque la proliferación de servidores de CI en diferentes unidades de negocio suele dejar instancias huérfanas. En un entorno empresarial típico, no es raro encontrar tres, cinco o más instancias de TeamCity en diferentes proyectos, muchas de ellas instaladas por equipos de desarrollo que ya no existen o que se han mudado a otros proyectos sin dejar rastro documentado. Cada una de esas instancias es un vector de entrada potencial. Segundo, aplicar la actualización a 2026.1.3 o 2025.11.7 lo antes posible, o en su defecto desplegar el plugin de parche de seguridad publicado por JetBrains, recordando que el plugin es una medida temporal. Tercero, como mitigación complementaria mientras se completan las actualizaciones, restringir el acceso de red a la interfaz de administración y al endpoint del agent polling protocol únicamente a redes de confianza, idealmente detrás de VPN o zero-trust network access, y bloquear el acceso desde Internet público a los puertos de TeamCity.
Para los equipos que sospechen o confirmen una explotación previa, los indicadores de compromiso publicados por JetBrains y los analistas incluyen nombres de agentes sospechosos con prefijos como `scan*`, intentos de deserialización anómalos en los logs de XStream (mensajes `ConversionException` repetidos o payloads inesperados), y la presencia de procesos hijos inesperados del proceso de TeamCity. Esos indicadores deben incorporarse a las reglas de detección del SIEM corporativo y a los pipelines de threat hunting con la mayor prioridad. Adicionalmente, si se confirma cualquier compromiso, es imprescindible rotar todas las credenciales, claves SSH, tokens de despliegue y secretos almacenados en el servidor de TeamCity, dado que cualquier elemento gestionado por el servidor debe considerarse expuesto. Help Net Security fue particularmente explícito al señalar que la rotación de secretos no es opcional: la única manera de recuperar la confianza en un pipeline de CI/CD comprometido es asumir que todos los secretos que pasaron por él en cualquier momento son públicos.
CVE-2026-63077 es, en conjunto, una de las vulnerabilidades más severas divulgadas en 2026 contra infraestructura DevSecOps. Combina una criticidad técnica máxima (CVSS 9.8, sin autenticación, sin interacción del usuario) con un vector de explotación trivial (un único request HTTP), con un activo objetivo crítico (el servidor que orquesta las pipelines de producción) y con confirmación de explotación activa en la naturaleza. Los equipos que aún no hayan actuado deben tratarla como una emergencia operativa y aplicar las mitigaciones recomendadas por JetBrains y CISA sin demora. La ventana entre divulgación y explotación masiva suele ser de días, y en este caso ya hay evidencia de que actores maliciosos están aprovechando la falla antes de que las víctimas alcancen a parchear.
Las lecciones operativas de CVE-2026-63077 van más allá del incidente puntual y tocan la forma en que las organizaciones han estado gestionando su superficie DevSecOps. Por un lado, el caso revela la fragilidad estructural de confiar la entrega de software a servidores de CI cuyo inventario no es exhaustivamente conocido por los equipos de seguridad. Por otro lado, demuestra que los ciclos de actualización para productos críticos deben acortarse drásticamente: cuando la diferencia entre divulgación y explotación es de días, una ventana de cambio de varias semanas equivale a dejar la puerta abierta al atacante. Los analistas que han cubierto la respuesta a la vulnerabilidad coinciden en que el próximo paso lógico para muchas organizaciones será auditar no solo el inventario de TeamCity, sino también el resto de la cadena DevOps (repositorios, runners, registries, servicios de firma), porque los atacantes que obtengan RCE en un servidor de CI raramente se limitan a esa primera superficie. Adelantarse —buscar proactivamente instancias, parchear antes de los plazos regulatorios, monitorizar los IoCs publicados por JetBrains y los analistas independientes— es la diferencia entre un incidente contenido y un compromiso sistémico. Para los equipos que ya han completado la mitigación inicial y la rotación de secretos, queda una segunda fase menos urgente pero igualmente importante: integrar la lección en los procesos de gestión de cambios y de threat modeling. La pregunta correcta que cada organización debería hacerse tras CVE-2026-63077 no es solo cómo parchear TeamCity, sino cuántas otras herramientas críticas de la cadena DevSecOps están expuestas de forma similar sin que la organización lo sepa. Productos como los agentes de runners, los servicios de firma de contenedores, los proxies de artifact y los registros internos son superficies con el mismo perfil de criticidad, y un programa serio de gestión de vulnerabilidades DevSecOps debe tratarlos con el mismo rigor con que se trata el inventario de firewalls o de aplicaciones web expuestas a Internet. CVE-2026-63077, en este sentido, no es solo una vulnerabilidad concreta que debe parchearse: es un llamado de atención sobre la madurez general del modelo operativo que cada organización ha construido alrededor de sus pipelines de entrega de software, y los equipos que respondan solo con un parche aplicado estarán perdiendo la oportunidad de extraer el aprendizaje real.