Rapid7 detalla falla crítica en TeamCity que ya está siendo explorada, y CISA impuso un plazo relámpago
Falla CVSS 9.8 permite ejecución remota de código sin autenticación en servidores JetBrains TeamCity. CISA la añadió al KEV el 5 de agosto con un plazo de tres días.
Rapid7 actualizó este lunes su análisis técnico de la CVE-2026-63077, falla crítica de ejecución remota de código no autenticado en JetBrains TeamCity On-Premises, días después de que la CISA la añadiera al catálogo de vulnerabilidades activamente explotadas. La puntuación CVSS es de 9.8 y el vector es de los más peligrosos. Cualquier atacante con acceso HTTP o HTTPS al servidor puede ejecutar comandos del sistema operativo con los privilegios del proceso TeamCity, sin necesidad de credenciales.
TeamCity es una de las plataformas de CI/CD más adoptadas por equipos de ingeniería de mediano y gran tamaño, con decenas de miles de servidores expuestos a internet según levantamientos públicos de Shodan. Un servidor comprometido es un pivote ideal. Llega directamente al pipeline, con acceso a secretos, credenciales de la nube, tokens de despliegue y código fuente. Los grupos de ransomware que buscan comprometer la cadena de suministro suelen entrar por vectores exactamente así.
La raíz del problema
Según Rapid7 Labs, la versión vulnerable de TeamCity monta una allowlist de XStream para restringir qué clases Java pueden ser deserializadas cuando el servidor procesa solicitudes de agente no autenticadas. El error es de omisión. El desarrollador añadió las clases del protocolo TeamCity a la lista, pero no eliminó los permisos predeterminados de XStream, que ya cubren una superficie amplia. El parche correcto inserta NoTypePermission.NONE antes de la allowlist, lo que transforma la lista en exclusiva. Rapid7 confirmó en laboratorio que la corrección resuelve el vector.
JetBrains divulgó la falla el 27 de julio y liberó builds corregidos el mismo día: TeamCity 2026.1.3 (build 222742) y TeamCity 2025.11.7 (build 208264). Para servidores que no pueden ser actualizados de inmediato, la empresa ofrece un plugin de seguridad que cubre versiones desde 2017.1. La CISA añadió la CVE al KEV el 5 de agosto e impuso un plazo de tres días para que las agencias federales aplicaran la corrección, con la fecha límite vencida el 8 de agosto.
Donde la exposición duele
En EE.UU., las agencias federales que ejecutan TeamCity en entornos de contratistas están bajo presión directa de la CISA. Las auditorías que la agencia suele realizar tras la inclusión en el KEV son conocidas por generar vergüenza pública, y los contratistas de defensa tendrán que documentar la remediación en un plazo ajustado o correr el riesgo de suspensión de su autorización para operar.
En Europa, el panorama es más diluido. JetBrains, con sede en Praga, tiene una base instalada concentrada en Alemania, República Checa, Polonia y Reino Unido, donde bancos y telcos utilizan TeamCity para orquestar pipelines de despliegue. Ninguna organización se ha pronunciado públicamente sobre la exposición hasta el cierre de este informe, que es el estándar para incidentes de esta naturaleza mientras los equipos de respuesta aún investigan. Tampoco hay evidencia divulgada de compromiso en nombres específicos, solo confirmación de explotación activa en masa por parte de la CISA.
Qué hacer si operas TeamCity
Los equipos de ingeniería deben tratar la actualización como un incidente Sev-1, no como una ventana de mantenimiento programada. El orden correcto es: actualizar a 2026.1.3 o 2025.11.7, o aplicar el plugin de seguridad; rotar todos los secretos almacenados en TeamCity, incluidos tokens de nube, claves SSH, credenciales de registro y API keys; auditar logs en busca de solicitudes al endpoint del agente anteriores al parche; y, para servidores expuestos a internet, verificar señales de persistencia como tareas cron inusuales, contenedores nuevos y conexiones salientes sospechosas.
En Brasil, integradores globales y bancos que operan pipelines de CI para core banking mantienen una exposición típica: TeamCity en red interna, sin exposición directa a internet, pero con acceso privilegiado a entornos de producción. El riesgo, para estas operaciones, está menos en la exposición pública y más en el movimiento lateral. Un atacante que ya esté dentro de la red corporativa, por cualquier vía, puede transformar TeamCity en un punto de escalada a un costo bajísimo, y la cadena termina en código de producción firmado con credenciales legítimas.
El bug común que el ecosistema aún no ha corregido
Lo que la CVE-2026-63077 revela no es el bug en sí, común en deserialización Java, sino lo poco que el ecosistema DevOps ha evolucionado en endurecimiento por defecto. Los servidores de CI continúan siendo tratados como herramientas internas, cuando en la práctica operan como intermediarios de credenciales de producción. Mientras esta premisa no cambie, la próxima cadena de suministro comprometida por esta vía solo espera al próximo XStream olvidado.