JetBrains publicó el 28 de julio de 2026 un aviso por CVE-2026-63077, un bypass de autenticación con CVSS 9.8 que permite ejecutar comandos del sistema operativo en TeamCity On-Premises sin ninguna credencial.
Alcanza con tener acceso HTTP o HTTPS al servidor. Todas las versiones On-Premises están afectadas.
Dónde está el problema
El vector es el protocolo de polling de agentes, el mecanismo por el que los agentes de build consultan al servidor si hay trabajo pendiente.
Un atacante no autenticado puede «saltearse los chequeos de autenticación y ejecutar comandos arbitrarios del sistema operativo» a través de ese canal.
El impacto declarado va más allá de la ejecución: exposición de credenciales y de la configuración del servidor, y modificación del estado del servidor.
Por qué un servidor de CI es un objetivo de primera
Comprometer un servidor de integración continua no es equivalente a comprometer un servidor cualquiera.
TeamCity guarda, casi por definición, las credenciales que dan acceso al resto de la infraestructura: tokens de repositorios, claves de despliegue, credenciales de registries y accesos a entornos productivos.
Y además ejecuta código como parte de su función normal, lo que vuelve más difícil distinguir la actividad maliciosa del trabajo legítimo.
Es el mismo motivo por el que las campañas contra servidores de CI vienen creciendo: es el punto donde convergen el acceso al código fuente y la capacidad de modificar lo que se despliega.
Versiones corregidas
JetBrains corrigió el problema en:
- TeamCity 2025.11.7.
- TeamCity 2026.1.3.
Las instancias de TeamCity Cloud ya fueron parcheadas por JetBrains, así que no requieren acción del cliente.
El hallazgo se le atribuye a Antoni Tremblay y fue reportado el 10 de julio, con anuncio público el 28.
Si no podés actualizar ya
JetBrains publicó un plugin de parche de seguridad disponible para versiones desde 2017.1 en adelante, pensado justamente para instalaciones viejas que no pueden saltar de versión rápido.
Las medidas complementarias son las de siempre, y siguen siendo las más efectivas:
- Restringir el acceso al servidor de TeamCity detrás de VPN.
- No exponer a internet la pantalla de login ni las APIs REST.
- Sumar capas adicionales de control de acceso.
Al momento del aviso no había evidencia de explotación en el mundo real. La historia reciente de TeamCity, sin embargo, sugiere que esa ventana suele ser corta: versiones anteriores fueron blanco de campañas masivas a los pocos días de publicarse los detalles.
¿Cuántos servidores de build tienen expuestos a internet?
La respuesta honesta en muchas organizaciones es «más de los que creemos», porque los servidores de CI suelen abrirse temporalmente para integrar con algún servicio externo y esa excepción queda.
¿Ya revisaron la exposición de su TeamCity? Te leemos en los comentarios.


