Introducción
Un servidor de compilación expuesto a internet con un binario de TeamCity desactualizado basta para que un atacante sin credenciales ejecute comandos arbitrarios del sistema operativo y comprometa toda la cadena de CI/CD. CVE-2026-63077 no es una vulnerabilidad teórica: JetBrains la parcheó el 25 de julio, CISA la incorporó al catálogo KEV el 5 de agosto, y esta semana la agencia estadounidense actualizó la alerta para confirmar que bandas de ransomware la explotan activamente. Para los equipos de infraestructura que sostienen pipelines de compilación sobre TeamCity On-Premises —ya sea en instancias EC2, contenedores Docker o clusters EKS—, el margen de acción se redujo a horas, no semanas.
Qué ocurrió
El 25 de julio, JetBrains liberó parches para TeamCity On-Premises versiones 2025.11.7 y 2026.1.3, corrigiendo CVE-2026-63077, una falla crítica de bypass de autenticación en el protocolo de polling de agentes. El vector es directo: un atacante que alcance el puerto HTTP(S) del servidor TeamCity puede falsificar la comunicación con un agente legítimo, eludir las verificaciones de identidad y ejecutar comandos del SO con los privilegios del proceso del servidor. No requiere credenciales, no requiere acceso previo al panel.
CISA añadió la CVE al Known Exploited Vulnerabilities Catalog el 5 de agosto y ordenó a las agencias federales de EE.UU. mitigar la exposición en un plazo de 72 horas. JetBrains confirmó la explotación en el mundo real el 7 de agosto, publicó indicadores de compromiso (IOCs) y recomendó a los clientes que no podían parchear de inmediato restringir el acceso a redes confiables. La actualización de esta semana de CISA no aporta un nuevo vector: reconfirma que el tráfico observado corresponde a operaciones de ransomware, no solo a espionaje o minería.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
TeamCity no es un servidor web cualquiera. Gestiona credenciales de artefactos, tokens de acceso a repositorios Git, claves de despliegue a Kubernetes, secretos de AWS y configuraciones de pipelines que alimentan producción. Una vez que el atacante ejecuta comandos con los privilegios del proceso teamcity-server, accede al directorio data/config/, roba credenciales almacenadas y puede inyectar código malicioso en los artefactos de compilación que se distribuyen a miles de endpoints.
El contexto agrava el riesgo. Desde octubre de 2023, CISA marcó cuatro vulnerabilidades de TeamCity como explotadas en el campo, todas vinculadas a ataques de ransomware. En octubre de 2024, la NSA y el NCSC británico advirtieron que APT29, vinculado al Servicio de Inteligencia Exterior de Rusia (SVR), atacaba servidores TeamCity y Zimbra «a escala masiva». JetBrains declara más de 30.000 equipos DevOps usando la plataforma, con nombres como Citibank, Amazon Games, Tesla y Samsung en la lista de clientes.
Shadowserver, el servicio de telemetría de seguridad, identificó aproximadamente 700 servidores TeamCity expuestos a internet vulnerables justo tras el parche. A la fecha del reporte, ese número bajó a poco más de 160. Sigue siendo una superficie de ataque activa y documentada.
Detalles técnicos
La vulnerabilidad reside en el protocolo de comunicación entre el servidor TeamCity y sus agentes. Los agentes se registran mediante polling HTTP(S) y el servidor valida su identidad a través de un token de registro y un handshake interno. CVE-2026-63077 permite que un atacante no autenticado forje ese handshake, pase la verificación y obtenga una sesión con permisos equivalentes al servicio teamcity-server. El impacto depende de los privilegios del proceso: si TeamCity corre como root en Linux o como SYSTEM en Windows, la ejecución arbitraria compromete el host completo.
Versiones afectadas: TeamCity On-Premises anteriores a 2025.11.7 y anteriores a 2026.1.3. Las ediciones SaaS (TeamCity Cloud) no están expuestas porque JetBrains gestiona la infraestructura del servidor.
En despliegues Docker, el riesgo se amplifica. Si el contenedor de TeamCity corre con –privileged o monta el socket de Docker del host (-v /var/run/docker.sock:/var/run/docker.sock), el atacante que ejecute comandos dentro del contenedor escala a root en el nodo. En arquitecturas sobre EKS o Kubernetes, un pod de TeamCity con ServiceAccount de alto nivel permite enumerar secretos del namespace, manipular deployments y pivotar hacia otros workloads del cluster.
El proceso de compilación es el segundo salto lateral. Un artefacto alterado en la pipeline se despliega a producción sin que los controles de code review lo detecten, porque la inyección ocurre a nivel de binario o imagen, no de código fuente.
Qué deberían hacer los administradores y equipos técnicos
Parcheo inmediato. Actualizá a TeamCity 2025.11.7 o 2026.1.3 según la rama que uses. En Linux con paquete .deb o .rpm, ejecutá el instalador oficial de JetBrains y reiniciá el servicio teamcity. En Docker, reemplazá la imagen por la versión parcheada y recreá el contenedor. No postergues: el plazo CISA para federales fue 72 horas y las bandas de ransomware no respetan ventanas de mantenimiento trimestrales.
Restringí la exposición. Si no podés parchear hoy, eliminá la publicación del puerto 443 (o 8111) del servidor TeamCity a internet. Limitá el acceso a IPs de tu red corporativa o a un grupo de agentes conocido. En AWS, ajustá el Security Group del grupo de instancias para permitir inbound solo desde rangos internos. En Kubernetes, aplicá NetworkPolicies que restrinjan el tráfico al pod de TeamCity.
Auditá privilegios. Verificá que el proceso teamcity-server no corra como root ni como SYSTEM. En Linux, confirmá que el usuario de servicio sea teamcity con permisos mínimos sobre el directorio de instalación. En Docker, eliminá –privileged y el mount del socket de Docker. En EKS, revisá que el ServiceAccount del namespace de CI/CD no tenga permisos cluster-admin ni acceso a secretos de otros namespaces.
Revisá artefactos y credenciales. Tras el parcheo, rotá todos los tokens de acceso, API keys y credenciales almacenadas en la configuración de TeamCity. Revisá los logs de agentes y compilaciones del período entre el 25 de julio y la fecha de parcheo buscando conexiones desde IPs desconocidas o comandos anómalos. Compará checksums de artefactos publicados en repositorios internos contra los originales.
Monitoreá IOCs. JetBrains publicó indicadores de compromiso el 7 de agosto. Incorporalos a tu SIEM o EDR. Si usás Wazuh, Suricata o CloudTrail para detección, cargá las firmas específicas y generá alertas ante conexiones entrantes al puerto de TeamCity desde IPs no autorizadas.
Planificá contingencia de pipeline. Si un servidor de compilación se compromete, tenés un proceso definido para revertir artefactos, invalidar firmas de imágenes y re-ejecutar builds desde un snapshot limpio? Si la respuesta es «depende de quién esté de guardia», documentalo antes del próximo incidente.
Conclusión
Cuatro CVEs de TeamCity explotadas en menos de tres años, todas vinculadas a ransomware, configuran un patrón que no admite complacencia. La arquitectura de CI/CD es un objetivo prioritario porque una sola brecha contamina cientos o miles de despliegues downstream. Los 160 servidores que Shadowserver aún rastrea sin parchear representan una ventana que los operadores de ransomware ya están usando. El parche existe desde hace más de un mes. La restricción de acceso a redes confiables es un paliado de horas, no una estrategia. Actualizá, cerrá la superficie, rotá credenciales y verificá la integridad de tus artefactos.
Fuentes
- https://www.bleepingcomputer.com/news/security/cisa-ransomware-gangs-now-exploiting-critical-teamcity-flaw/
- https://www.bankinfosecurity.com/