A CISA confirmou que a CVE-2026-63077, vulnerabilidade crítica no JetBrains TeamCity, já está sendo usada em campanhas de ransomware. A falha permite que um atacante sem credenciais execute comandos no sistema operacional de servidores TeamCity On-Premises acessíveis por HTTP ou HTTPS.
O risco não termina no servidor comprometido. Como o TeamCity participa da compilação, integração e entrega de software, o invasor pode alcançar credenciais, repositórios, artefatos, registros de pacotes, ambientes de nuvem e sistemas de produção conectados à esteira.
A atualização da CISA reforça um padrão observado em notícias recentes: operadores de ransomware estão priorizando plataformas de gestão, segurança e desenvolvimento que concentram acesso privilegiado e conectividade com diferentes partes da organização.
O que mudou no alerta da CISA
A CVE-2026-63077 foi incluída no catálogo de Vulnerabilidades Conhecidas e Exploradas da CISA em 5 de agosto de 2026. Em 23 de setembro, o campo que indica utilização em ransomware foi alterado de “Unknown” para “Known”, confirmando que a vulnerabilidade passou a integrar campanhas desse tipo.
A alteração não representa uma nova vulnerabilidade nem uma nova inclusão no catálogo. Ela muda o contexto de risco: uma falha que já tinha exploração ativa confirmada agora também possui associação oficial com operações de ransomware.
A CISA não identificou publicamente quais grupos estão explorando a vulnerabilidade. Portanto, não é possível atribuir a campanha atual a uma operação específica com base apenas no catálogo.
Como a vulnerabilidade funciona
A CVE-2026-63077 é uma falha de desserialização de dados não confiáveis no protocolo usado pelos agentes do TeamCity para se comunicar com o servidor. Um invasor com acesso HTTP ou HTTPS pode explorar esse protocolo sem autenticação e executar comandos com os privilégios do processo do TeamCity.
A vulnerabilidade recebeu pontuação CVSS 9.8 e afeta versões do TeamCity On-Premises anteriores às correções 2025.11.7 e 2026.1.3. O TeamCity Cloud não exige ação dos clientes porque as medidas necessárias foram aplicadas pela própria JetBrains.
A correção principal é atualizar o servidor para uma das versões protegidas. Para ambientes a partir do TeamCity 2017.1 que não possam ser atualizados imediatamente, a JetBrains disponibilizou um plugin de segurança específico para a vulnerabilidade. O plugin corrige a CVE-2026-63077, mas não substitui uma atualização completa da plataforma.
Por que o TeamCity é estratégico
Um servidor de CI/CD normalmente mantém conexões com repositórios de código, agentes de compilação, registros de pacotes, plataformas de nuvem e ambientes de implantação. Também pode processar tokens, chaves de API, credenciais de serviço e certificados usados para assinar ou distribuir software.
Isso transforma o comprometimento do TeamCity em um problema maior do que a indisponibilidade de um servidor. O atacante pode roubar segredos, alterar configurações, movimentar-se para outros ambientes ou interferir nos artefatos produzidos pela organização.
O risco de cadeia de suprimentos aparece quando uma alteração maliciosa entra no processo de compilação e chega a pacotes, imagens, aplicações ou atualizações posteriormente distribuídas. Nesse cenário, a própria esteira confiável passa a transportar a atividade do invasor.
O incidente da própria JetBrains
A gravidade desse cenário ficou evidente no incidente envolvendo o JetBrains Cadence, serviço que utilizava TeamCity para orquestrar cargas de trabalho. A JetBrains confirmou que o ambiente permaneceu vulnerável à CVE-2026-63077 e foi explorado entre 8 e 24 de agosto de 2026.
Os invasores acessaram dados pessoais e comprometeram um backup completo do servidor Cadence de 2024. A empresa também passou a considerar potencialmente expostos código-fonte, credenciais, configurações, artefatos e dados presentes no ambiente conectado.
A própria JetBrains reconheceu que o servidor deveria ter recebido a correção como parte da resposta inicial, mas não foi atualizado. O caso mostra que publicar ou receber um patch não significa que a exposição foi efetivamente eliminada.
Como esta notícia se conecta às anteriores
O caso TeamCity amplia uma sequência de incidentes em que sistemas com acesso privilegiado são usados como porta de entrada para extorsão, movimento lateral e comprometimento de ambientes conectados.
- No caso das falhas do Cisco FMC exploradas pelo ransomware Qilin, o comprometimento de uma plataforma central de segurança permitiu roubo de credenciais, persistência e preparação do ambiente para ransomware.
- Na exploração da CVE-2026-60004 no Gitea, uma plataforma de desenvolvimento exposta à internet também permitia execução de comandos com os privilégios da conta de serviço.
- A campanha do worm Shai Hulud contra ambientes de desenvolvimento demonstrou como credenciais, tokens e dependências comprometidas podem ampliar o impacto para além do sistema inicialmente afetado.
- O StormEncryptor mostrou a preferência de operadores de ransomware por plataformas expostas que oferecem acesso administrativo e caminhos rápidos para outros ativos corporativos.
Em todos esses casos, a tecnologia explorada muda, mas o padrão operacional permanece: comprometer um sistema concentrador reduz o esforço necessário para alcançar credenciais, dados, produção e continuidade.
Quem pode ser afetado
Estão no escopo organizações que executam qualquer versão vulnerável do TeamCity On-Premises, especialmente quando o servidor está acessível pela internet ou por redes amplas e pouco segmentadas.
No Brasil, a prioridade deve ser maior para empresas de software, fintechs, bancos, varejistas, indústrias, provedores de tecnologia e organizações que usam o TeamCity para automatizar implantações em ambientes críticos. O risco também alcança empresas que recebem software, pacotes ou serviços produzidos por terceiros em esteiras comprometidas.
A Shadowserver mantém uma verificação baseada em versão para identificar instâncias expostas à CVE-2026-63077. A contagem de mais de 160 servidores vulneráveis citada na notícia deve ser entendida como uma fotografia dinâmica da internet, não como o tamanho total da exposição, pois não inclui ambientes internos, acessos restritos ou ativos não identificados pelo escaneamento.
Por que aplicar o patch não basta
A atualização impede novas tentativas de exploração da vulnerabilidade, mas não remove contas, web shells, plugins, tarefas, tokens ou alterações implantadas antes da correção.
Como a exploração ativa começou antes da confirmação de uso em ransomware, servidores que permaneceram acessíveis e vulneráveis devem passar por investigação retrospectiva. A ausência de criptografia ou pedido de resgate não comprova que o ambiente está íntegro.
O invasor pode ter extraído credenciais, criado persistência ou alterado componentes da esteira e adiado a etapa de impacto. Por isso, correção e resposta a incidente precisam acontecer de forma coordenada.
O que fazer nas próximas 24 horas
- Localize todas as instâncias. Identifique servidores TeamCity de produção, homologação, laboratório, contingência, filiais e ambientes administrados por terceiros.
- Confirme a versão efetivamente executada. Considere vulneráveis as instalações anteriores a 2025.11.7 e 2026.1.3.
- Aplique a atualização. Atualize para uma versão corrigida. Quando isso não for possível, use o plugin oficial disponível para TeamCity 2017.1 ou posterior.
- Retire a exposição desnecessária. Restrinja o acesso a redes autorizadas, VPN ou camadas adicionais de controle.
- Preserve evidências. Antes de reiniciar, reconstruir ou excluir arquivos, preserve logs, processos, conexões, arquivos recentes e dados do sistema.
O que investigar nas próximas 72 horas
- Revise os registros do TeamCity. Procure eventos relacionados a ConversionException em servidores que estavam vulneráveis e ForbiddenClassException após a correção. Esses eventos exigem análise de contexto e não devem ser tratados isoladamente como confirmação de comprometimento.
- Procure agentes desconhecidos. Revise registros de novos agentes, nomes incomuns, sessões inesperadas e conexões vindas de endereços não autorizados.
- Analise a árvore de processos. Investigue shells, PowerShell, cmd, curl, wget, Python, scripts ou ferramentas de rede iniciadas pelo processo Java associado ao TeamCity.
- Revise alterações na esteira. Compare configurações de build, scripts, plugins, integrações, repositórios, dependências e artefatos com versões conhecidas como confiáveis.
- Rotacione segredos. Revogue tokens de repositórios, chaves de nuvem, credenciais de implantação, contas de serviço, certificados e chaves de assinatura acessíveis ao servidor.
- Amplie a investigação. Correlacione os eventos do TeamCity com EDR, firewall, proxy, DNS, identidade, nuvem, repositórios e registros de pacotes.
O que revisar na próxima semana
- Valide a integridade dos artefatos produzidos durante o período de possível exposição.
- Revise implantações realizadas em produção e compare hashes, commits, dependências e assinaturas.
- Separe o servidor TeamCity dos agentes de compilação e aplique privilégios mínimos às contas de serviço.
- Defina responsáveis por patch, investigação, rotação de segredos e validação dos ambientes conectados.
- Teste um playbook conjunto entre Vulnerability Management, AppSec, DevSecOps, SOC, infraestrutura e resposta a incidentes.
- Registre o risco residual, as exceções e as evidências de correção para permitir acompanhamento executivo.
O que líderes precisam acompanhar
A resposta não deve ser medida apenas pelo percentual de servidores atualizados. A liderança precisa saber quantas instâncias existiam, quais estavam expostas, por quanto tempo permaneceram vulneráveis, quais credenciais podiam acessar e quais artefatos foram produzidos nesse período.
Também é necessário confirmar se a organização consegue reconstruir a confiança na esteira. Isso envolve demonstrar que código, dependências, imagens, pacotes e implantações não foram alterados por um invasor.
A pergunta central não é apenas se o TeamCity foi corrigido. A organização consegue provar que os artefatos produzidos antes da correção continuam confiáveis?
Fontes
JetBrains: comunicado original sobre a CVE-2026-63077
JetBrains: orientações após a confirmação de exploração ativa
JetBrains: incidente de segurança no Cadence
CISA: catálogo de vulnerabilidades conhecidas e exploradas
