VORVEXAPEX

CVE-2026-63077: RCE não autenticado no TeamCity abre a porta pro pipeline inteiro

Um RCE não autenticado no TeamCity On-Premises, CVSS 9,8 e já com exploração ativa confirmada pela CISA, mostra por que servidor de CI/CD merece o mesmo escopo de pentest que um sistema de produção.

Por Equipe VorvexPublicado em 15 de agosto de 20263 min de leitura

Servidor de CI/CD raramente é o primeiro item que vem à cabeça quando se pensa em superfície de ataque exposta, mas é onde ficam as chaves de tudo: credencial de deploy, token de repositório privado, chave que assina o artefato antes dele ir pra produção. Foi exatamente esse tipo de sistema que a JetBrains corrigiu em 27 de julho de 2026, com uma falha crítica no TeamCity On-Premises que permite execução remota de comando sem nenhuma autenticação.

A falha: CVE-2026-63077

A National Vulnerability Database confirma CVSS 3.1 de 9,8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), classificada como CWE-502, desserialização de dado não confiável. O vetor é o protocolo de polling de agente do TeamCity: um atacante remoto, sem credencial nenhuma e com apenas acesso HTTP(S) ao servidor, consegue contornar a checagem de autenticação e executar comando arbitrário de sistema operacional com o mesmo privilégio do processo do TeamCity. A falha afeta toda versão On-Premises anterior à 2025.11.7 e a linha 2026.1 até a 2026.1.2. A correção está nas versões 2025.11.7 e 2026.1.3. Quem usa TeamCity Cloud não precisa agir, a mitigação já estava aplicada do lado do fornecedor.

Por que RCE em servidor de build pesa mais que RCE comum

Servidor de CI/CD concentra o tipo de acesso que qualquer atacante quer: credencial de deploy pra produção, token de repositório privado, chave de assinatura de artefato, variável de ambiente com segredo de outros sistemas conectados. Comprometer o processo do TeamCity não é só executar um comando isolado, é herdar esse acesso inteiro. Na prática, controle sobre o servidor de build abre caminho pra alterar pipeline, injetar código num artefato antes dele ser publicado, ou usar as próprias credenciais do CI/CD pra pivotar pra outros sistemas. É o mesmo padrão de risco por trás dos maiores incidentes de supply chain de software dos últimos anos.

Diagram showing an unauthenticated attacker reaching a CI/CD build server through an agent polling protocol, bypassing authentication, and gaining access to deployment credentials and build artifacts
Um RCE não autenticado no servidor de build não fica isolado: ele herda credencial de deploy, chave de artefato e acesso a tudo que o pipeline de CI/CD toca.

Exploração confirmada em agosto

No aviso original, a JetBrains registrou que não havia evidência de exploração ativa até a publicação. Isso mudou rápido: em 5 de agosto de 2026 a CISA incluiu a CVE-2026-63077 no catálogo Known Exploited Vulnerabilities, confirmando exploração em servidor desatualizado, com prazo de mitigação até 8 de agosto pras agências federais dos EUA. Dois dias depois, em 7 de agosto, a JetBrains publicou orientação adicional reforçando a urgência do patch pra quem ainda não tinha atualizado.

O que fazer agora

  • Atualizar para TeamCity 2025.11.7 ou 2026.1.3, as versões corrigidas
  • Se a atualização completa não for viável de imediato, aplicar o plugin de patch de segurança da JetBrains, disponível a partir da versão 2017.1
  • Restringir o acesso de rede ao servidor TeamCity e ao endpoint de polling de agente só à origem confiável, nunca exposto livremente na internet
  • Rotacionar credencial, token e segredo armazenado no TeamCity caso haja qualquer indício de exposição do servidor antes do patch
  • Revisar log de build recente em busca de pipeline alterado ou artefato publicado fora do padrão esperado
  • Incluir o servidor de CI/CD no escopo do próximo pentest, com o mesmo peso dado a um servidor de produção

O que isso muda pra quem está avaliando contratar um pentest

CI/CD deixou de ser infraestrutura de bastidor que só o time de plataforma enxerga. É superfície de ataque com acesso direto a produção, e um RCE não autenticado nela vale, na prática, tanto quanto um RCE num sistema voltado pro público. Se o servidor de build da empresa nunca entrou no escopo de um teste de segurança, essa é a lacuna que mais vale fechar primeiro.

← Voltar ao blog

Quer essa mesma profundidade aplicada ao seu ambiente?

Conte o que você precisa validar e a equipe monta um escopo de pentest sob medida.

Falar no WhatsApp

Pronto para avaliar o risco da sua empresa?