Uma vulnerabilidade crítica no TeamCity, plataforma de CI/CD amplamente usada por equipes de desenvolvimento para automação de build, testes e deploy, permite que um atacante execute comandos arbitrários no sistema operacional sem precisar de nenhuma credencial. A falha foi catalogada como CVE-2026-63077 e afeta instalações On-Premises do produto. Se sua organização roda TeamCity internamente, este é um patch que não pode esperar o próximo ciclo de manutenção.

O que é a CVE-2026-63077 e por que ela é tão grave

A CVE-2026-63077 recebeu pontuação CVSS 9.8, o topo da escala de severidade. Essa nota reflete uma combinação perigosa: exploração remota, sem necessidade de autenticação, sem interação do usuário, e impacto total em confidencialidade, integridade e disponibilidade.

Na prática, isso significa que qualquer atacante com acesso de rede à interface do TeamCity pode explorar a falha diretamente, sem precisar de login, senha, token ou qualquer tipo de credencial válida. Não há necessidade de engenharia social, phishing ou acesso interno prévio — basta alcançar o servidor vulnerável pela rede.

Um ponto importante para quem administra a ferramenta: o TeamCity Cloud, versão hospedada e gerenciada pela JetBrains, não é afetado pela falha. O risco está concentrado nas instalações On-Premises, onde a responsabilidade por aplicar patches e configurar a segurança do servidor recai inteiramente sobre a equipe de infraestrutura da própria organização.

Como a vulnerabilidade funciona na prática

Execução de código sem autenticação prévia

A falha permite que um atacante acione a execução de comandos no sistema operacional subjacente ao servidor TeamCity sem passar por nenhuma etapa de autenticação. Isso coloca a CVE-2026-63077 na categoria mais crítica de vulnerabilidades: pré-autenticação (pre-auth) com Remote Code Execution (RCE). Uma vez explorada, o atacante ganha capacidade de executar comandos com os privilégios do processo do TeamCity no servidor — o que, dependendo da configuração do ambiente, pode significar controle total da máquina.

Versões afetadas e versões corrigidas (2025.11.7 e 2026.1.3)

As correções foram disponibilizadas nas versões 2025.11.7 e 2026.1.3. Qualquer instalação On-Premises rodando versões anteriores a essas deve ser considerada vulnerável e tratada como prioridade máxima de remediação. Não existe mitigação parcial documentada que substitua a aplicação do patch — a atualização para uma versão corrigida é a única resposta efetiva.

Por que servidores de CI/CD são alvos tão valiosos

Um servidor de CI/CD comprometido não é um incidente isolado — é um ponto de entrada para praticamente tudo o que a organização constrói e implanta. O TeamCity, como orquestrador central de pipelines, normalmente tem acesso a:

• Repositórios de código-fonte, incluindo projetos proprietários e ainda não lançados
• Segredos de build: chaves de API, tokens de assinatura de código, credenciais de registries privados
• Credenciais de deploy para ambientes de staging e produção
• Conectividade direta com ambientes de produção, muitas vezes com permissões elevadas para automatizar releases

Um atacante que compromete o servidor de build não precisa mais invadir a aplicação final — ele pode inserir código malicioso diretamente no pipeline, comprometendo tudo que passar por ali dali em diante. É exatamente esse tipo de posição estratégica na cadeia de desenvolvimento que torna o TeamCity um elo crítico da supply chain de software, e explica por que vulnerabilidades como essa recebem atenção prioritária de grupos de ataque mais sofisticados.

Comparando com falhas em aplicações web comuns

Uma vulnerabilidade de auth bypass combinada com RCE em uma aplicação web de front-end já é grave. Na ferramenta de build, o impacto é ampliado. Enquanto uma aplicação comprometida geralmente expõe dados daquele sistema específico, um servidor de CI/CD comprometido expõe todo o processo de construção de software da organização — com potencial de afetar múltiplos produtos, múltiplos times e, em cenários de distribuição de software para clientes, múltiplas organizações downstream.

Esse padrão de risco elevado em sistemas com privilégios amplos e conectividade crítica também aparece em outras plataformas corporativas centrais, como demonstrado pela vulnerabilidade crítica em sistemas SAP que pode permitir invasão total de sistemas corporativos. O paralelo é direto: sistemas que concentram privilégios e conectividade ampla exigem um padrão de proteção mais rigoroso do que aplicações isoladas.

O histórico de exploração ativa do TeamCity

Esta não é a primeira vez que o TeamCity aparece no radar de ataques ativos. A CVE-2023-42793, outra falha crítica de RCE na plataforma, foi explorada em campanhas atribuídas a atores estatais, gerando alertas específicos da CISA (Cybersecurity and Infrastructure Security Agency) sobre o risco de comprometimento de cadeias de suprimento de software através de servidores de build expostos.

O padrão se repete: falhas críticas em ferramentas de CI/CD atraem atenção de atacantes motivados, e o intervalo entre a divulgação de uma vulnerabilidade e sua exploração em massa tende a ser curto. Organizações que não aprenderam a lição da CVE-2023-42793 — mantendo instâncias desatualizadas e expostas — estão no grupo de maior risco diante da CVE-2026-63077.

Como identificar se sua organização está exposta

Buscando instâncias TeamCity expostas na internet (Shodan/Censys)

Ferramentas de reconhecimento como Shodan e Censys permitem localizar rapidamente instâncias TeamCity acessíveis publicamente, identificando banners de serviço, portas padrão e versões expostas em cabeçalhos HTTP. Equipes de segurança devem realizar essa busca ativamente sobre seus próprios ativos — e não assumir que “ninguém sabe que o servidor existe” é uma estratégia de proteção válida. Se o servidor está acessível pela internet pública, ele será encontrado.

Riscos de ferramentas de CI/CD sem segmentação de rede

Mesmo instâncias que não estão diretamente expostas à internet podem representar risco significativo se não houver segmentação adequada dentro da rede interna. Um atacante que ganha um ponto de apoio inicial em qualquer parte da rede — via phishing, VPN comprometida ou outra vulnerabilidade — pode se mover lateralmente até o servidor de CI/CD se não houver controles de rede limitando esse acesso. Esse problema de exposição de infraestrutura interna sem segmentação adequada é o mesmo padrão de risco discutido na análise sobre a vulnerabilidade crítica no Windows Server que pode permitir sequestrar a infraestrutura de rede: perímetro não é suficiente, segmentação interna é obrigatória.

Checklist de resposta imediata para equipes de segurança

Para equipes que operam TeamCity On-Premises, a resposta deve ser imediata e estruturada:

1. Inventariar todas as instâncias TeamCity da organização, incluindo ambientes de teste, homologação e instâncias esquecidas ou legadas.
2. Verificar a versão em execução em cada instância e confirmar se está na lista de versões afetadas.
3. Aplicar o patch imediatamente, atualizando para a versão 2025.11.7 ou 2026.1.3, conforme o ramo de versão utilizado.
4. Revisar logs de acesso recentes em busca de indicadores de exploração, requisições anômalas ou execução de comandos não autorizados no período anterior à correção.
5. Rotacionar credenciais e segredos de build que possam ter sido expostos — tokens de API, chaves de assinatura, credenciais de deploy e qualquer segredo armazenado ou acessível pelo TeamCity.

Esse checklist deve ser tratado como resposta a incidente, não como tarefa de manutenção rotineira, dado o CVSS 9.8 e o histórico de exploração ativa de falhas anteriores na mesma plataforma.

Como prevenir incidentes semelhantes no futuro

Boas práticas de hardening para servidores de CI/CD

Patches corrigem vulnerabilidades conhecidas, mas não substituem uma arquitetura de segurança sólida. Servidores de CI/CD devem estar isolados em segmentos de rede dedicados, com acesso restrito por princípio de menor privilégio, autenticação multifator obrigatória para administradores, e monitoramento ativo de logs e comportamento anômalo. Segredos de build nunca devem ficar armazenados em texto claro na configuração do servidor, e o acesso a credenciais de produção a partir do pipeline deve ser auditado e limitado ao estritamente necessário.

Complementando patches com testes contínuos de segurança

Aplicar patches reativamente, apenas após a divulgação de uma CVE, é insuficiente como estratégia. Testes contínuos de segurança — scans de vulnerabilidade recorrentes e pentests direcionados à infraestrutura de CI/CD — identificam configurações inseguras, exposições desnecessárias e falhas antes que se tornem manchete. Entender as diferenças entre scans de vulnerabilidades e pentests ajuda equipes de segurança a estruturar um programa de testes que combine cobertura ampla e recorrente com validação profunda de cenários de exploração real.

Conclusão: CI/CD como prioridade estratégica de segurança

A CVE-2026-63077 reforça um padrão que já deveria estar consolidado nas prioridades de segurança de qualquer organização que desenvolve software: servidores de CI/CD não são infraestrutura secundária, são ativos críticos que concentram acesso a código-fonte, segredos e ambientes de produção. Uma falha de RCE sem autenticação nessa camada equivale a dar as chaves da cadeia de desenvolvimento inteira para quem a explorar primeiro.

Se sua organização opera TeamCity On-Premises, a prioridade agora é confirmar a versão em execução e aplicar o patch. Depois disso, vale revisar se sua infraestrutura de CI/CD como um todo está segmentada, monitorada e testada com a mesma seriedade dedicada aos sistemas de produção. A Resh pode ajudar sua equipe a avaliar a exposição real desses ambientes através de testes de segurança contínuos e pentests direcionados à cadeia de desenvolvimento — entre em contato para uma avaliação.