JetBrains corrige falla crítica 9.8 en TeamCity que permite ejecución remota sin autenticación
CVE-2026-63077 en el protocolo de polling del agente permite a cualquier atacante con acceso HTTP ejecutar código en el servidor. Todas las instalaciones On-Premises anteriores a 2025.11.7 y 2026.1.3 están vulnerables.
JetBrains publicó el 27 de julio un aviso solicitando a todos los clientes de TeamCity On-Premises que actualizaran a las versiones 2025.11.7 o 2026.1.3. La empresa corrigió allí la CVE-2026-63077, una falla de deserialización insegura en el protocolo de polling entre el servidor y los agentes de build que recibió una puntuación de 9.8 en CVSS v3.1 y permite la ejecución remota de código sin ninguna autenticación.
El problema se encuentra en la CWE-502, deserialización de datos no confiables, expuesta en el canal que los agentes de build utilizan para consultar al servidor sobre nuevos trabajos. Un atacante con acceso HTTP o HTTPS al servidor envía un payload malicioso al endpoint de polling y obtiene ejecución en el proceso de TeamCity, sin sesión, sin token y sin interacción del usuario. Todas las versiones On-Premises anteriores a los parches están vulnerables.
El investigador Antoni Tremblay reportó la falla el 10 de julio a través del programa de divulgación coordinada de JetBrains. La empresa dice que no ha observado explotación activa hasta la publicación del aviso y también ha disponibilizado un plugin de parche de seguridad para instalaciones más antiguas, con soporte a partir de la versión 2017.1. Los clientes de TeamCity Cloud no necesitan actuar: el entorno administrado ya ha sido corregido.
Base instalada y lectura de riesgo global
TeamCity aparece en al menos 30 mil implementaciones, según JetBrains, con una lista de clientes que incluye Citibank, Ferrari, Wargaming y la división Oculus de Meta. Estudios de mercado de Datanyze sitúan a la plataforma en la segunda posición en CI, con un 18.7% de participación, solo detrás de Jenkins y por delante de alternativas más recientes como GitHub Actions en entornos corporativos heredados. La concentración está en Estados Unidos, Alemania y Australia, los tres mercados con mayor adopción declarada.
Los servidores de CI/CD son uno de los objetivos más valiosos para los atacantes hoy en día. Quien controla TeamCity controla el pipeline, y por extensión el binario firmado que entra en producción. La comparación inevitable es con el incidente de 3CX de 2023 y el compromiso de CircleCI en el mismo año, ambos usados como plataforma para ataques de supply chain a terceros. Fue por esta razón que la CISA incluyó una falla anterior de TeamCity, la CVE-2024-27198, en su catálogo KEV en marzo de 2024, pocas semanas después de la divulgación. En esa ocasión, BianLian y otros grupos de ransomware comenzaron a barrer la internet en busca de servidores expuestos en menos de 72 horas después de la publicación del exploit público.
El dolor no se restringe a Fráncfort o San José. Centros de delivery de Cognizant, Infosys y TCS en India utilizan TeamCity como parte del stack contratado por bancos estadounidenses y europeos; un servidor comprometido en Bangalore o Pune abre la puerta al repositorio del cliente en la City de Londres. En Brasil, entornos de shared services de bancos de mediano porte y equipos de ingeniería de fintechs paulistas utilizan TeamCity como orquestador de builds Java y .NET, legado del peso histórico de JetBrains en el desarrollo corporativo. Para el CISO aquí, la lectura es la misma: si el servidor está expuesto a internet o a una red corporativa amplia, el parche es para ahora.
Qué hacer en las próximas 48 horas
La recomendación directa de JetBrains: para quienes están en la rama 2026.x, actualizar a la 2026.1.3; para quienes están en la rama 2025.11.x, actualizar a la 2025.11.7. El plugin de parche resuelve para quienes bloquean en versiones antiguas, pero no sustituye la actualización. Segregar el servidor de TeamCity de la internet pública, aunque el proveedor no mencione el punto en el aviso, elimina el vector principal mientras la ventana de exposición disminuye. Equipos de respuesta que ya estén ejecutando escaneos internos con Nuclei o Tenable deben priorizar la firma tan pronto como esta esté disponible, y revisar logs del endpoint de agent polling en busca de payloads binarios inusuales en las últimas dos semanas, rango que cubre la ventana entre el reporte privado y la divulgación pública.
Una nota final sobre el calendario. Entre la fecha en que Tremblay reportó la falla, 10 de julio, y la divulgación pública, el día 27, transcurrieron diecisiete días. Es una ventana corta para una corrección que implica cambio en el protocolo. JetBrains actuó rápido después del incidente de 2024, cuando Rapid7 rompió el embargo y forzó la divulgación anticipada. La pregunta que queda para el equipo de seguridad del cliente es otra: ¿cuánto tiempo, ahora que la CVE es pública, hasta la primera explotación en el medio?