TeamCity ya se explota en ataques: el parche no admite más espera
JetBrains informó el 7 de agosto de 2026 que había recibido reportes de explotación activa e intentos contra servidores TeamCity sin corregir. La actualización de seguridad de JetBrains precisa que CVE-2026-63077 permite ejecutar comandos del sistema operativo sin autenticación cuando una instalación vulnerable de TeamCity On-Premises es accesible mediante HTTP o HTTPS.
El mismo 7 de agosto, el riesgo ya no podía tratarse como una posibilidad teórica: los ataques reportados afectaban a servidores On-Premises sin parchear, mientras que TeamCity Cloud ya tenía aplicadas las mitigaciones. CISA había incorporado la vulnerabilidad el 5 de agosto a su catálogo de vulnerabilidades explotadas, que reúne fallos con evidencia de uso en ataques reales.
El riesgo está en TeamCity On-Premises
La exposición se limita al producto instalado en infraestructura propia. TeamCity Cloud no requiere ninguna acción del cliente para este fallo: JetBrains indica que ya aplicó las medidas necesarias y que no tiene constancia de explotación de sus entornos alojados.
En un servidor On-Premises afectado, el atacante no necesita una cuenta, una sesión válida ni interacción de un usuario. Puede aprovechar el protocolo con el que los agentes consultan al servidor y ejecutar comandos con los privilegios del proceso de TeamCity. Por tanto, el alcance posterior depende de los permisos de esa cuenta de servicio y de los sistemas conectados al entorno de integración y despliegue continuos.
El registro de CVE-2026-63077 en NVD clasifica el problema como deserialización de datos no confiables y recoge una puntuación CVSS 3.1 de 9,8 aportada por JetBrains. El vector refleja un ataque por red, de baja complejidad, sin privilegios previos ni intervención del usuario, con impacto alto sobre confidencialidad, integridad y disponibilidad.
La ruta de corrección depende de la instalación
Las dos compilaciones corregidas son TeamCity 2025.11.7 y 2026.1.3. Para instalaciones que no puedan actualizarse de inmediato, el fabricante ofrece un complemento específico compatible con TeamCity 2017.1 y versiones posteriores, según el aviso técnico original de JetBrains.
- TeamCity Cloud: no necesita una actualización gestionada por el cliente, porque la mitigación ya fue aplicada en el servicio.
- Rama 2025.11 de TeamCity On-Premises: debe actualizarse como mínimo a 2025.11.7.
- Rama 2026.1 de TeamCity On-Premises: debe actualizarse como mínimo a 2026.1.3.
- TeamCity 2017.1 o posterior sin posibilidad inmediata de actualización: puede protegerse contra este fallo con el complemento de seguridad.
- Versiones anteriores a 2017.1: no están dentro del intervalo de compatibilidad anunciado para el complemento y necesitan migrar a una compilación corregida.
El complemento corrige únicamente CVE-2026-63077, no el resto de los problemas de seguridad resueltos en versiones posteriores. En TeamCity 2017.1 a 2018.1 es necesario reiniciar el servidor después de instalarlo; desde 2018.2 puede habilitarse sin reinicio. Las versiones 2024.03 y posteriores descargan los complementos de seguridad disponibles y pueden notificarlos al administrador, pero su aplicación aún debe verificarse.
Credenciales, código y artefactos quedan dentro del alcance
La ejecución remota no convierte automáticamente cada incidente en un robo de toda la cadena de suministro, pero tampoco debe evaluarse como el compromiso aislado de un servidor web. TeamCity coordina compilaciones y despliegues, conserva configuraciones y puede comunicarse con repositorios, registros de paquetes, servicios en la nube y entornos de producción.
Si un servidor permaneció accesible y sin corregir durante el periodo de explotación, una investigación debe delimitar qué recursos podía utilizar el proceso de TeamCity:
- credenciales almacenadas, parámetros protegidos y tokens empleados en las compilaciones;
- claves y credenciales de acceso a repositorios de código fuente;
- configuraciones de proyectos, pasos de compilación y reglas de despliegue;
- artefactos generados, paquetes publicados y metadatos de compilaciones;
- credenciales de registros de contenedores, almacenes de artefactos y plataformas en la nube;
- agentes autorizados, integraciones externas y destinos posteriores de la cadena CI/CD.
La inclusión de un activo en este inventario no demuestra que haya sido sustraído o alterado. Significa que estaba potencialmente al alcance del proceso comprometido y debe considerarse al reconstruir el incidente. Instalar la corrección bloquea nuevas explotaciones por esta vía, pero no elimina por sí solo persistencia, credenciales robadas o cambios realizados con anterioridad.
Los registros aportan indicios, no una confirmación aislada
En una instancia vulnerable, el mensaje com.thoughtworks.xstream.converters.ConversionException puede corresponder a un intento o a una explotación exitosa, aunque su presencia por sí sola no prueba el compromiso. En un servidor ya corregido, com.thoughtworks.xstream.security.ForbiddenClassException puede señalar que el complemento o la versión reparada bloqueó un intento posterior.
También pueden aparecer agentes no autorizados inesperados, en particular nombres que comienzan por “scan”. La fecha mostrada para uno de esos agentes no necesariamente coincide con el momento del intento; para establecer la secuencia temporal deben prevalecer las marcas de los registros relacionados.
El aviso del 7 de agosto confirma reportes de explotación y mantiene disponibles tres vías de protección: las compilaciones 2025.11.7 y 2026.1.3, o el complemento para instalaciones desde 2017.1. JetBrains no identifica en su actualización a los responsables ni cuantifica el número de servidores afectados, por lo que siguen pendientes detalles sobre la escala y las campañas observadas.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.