CVE-2026-63077 en TeamCity: la RCE no autenticada que puso a CISA a exigir un parche en 72 horas
JetBrains parcheó una vulnerabilidad crítica en TeamCity On-Premises a fines de julio; para el 7 de agosto ya había explotación activa confirmada. El caso es un recordatorio concreto de que el servidor de CI/CD merece el mismo nivel de blindaje que producción, no menos.
El 27 de julio, JetBrains publicó un aviso de seguridad para TeamCity On-Premises que, a primera vista, se parecía a decenas de otros CVE que cualquier equipo de plataforma ve pasar cada mes. Diez días después, el 7 de agosto, esa misma vulnerabilidad ya tenía explotación activa confirmada en internet, la Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) la había sumado a su catálogo de vulnerabilidades explotadas conocidas (KEV) el 5 de agosto, y las agencias federales de ese país tenían hasta el 8 de agosto para parchear. Ese es el ritmo real al que se mueve hoy la explotación de una falla en herramientas de CI/CD, y es la razón por la que vale la pena mirar el caso con detalle, más allá de si tu organización usa TeamCity puntualmente.
Qué es CVE-2026-63077
La falla, con puntaje CVSS de 9.8 sobre 10, es una vulnerabilidad de deserialización de datos no confiables en el protocolo de sondeo de agentes (agent polling protocol) que usa TeamCity para comunicarse entre el servidor y los agentes de build. Según la propia JetBrains, un atacante sin autenticar que tenga acceso HTTP(S) al servidor puede explotarla para saltarse los controles de autenticación y ejecutar comandos de sistema operativo arbitrarios, con los mismos privilegios que tiene el proceso del servidor de TeamCity.
El análisis técnico que publicó Rapid7 el 7 de agosto (actualizado el 10) explica el mecanismo con precisión: TeamCity usa la librería XStream para deserializar los datos que le llegan de los agentes, y define una lista de permitidos (allowlist) de qué clases Java puede deserializar. El problema es que esa allowlist agregaba las clases propias del protocolo de TeamCity sin remover los permisos por defecto que trae XStream, lo que en la práctica dejaba la puerta abierta a deserializar clases arbitrarias. El parche corrige esto agregando NoTypePermission.NONE antes de la allowlist de TeamCity, con lo que la lista pasa de ser aditiva a ser exclusiva. Rapid7 llegó a publicar un script de prueba de concepto en Python que explota la falla escribiendo un archivo .JSPWS —una extensión personalizada de JSP— para ejecutar un comando arbitrario y borrarlo del disco después, lo cual da una idea de lo directo que es el camino de explotación una vez que se entiende el bug.
Por qué un servidor de build es un objetivo tan atractivo
El impacto que describe JetBrains no es abstracto: un ataque exitoso puede exponer datos y configuraciones del servidor, credenciales almacenadas, modificar el estado del servidor y —lo más delicado— comprometer la integridad de los artefactos de build y de los pipelines de CI/CD que dependen de ellos. Un servidor de TeamCity suele tener acceso a repositorios de código fuente, credenciales de despliegue, tokens de registries de contenedores y, en muchos casos, llaves para firmar artefactos. Comprometer ese único punto no es solo robar datos: es ganar la capacidad de inyectar código malicioso en el software que la organización termina distribuyendo, que es exactamente el patrón detrás de los incidentes de cadena de suministro de software más costosos de los últimos años.
Qué hacer si corrés TeamCity On-Premises
La corrección está disponible desde el aviso original: actualizar a TeamCity 2025.11.7 o 2026.1.3. Para quien no pueda actualizar de inmediato, JetBrains publicó un plugin de parche de seguridad que cubre específicamente este CVE en versiones desde 2017.1 en adelante —aunque la recomendación oficial sigue siendo actualizar el servidor completo para recibir el resto de las correcciones acumuladas. Los clientes de TeamCity Cloud no necesitan hacer nada: la mitigación ya se aplicó del lado de JetBrains.
Para investigar si hubo intentos de explotación, JetBrains da dos señales concretas para buscar en los logs del servidor. La aparición del mensaje com.thoughtworks.xstream.converters.ConversionException puede indicar un intento, exitoso o no, y amerita revisión. En servidores ya parchados, el mensaje com.thoughtworks.xstream.security.ForbiddenClassException indica que un intento de explotación fue bloqueado correctamente por el parche. También conviene revisar la lista de agentes de build no autorizados en busca de entradas inesperadas, en particular agentes cuyo nombre empiece con scan —un patrón asociado a escaneos automatizados que prueban la vulnerabilidad—, aunque la fecha que muestra un agente no autorizado no necesariamente coincide con el momento real del intento; para eso hay que guiarse por los timestamps de los mensajes de log.
Como medida adicional, si el servidor es accesible desde internet y no se puede aplicar el parche de inmediato, JetBrains recomienda restringir el acceso externo hasta poder hacerlo. Y como práctica de fondo, independientemente de este CVE puntual: limitar el acceso de red a servidores de TeamCity a redes de confianza, correr el proceso del servidor con el mínimo privilegio de sistema operativo necesario, exigir VPN para servidores expuestos a internet, y —punto que suele pasarse por alto— correr el servidor de TeamCity en un host dedicado, separado de los agentes de build, tal como recomienda la propia documentación de JetBrains.
La conclusión práctica para esta semana
Uses o no TeamCity, el caso deja una lista de verificación que aplica a cualquier herramienta de CI/CD —Jenkins, GitLab CI, Bamboo, Azure DevOps Server— porque todas comparten el mismo perfil de riesgo: acceso privilegiado a código, credenciales y proceso de release, muchas veces expuesto a una red más amplia de lo que el equipo de seguridad cree.
Primero, inventariá qué servidores de CI/CD tiene tu organización y cuáles son alcanzables desde internet sin VPN de por medio; en la práctica, ese inventario suele tener sorpresas. Segundo, tratá los CVE de tus herramientas de build con la misma urgencia que los de tus servidores de producción, no con menos: el incidente de TeamCity mostró que el tiempo entre parche público y explotación activa en la vida real puede ser de apenas diez días. Tercero, si administrás TeamCity específicamente, actualizá a 2025.11.7 o 2026.1.3 esta semana, revisá los logs en busca de los mensajes mencionados arriba y remové cualquier agente no autorizado que encuentres. Y cuarto, aprovechá el caso para conversar con tu equipo sobre integridad de artefactos: firmar builds, verificar procedencia (SLSA u otro marco equivalente) y separar el servidor de CI/CD de los agentes ya no es una discusión teórica de conferencia de seguridad, es lo que hubiera limitado el radio de impacto de este incidente puntual.