JetBrains corrige falha crítica 9.8 no TeamCity que permite execução remota sem autenticação
CVE-2026-63077 no protocolo de polling do agente deixa qualquer atacante com acesso HTTP executar código no servidor. Todas as instalações On-Premises anteriores a 2025.11.7 e 2026.1.3 estão vulneráveis.
A JetBrains publicou no dia 27 de julho um aviso pedindo que todos os clientes do TeamCity On-Premises atualizem para as versões 2025.11.7 ou 2026.1.3. A empresa corrigiu ali a CVE-2026-63077, uma falha de deserialização insegura no protocolo de polling entre servidor e agentes de build que recebeu nota 9.8 no CVSS v3.1 e permite execução remota de código sem qualquer autenticação.
O problema está na CWE-502, deserialização de dados não confiáveis, exposta no canal que os agentes de build usam para consultar o servidor por novos jobs. Um atacante com acesso HTTP ou HTTPS ao servidor manda um payload malicioso para o endpoint de polling e ganha execução no processo do TeamCity, sem sessão, sem token e sem interação do usuário. Todas as versões On-Premises anteriores aos patches estão vulneráveis.
O pesquisador Antoni Tremblay reportou a falha em 10 de julho via o programa de divulgação coordenada da JetBrains. A empresa diz que não observou exploração ativa até a publicação do aviso e disponibilizou também um plugin de patch de segurança para instalações mais antigas, com suporte a partir da versão 2017.1. Clientes do TeamCity Cloud não precisam agir: o ambiente gerenciado já foi corrigido.
Base instalada e leitura de risco global
O TeamCity aparece em pelo menos 30 mil implantações, segundo a própria JetBrains, com uma lista de clientes que inclui Citibank, Ferrari, Wargaming e a divisão Oculus da Meta. Estudos de mercado da Datanyze colocam a plataforma na segunda posição em CI, com 18,7% de participação, atrás apenas do Jenkins e à frente de alternativas mais recentes como o GitHub Actions em ambientes corporativos legados. A concentração está nos Estados Unidos, Alemanha e Austrália, os três mercados com maior adoção declarada.
Servidores de CI/CD são um dos alvos mais valorizados por atacantes hoje. Quem controla o TeamCity controla o pipeline, e por extensão o binário assinado que entra em produção. A comparação inevitável é com o incidente da 3CX de 2023 e o compromisso da CircleCI no mesmo ano, ambos usados como plataforma para ataques de supply chain a terceiros. Foi por essa razão que a CISA colocou uma falha anterior de TeamCity, a CVE-2024-27198, no seu catálogo KEV em março de 2024, poucas semanas depois do disclosure. Naquela ocasião, o BianLian e outros grupos ransomware começaram a varrer a internet em busca de servidores expostos em menos de 72 horas depois da publicação do exploit público.
A dor não se restringe a Frankfurt ou San Jose. Centros de delivery da Cognizant, Infosys e TCS na Índia rodam TeamCity como parte do stack contratado por bancos americanos e europeus; um servidor comprometido em Bangalore ou Pune abre porta para o repositório do cliente na City de Londres. No Brasil, ambientes de shared services de bancos de médio porte e times de engenharia de fintechs paulistas usam TeamCity como orquestrador de builds Java e .NET, herança do peso histórico da JetBrains em desenvolvimento corporativo. Para o CISO daqui, a leitura é a mesma: se o servidor está exposto à internet ou a uma rede corporativa ampla, o patch é para agora.
O que fazer nas próximas 48 horas
A recomendação direta da JetBrains: para quem está no ramo 2026.x, subir para a 2026.1.3; para quem está no ramo 2025.11.x, subir para 2025.11.7. O plugin de patch resolve para quem trava em versões antigas, mas não substitui a atualização. Segregar o servidor do TeamCity da internet pública, ainda que o vendor não mencione o ponto no aviso, elimina o vetor principal enquanto a janela de exposição diminui. Times de resposta que já rodam varredura interna com Nuclei ou Tenable devem priorizar a assinatura assim que ela cair, e revisar logs do endpoint de agent polling em busca de payloads binários incomuns nas últimas duas semanas, faixa que cobre a janela entre report privado e disclosure público.
Uma nota final sobre calendário. Entre a data em que Tremblay reportou a falha, 10 de julho, e o disclosure público, dia 27, passaram-se dezessete dias. É uma janela curta para uma correção que envolve mudança no protocolo. A JetBrains agiu rápido depois do incidente de 2024, quando a Rapid7 quebrou embargo e forçou o disclosure antecipado. A pergunta que fica para o time de segurança do cliente é outra: quanto tempo, agora que o CVE está público, até a primeira exploração no wild?