Rapid7 detalha falha crítica no TeamCity que já está sendo explorada, e CISA impôs prazo relâmpago

A Rapid7 atualizou nesta segunda-feira sua análise técnica da CVE-2026-63077, falha crítica de execução remota de código não autenticado no JetBrains TeamCity On-Premises, dias depois de a CISA adicioná-la ao catálogo de vulnerabilidades exploradas ativamente. A pontuação CVSS é 9,8 e o vetor é dos mais perigosos. Qualquer atacante com acesso HTTP ou HTTPS ao servidor consegue executar comandos de sistema operacional com os privilégios do processo TeamCity, sem precisar de credenciais.

O TeamCity é uma das plataformas de CI/CD mais adotadas por times de engenharia de médio e grande porte, com dezenas de milhares de servidores expostos à internet segundo levantamentos públicos do Shodan. Um servidor comprometido é um pivô ideal. Chega direto no pipeline, com acesso a segredos, credenciais de cloud, tokens de deploy e código-fonte. Grupos de ransomware que buscam supply chain compromise costumam entrar por vetores exatamente assim.

A raiz do problema

Segundo a Rapid7 Labs, a versão vulnerável do TeamCity monta uma allowlist do XStream para restringir quais classes Java podem ser desserializadas quando o servidor processa requisições de agente não autenticadas. O erro é de omissão. O desenvolvedor adicionou as classes do protocolo TeamCity à lista, mas não removeu as permissões default do XStream, que já cobrem superfície ampla. O patch correto insere NoTypePermission.NONE antes da allowlist, o que transforma a lista em exclusiva. A Rapid7 confirmou em bancada que a correção resolve o vetor.

A JetBrains divulgou a falha em 27 de julho e liberou builds corrigidos no mesmo dia: TeamCity 2026.1.3 (build 222742) e TeamCity 2025.11.7 (build 208264). Para servidores que não podem ser atualizados de imediato, a empresa oferece um security patch plugin que cobre versões desde 2017.1. A CISA adicionou a CVE ao KEV em 5 de agosto e impôs prazo de três dias para agências federais aplicarem a correção, com deadline vencida em 8 de agosto.

Onde a exposição machuca

Nos EUA, agências federais que rodam TeamCity em ambientes de contratistas estão sob pressão direta da CISA. As auditorias que a agência costuma fazer após inclusão no KEV são conhecidas por gerar constrangimento público, e contratistas de defesa terão que documentar remediação em prazo apertado ou correr risco de suspensão de authority to operate.

Na Europa, o quadro é mais diluído. A JetBrains, sediada em Praga, tem base instalada concentrada na Alemanha, na República Tcheca, na Polônia e no Reino Unido, onde bancos e telcos rodam TeamCity para orquestrar pipelines de deploy. Nenhuma organização se pronunciou publicamente sobre a exposição até o fechamento desta matéria, o padrão para incidentes desta natureza enquanto times de resposta ainda investigam. Não há, também, evidência divulgada de comprometimento em nomes específicos, apenas confirmação de exploração ativa em massa pela CISA.

O que fazer se você opera TeamCity

Times de engenharia devem tratar a atualização como incidente Sev-1, não como janela de manutenção programada. A ordem correta é: atualizar para 2026.1.3 ou 2025.11.7, ou aplicar o security patch plugin; rotacionar todos os segredos armazenados no TeamCity, incluindo tokens de nuvem, chaves SSH, credenciais de registry e API keys; auditar logs em busca de requisições ao endpoint do agente anteriores ao patch; e, para servidores expostos à internet, verificar sinais de persistência como tarefas cron incomuns, contêineres novos e conexões saintes suspeitas.

No Brasil, integradores globais e bancos que operam pipelines de CI para core banking mantêm exposição típica: TeamCity em rede interna, sem exposição direta à internet, mas com acesso privilegiado a ambientes de produção. O risco, para essas operações, está menos na exposição pública e mais em movimento lateral. Um atacante que já esteja dentro da rede corporativa, por qualquer via, consegue transformar o TeamCity em ponto de escalada com custo baixíssimo, e a cadeia termina em código de produção assinado com credencial legítima.

O bug corriqueiro que o ecossistema ainda não corrigiu

O que a CVE-2026-63077 escancara não é o bug em si, corriqueiro em desserialização Java, mas o quão pouco o ecossistema DevOps evoluiu em endurecimento por default. Servidores de CI continuam sendo tratados como ferramentas internas, quando na prática operam como brokers de credenciais de produção. Enquanto essa premissa não mudar, a próxima cadeia de suprimento comprometida por essa via só espera o próximo XStream esquecido.