A maioria das histórias de segurança desta newsletter trata de coisas que acontecem diretamente com você: uma mensagem de phishing, uma senha vazada, um site de compras falso. Esta é diferente. Os incidentes abaixo aconteceram com desenvolvedores — as pessoas que escrevem os aplicativos e serviços que você usa todos os dias. Mas o motivo pelo qual pertencem a esta newsletter é simples: se alguém envenena as ferramentas usadas para criar software, o veneno não fica com quem o criou. Ele é enviado junto com o produto.

Duas coisas aconteceram recentemente que ilustram isso. Nenhuma ganhou as manchetes como acontece com uma grande violação, porque nenhuma delas é uma violação especificamente sua. Ambas são ataques à cadeia que produz o software que você acaba instalando, abrindo ou usando para fazer login.

Extensões falsificadas disfarçadas de marcas confiáveis

O Open VSX é um marketplace público de extensões para editores de código — os pequenos complementos que os desenvolvedores instalam para obter autocompletar, linting e integrações para as ferramentas que usam diariamente (o Visual Studio Code e vários de seus equivalentes de código aberto usam esse marketplace). Entre 26 de julho e 1º de agosto de 2026, pesquisadores de segurança da Manifold Security encontraram 77 extensões falsificadas no registro. Cada uma copiava o nome e o namespace de uma extensão real e confiável, mas era publicada por uma conta que não pertencia ao proprietário original — uma forma clássica de personificação, às vezes chamada de apropriação de namespace.

Os nomes apropriados não eram aleatórios. Eles tomavam emprestadas as identidades da AMD, da LEGO Education, da Hyperledger, da Azure, da Artsy, de projetos de código aberto da Salesforce, de uma agência federal dos EUA e — numa espécie de ironia sombria — do próprio marketplace de extensões. Todos os 77 pacotes se comunicavam com um único domínio que havia sido registrado apenas 11 dias antes do surgimento do primeiro pacote falso, um padrão que sugere uma campanha coordenada e criada para um fim específico, em vez de cópias oportunistas.

A maioria das extensões falsas fazia algo modesto: informava discretamente o nome do host ao servidor do invasor, o que, por si só, pode ser apenas uma verificação para saber quem instalou a isca. Mas os pesquisadores descobriram que aproximadamente um quarto das 77 — 19 pacotes — ia além. Segundos após a ativação, coletavam o nome do host, o nome de usuário do sistema operacional, detalhes do editor e um ID da máquina. Depois, liam qualquer projeto que o desenvolvedor tivesse aberto: o repositório remoto do git (que revela a organização e o host do repositório), o domínio do e-mail do commit, o branch atual e o commit mais recente. Eles também extraíam valores de integração contínua — as credenciais e configurações que permitem que sistemas automatizados compilem e implantem código sem que uma pessoa digite uma senha a cada vez.

Nenhum desses dados é útil para esvaziar a conta bancária de alguém. Eles são úteis para outra coisa: descobrir para quais empresas um desenvolvedor trabalha, como é a infraestrutura interna delas e como obter um ponto de apoio nela.

Um bug com nota 9,8 de 10 na máquina que cria o software

O segundo incidente envolve o TeamCity, uma plataforma de integração e entrega contínuas (CI/CD) desenvolvida pela JetBrains. Se um editor de código é o lugar onde os desenvolvedores escrevem software, uma plataforma de CI/CD é o chão de fábrica automatizado onde esse código é compilado, testado e enviado para produção — muitas vezes sem que ninguém precise clicar em "implantar". O TeamCity é uma peça central dessa maquinaria em muitas empresas.

Uma vulnerabilidade identificada como CVE-2026-63077, com uma pontuação de gravidade de 9,8 em um máximo de 10, foi divulgada nas versões locais do TeamCity. Trata-se de uma falha de desserialização — uma classe de bug em que um programa confia tanto nos dados recebidos que os transforma diretamente em código em execução, sem verificar primeiro o que esses dados realmente são. Na prática, isso permitia que um invasor enviasse uma solicitação a um servidor TeamCity vulnerável, sem precisar fazer login, e executasse comandos arbitrários com os mesmos privilégios do próprio serviço do TeamCity. A JetBrains lançou correções (versões 2025.11.7 e 2026.1.3, além de um plugin de correção para instalações antigas 2017.1+), mas a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) alertou desde então que os invasores estão explorando ativamente sistemas sem correção.

Quem controla o servidor de compilação de uma empresa controla o que essa empresa envia. Isso não é uma hipótese — é a função literal da ferramenta.

O mesmo manual, duas portas diferentes

São incidentes não relacionados, investigados por pesquisadores diferentes, mas compartilham uma mesma estrutura. Nenhum deles ataca um produto acabado. Ambos atacam uma etapa anterior — o editor no qual um desenvolvedor escreve código ou o servidor que transforma esse código em uma versão enviada. Essa é a característica definidora de um ataque à cadeia de fornecimento de software: em vez de invadir um único alvo, você compromete algo a montante do qual muitos alvos dependem e deixa que o próprio processo confiável deles leve seu acesso adiante por você.

Vale a pena ser honesto sobre o que ainda não sabemos. Nenhum dos relatórios divulgados esta semana revelou um caso confirmado de um aplicativo ou usuário downstream comprometido como resultado direto — a campanha contra as extensões parece ser de reconhecimento e coleta de acesso, e a exploração do TeamCity é descrita como ativa, mas sem vítimas identificadas. Isso é normal; comprometimentos da cadeia de fornecimento costumam ser descobertos no ponto de entrada muito antes de (ou em vez de) se rastrear o eventual resultado.

Por que este é um problema seu, não apenas deles

Você provavelmente nunca instalará uma extensão de programação nem executará um servidor de CI/CD. Mas usa o resultado de centenas deles: seu aplicativo bancário, seu gerenciador de senhas, o portal escolar do seu filho, o navegador em que você está lendo isto. Tudo passou pelo editor de algum desenvolvedor e pelo pipeline de compilação de alguma empresa antes de chegar ao seu telefone. Se qualquer um desses elos for comprometido silenciosamente, a alteração maliciosa pode seguir junto com uma atualização de software comum e rotineira — o tipo de atualização que você instala porque lhe disseram que atualizar é a atitude segura.

É também por isso que as orientações em uma análise pós-incidente de uma violação às vezes parecem estranhas para leitores não técnicos: uma empresa diz que seus sistemas foram comprometidos por meio de um servidor de compilação, de uma credencial de desenvolvedor roubada ou de uma dependência maliciosa, e isso pode parecer abstrato em comparação com "alguém adivinhou minha senha". Não é abstrato. É o mesmo resultado — seus dados ou a integridade do seu aplicativo comprometidos — alcançado por uma porta cuja existência você nunca soube.

O que realmente ajuda

Você não pode auditar o pipeline de CI/CD do seu banco, e não deveria ter de fazê-lo. Mas alguns hábitos reduzem genuinamente sua exposição a esta categoria de risco:

Mantenha as atualizações automáticas ativadas, mas não trate as atualizações como automaticamente confiáveis. É por meio dos patches que correções como a do TeamCity acima chegam ao software que você executa — manter tudo atualizado fecha brechas que os invasores estão sondando ativamente. Ao mesmo tempo, uma atualização só é tão boa quanto o pipeline que a produziu, que é exatamente o que está sendo alvo aqui; não existe uma defesa individual perfeita contra uma versão upstream verdadeiramente envenenada, e é por isso que este é fundamentalmente um problema de responsabilidade do fornecedor, não um problema seu.

Se você trabalha com desenvolvedores ou os gerencia, há duas coisas concretas e verificáveis: confirme que qualquer extensão de editor de código está instalada a partir da conta real e verificada do editor, não apenas de um nome correspondente (o Open VSX e marketplaces semelhantes exibem a identidade do editor — confira-a; não confie apenas no ícone e no título); e, se sua organização executa o TeamCity localmente, confirme hoje que ele está na versão 2025.11.7, 2026.1.3 ou que o plugin de correção foi aplicado, e não na próxima janela de manutenção — o alerta da CISA significa que isso está sendo explorado ativamente, não que seja algo teórico.

Para todos os demais, a mudança útil é apenas ter consciência: quando você lê sobre uma violação em uma empresa que remonta a "uma ferramenta de desenvolvedor comprometida" ou a "um sistema de compilação", isso não é uma nota de rodapé técnica e específica. É a mesma categoria de evento que as violações de senhas e os golpes de phishing abordados com mais frequência nesta newsletter — apenas começou uma camada mais acima, antes mesmo de o produto chegar até você.