---
title: "Ataque na cadeia do Rust suga 245 milhões de downloads com malware em crates"
author: "Gustavo Ramos O. Klein"
date: "2026-08-21 09:00:00-03"
category: "Segurança & Privacidade"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/08/21/ataque-na-cadeia-do-rust-suga-245-milhoes-de-downloads-com-malware-em-crates/md"
---

## Resumo
- Três crates legítimas do Rust foram comprometidas em 20 de agosto de 2026 após uma conta de mantenedor ser invadida.
- As versões maliciosas identificadas foram arrayref 0.3.10, internment 0.8.7 e append-only-vec 0.1.9.
- A arrayref tinha mais de 245 milhões de downloads totais, número que não corresponde à quantidade de máquinas infectadas.
- O ataque usou a dependência typosquat proc-macro1 e um build.rs para baixar e executar código remoto durante o cargo build.
- O malware coletava informações do sistema e credenciais de navegadores, além de criar persistência e enviar dados a um servidor C2.
- A Wiz recomenda tratar como comprometida qualquer máquina que tenha compilado as versões afetadas.
- A resposta inclui verificar dependências e logs, rotacionar credenciais e higienizar ambientes de desenvolvimento e CI/CD.

---

Em **20 de agosto de 2026**, a equipe de segurança do Rust identificou versões maliciosas de três crates, nome dado às bibliotecas distribuídas pelo registro crates.io, depois que uma conta de mantenedor foi comprometida. Uma delas, a **arrayref**, acumulava mais de **245 milhões de downloads totais**, enquanto as outras duas também foram usadas como pontos de entrada para o mesmo ataque. O código escondido não esperava apenas ser importado por um programa: ele aproveitava a etapa de compilação para baixar e executar um payload remoto. A seguir, o caso ajuda a entender onde a ponte entre código aberto e ferramentas de desenvolvimento pode ser explorada, como verificar a exposição e qual resposta faz sentido para cada ambiente.

## O ataque entrou pela cadeia de dependências

O primeiro alerta envolveu a publicação da **arrayref 0.3.10**, versão que a equipe de segurança do Rust classificou como maliciosa. As outras bibliotecas atingidas foram a **internment 0.8.7** e a **append-only-vec 0.1.9**, versões que também receberam o código de ataque. A confirmação oficial levou à remoção dos pacotes do crates.io, ao bloqueio das contas dos mantenedores e à restauração de versões que haviam sido marcadas indevidamente como yanked, termo usado no registro para indicar que uma versão não deve mais ser escolhida por novas resoluções de dependência. O [aviso da equipe de segurança do Rust](https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/) mostra que a intervenção ocorreu depois que a publicação maliciosa já estava disponível para usuários.

Esse alcance precisa ser lido com cuidado. A marca de **245 milhões de downloads** é o total acumulado da arrayref, não a quantidade de computadores que executaram o malware, nem uma estimativa de vítimas confirmadas. Ainda assim, o número explica por que uma biblioteca aparentemente pequena pode funcionar como uma ponte para muitos projetos: ela pode ser incorporada, direta ou indiretamente, por aplicações diferentes, e a dependência chega ao desenvolvedor como parte do processo normal de construção. O relatório da StepSecurity delimitou a atividade entre **07:11 e 09:25 UTC** de 20 de agosto, enquanto o aviso da RustSec fala em aproximadamente 86 minutos de disponibilidade da versão maliciosa, duas medidas que descrevem momentos diferentes da janela de exposição.

## O ponto de entrada estava no processo de compilação

A escala do pacote só se transforma em risco quando o código contaminado encontra uma etapa capaz de executar ações na máquina. Nesse caso, uma das crates recebeu uma dependência chamada **proc-macro1**, nome muito próximo de **proc-macro2**, a dependência legítima que o relatório identifica como alvo da imitação. Essa técnica é conhecida como typosquatting: em vez de criar um nome completamente diferente, o invasor usa uma variação visualmente parecida, aumentando a chance de que ela passe despercebida durante uma revisão rápida de arquivos e versões. A semelhança funcionou como uma falsa identidade dentro da conversa entre as dependências.

Depois que a dependência foi resolvida, o mecanismo de execução ficou no **build.rs**, um script acionado durante a construção do projeto. O relatório descreve que ele baixava um payload de segundo estágio e o executava por meio do processo de compilação, produzindo RCE, sigla em inglês para execução remota de código. O download usava **TLS**, protocolo empregado para proteger a conexão, mas com a validação dos certificados desativada, o que retirava uma verificação destinada a confirmar a identidade do servidor remoto. Para quem roda cargo build, o comando de compilação do Rust, a ameaça podia parecer parte do trabalho normal de preparar o programa, e é justamente essa confiança automática que torna a cadeia de dependências tão sensível.

## O backdoor transformou a máquina em fonte de dados

O código executado durante o build não parava na compilação. Segundo a análise técnica, o payload de estágio 2 funcionava como um **backdoor**, ou seja, um componente malicioso capaz de manter comunicação e executar ações conforme as instruções recebidas. Ele coletava informações do sistema e procurava credenciais armazenadas em navegadores, além de criar persistência por mecanismos do próprio sistema operacional, como o **systemd** e o registro do sistema. Persistência significa tentar permanecer ativo depois do primeiro comando ou reinicialização, transformando uma execução pontual em uma presença que pode continuar acessível ao invasor.

Essa coleta dependia de uma comunicação de saída com um servidor de **C2**, abreviação de comando e controle, que funciona como o endereço para onde o malware envia informações e de onde pode receber instruções. A análise da Wiz registrou, como exemplo, o endereço **23.254.165.112:9089**, formado por um IP e uma porta de rede. O detalhe importa porque mostra que o ataque não se limitava a modificar arquivos locais: havia uma segunda etapa de diálogo entre a máquina de desenvolvimento e uma infraestrutura remota. A ponte criada pelo build script, portanto, conectava o registro de pacotes a um canal de exfiltração.

Na etapa de saída, o malware exfiltrava dados em formato **JSON**, uma estrutura organizada para representar informações, codificados em **Base64**, uma forma de transformar dados em texto para transporte. A análise também descreveu a capacidade de roubar credenciais por meio de consultas diretas aos bancos de dados **SQLite** usados por navegadores. Em termos práticos, o risco não ficava restrito ao código do projeto que estava sendo compilado: uma estação que armazenava sessões, senhas ou outros dados de autenticação no navegador podia oferecer material útil ao invasor. É por isso que a investigação precisa olhar para a máquina inteira, e não apenas para o repositório afetado.

Essa capacidade de roubo levou a Wiz a apontar semelhanças técnicas entre o ataque e campanhas atribuídas a atores ligados à **Coreia do Norte**, também identificada pela sigla DPRK. A formulação indica uma sobreposição de técnicas, não uma confirmação pública de autoria, distinção que evita transformar uma pista de inteligência em uma conclusão definitiva. Para o desenvolvedor, porém, a atribuição não muda a primeira decisão operacional: a máquina que executou o código deve ser tratada segundo o que ela permitiu fazer, e não segundo a identidade ainda discutida de quem estava do outro lado da conexão.

## A janela foi curta, mas a resposta precisa ser ampla

Mesmo com a retirada rápida, a equipe precisou corrigir mais de uma camada do registro. As **crates maliciosas foram removidas do crates.io**, as contas dos mantenedores foram bloqueadas e versões que haviam sido marcadas indevidamente como yanked foram restauradas. A sequência mostra como um ataque desse tipo combina confiança social e automação técnica: a conta comprometida publica, a ferramenta resolve a dependência e o script executa a etapa seguinte sem exigir que o usuário abra manualmente um arquivo suspeito. Remover o pacote impede novas resoluções, mas não desfaz o que já aconteceu em máquinas que compilaram a versão contaminada.

O aviso da RustSec classificou o problema específico da **arrayref 0.3.10** como malicious e informou que o impacto ficou limitado aos usuários que resolveram a dependência durante o curto período em que ela esteve disponível no registro. Para esse pacote, as versões **0.3.9 ou anteriores** permanecem seguras segundo o aviso. Essa informação ajuda a corrigir projetos que ainda apontam para a versão contaminada, mas não deve ser confundida com uma limpeza completa: trocar a versão no arquivo de dependências resolve a seleção futura do pacote, enquanto uma máquina que já executou o build precisa ser investigada separadamente.

Como a própria análise da Wiz recomenda tratar qualquer máquina que tenha realizado um **cargo build** com as versões afetadas como totalmente comprometida, a resposta deve incluir os ambientes de desenvolvimento e os sistemas de integração e entrega contínuas, conhecidos como **CI/CD**. O primeiro passo é identificar quais projetos e agentes de automação compilaram as versões durante a janela de exposição; depois, é necessário rotacionar credenciais, invalidar acessos que possam ter sido armazenados nos navegadores e higienizar completamente os ambientes atingidos. A recomendação não é uma acusação de que toda máquina foi invadida, mas uma postura de contenção diante de um código que tinha capacidade comprovada de coletar dados e manter persistência.

## Como desbugar a verificação no projeto

Para quem mantém um projeto Rust, a verificação começa pela resolução das dependências usadas no período indicado, com atenção especial à **arrayref 0.3.10** e às versões afetadas das outras crates. O arquivo de dependências deve ser conferido para descobrir se a versão maliciosa foi escolhida diretamente ou se chegou por outra biblioteca, porque o ataque explorou justamente a relação entre pacotes. Também é necessário revisar os registros de build e os ambientes que executaram cargo build, incluindo agentes automatizados, para separar máquinas que apenas baixaram código daquelas que efetivamente passaram pela etapa capaz de executar o script.

Essa checagem é uma conversa entre camadas: o registro informa qual pacote foi publicado, o gerenciador de dependências mostra qual versão foi resolvida e os logs de compilação revelam onde o código foi executado. Se a versão comprometida foi compilada, a orientação da **Wiz** é considerar a máquina totalmente comprometida, enquanto a equipe de segurança recomenda a rotação total das credenciais e a higienização dos ambientes expostos. O objetivo é fechar as pontes que podem ter permanecido abertas, em vez de apenas corrigir o nome da dependência no projeto.

O caso do Rust deixa uma resposta prática para o próximo passo: não basta perguntar se uma biblioteca é conhecida ou se acumula muitos downloads. É preciso verificar qual código roda automaticamente durante a instalação e a compilação, quais credenciais ficam acessíveis nessa máquina e quais outros serviços confiam nela. Para a **arrayref**, o aviso indica que as versões até **0.3.9** continuam seguras; para qualquer ambiente que tenha executado uma versão afetada, a medida concreta é rotacionar acessos e refazer a higienização antes de devolvê-lo ao fluxo de desenvolvimento.