Ataque à cadeia de suprimentos do Rust injeta malware de build no arrayref

Atacantes publicaram em 20 de agosto de 2026 versões maliciosas de três crates de Rust amplamente usadas - arrayref 0.3.10, internment 0.8.7 e append-only-vec 0.1.9 - no crates.io, e quem compilou um projeto que resolvesse uma delas executou malware na própria máquina. A carga rodava durante o próprio cargo build, então um desenvolvedor ou um runner de CI nunca precisava chamar o código envenenado para ser comprometido.

A janela de exposição foi curta; o raio de impacto, não. Segundo o The Hacker News, o arrayref acumula 245.385.500 downloads no total, 53.905.601 deles nos 90 dias anteriores ao ataque, e 403 crates o listam como dependência direta. A empresa de segurança Wiz afirma que o arrayref aparece em mais de 35% de todos os ambientes que observa, e em três quartos dos ambientes onde Rust está presente.

Como o ataque funcionou

O Rust Security Response Team diz que recebeu uma denúncia às 7h15 UTC de 20 de agosto e verificou que a nova versão do arrayref "tinha um script de build que baixava uma carga maliciosa". As versões maliciosas não mexeram no código do próprio arrayref. Em vez disso, adicionaram uma nova dependência chamada proc-macro1 - um typosquat do ecossistema legítimo proc-macro - cujo script de build baixa e executa um binário remoto na compilação.

A análise da StepSecurity resume o mecanismo sem rodeios: "Bastava compilar qualquer projeto cujo lockfile resolvesse arrayref 0.3.10 para detonar a carga. O código da crate nunca precisa ser chamado." A mesma análise constatou que o atacante retirou (yank) todas as versões limpas 0.3.x do arrayref em uma rajada roteirizada, "transformando o próprio aviso de 'yanked version' do Cargo em mecanismo de entrega" - desenvolvedores que reagiam ao aviso atualizavam direto para a versão maliciosa.

Segundo a Wiz, o backdoor baixado reconstruía suas URLs de comando e controle a partir de fragmentos em Base64, desativava a validação de certificados TLS e trazia cargas específicas por plataforma com persistência para Windows, macOS e Linux, além de enumeração de credenciais em perfis de navegador. Junto ao proc-macro1, o Rust Security Response Team identificou outras cinco crates controladas pelo atacante: proc-macro-en, aovine, arone, aronenao e tinymember.

O crates.io removeu as versões maliciosas rapidamente: o arrayref 0.3.10 ficou no ar por 86 minutos, o internment 0.8.7 por 90 e o append-only-vec 0.1.9 por 107, segundo os registros de horário divulgados pelo The Hacker News. A StepSecurity observa que "a operação inteira, da criação do personagem à remoção do registro, cabe em uma única manhã de trabalho".

Quem está por trás

O que foi comprometido foi a conta do mantenedor, não o mantenedor. "Não acreditamos que o autor do arrayref esteja agindo de má-fé; o mais provável é que o computador ou as credenciais dele estejam comprometidos", declarou o Rust Security Response Team em sua divulgação.

A Wiz relata que a infraestrutura da campanha se sobrepõe substancialmente a operações norte-coreanas recentes contra cadeias de suprimentos: compartilha a mesma faixa de endereços da Hostwinds, 23.254.164.0/23, usada na campanha Mastra do npm, atribuída ao Sapphire Sleet, grupo ligado à RPDC, e seu tráfego de comando e controle ia para um IP que aparece na análise do Google Cloud Threat Intelligence sobre os ataques ao axios no npm, também atribuídos à Coreia do Norte. O manual já conhecido do npm acaba de chegar ao crates.io.

O que isso significa para desenvolvedores

Se alguma de suas máquinas ou runners de CI compilou um projeto Rust na manhã de 20 de agosto (UTC), verifique se o lockfile resolveu arrayref 0.3.10, internment 0.8.7 ou append-only-vec 0.1.9 e inspecione o cache local do registro - o aviso do Rust Security Response Team pede que se verifiquem as dependências em cache em busca dos nomes de crates maliciosas listados acima. Trate uma máquina que compilou uma delas como comprometida, não apenas exposta: segundo a Wiz, a carga instala persistência e enumera credenciais de navegador, então rotacione os segredos que essa máquina podia alcançar.

A lição estrutural é que scripts de build são uma superfície de execução remota de código, e lockfiles são o controle. Um Cargo.lock commitado fixa versões exatas; durante a janela de 86 minutos, o caminho vulnerável era um cargo install do zero ou um job de CI sem fixação de versões. O ataque também transformou um recurso de segurança em isca - depois do truque do yank, "versão retirada significa atualizar já" deixou de ser um reflexo seguro. Confira para o que você está atualizando e trate uma dependência novinha aparecendo no diff de uma crate estável há muito tempo como sinal de parar tudo.