Malware no crate arrayref do Rust colocou a comunidade de desenvolvimento em alerta após uma campanha de ataque à cadeia de suprimentos atingir versões comprometidas de bibliotecas hospedadas no crates.io. O caso envolve um dos componentes mais utilizados do ecossistema Rust: o arrayref, que acumula cerca de 245 milhões de downloads e aparece como dependência em projetos de criptografia, interfaces gráficas e infraestrutura de blockchain.
O ataque combinou o comprometimento da conta de um mantenedor, typosquatting e execução automática de código durante a compilação. O pacote falso proc-macro1, criado para se passar pelo legítimo proc-macro2, carregava um build.rs capaz de baixar e executar um segundo estágio malicioso. Assim, o simples ato de compilar um projeto afetado poderia ser suficiente para comprometer a máquina do desenvolvedor ou um ambiente de CI.
O incidente é especialmente relevante porque o código-fonte das bibliotecas legítimas praticamente não precisava ser alterado. Bastava inserir uma dependência maliciosa no manifesto do pacote. O resultado demonstra como dependências aparentemente inocentes podem transformar o processo de build em um vetor de execução remota.
Como ocorreu o ataque de supply chain no ecossistema Rust
A operação começou nas primeiras horas de 20 de agosto de 2026, quando o atacante criou uma conta no GitHub chamada dtolney, uma imitação quase perfeita do nome de usuário dtolnay, associado ao desenvolvedor David Tolnay e ao projeto legítimo proc-macro2.
Pouco depois, a mesma identidade foi registrada no crates.io. Às 01h55 UTC, o invasor publicou proc-macro1 1.0.106, inicialmente como uma cópia aparentemente legítima de proc-macro2. A publicação serviu como uma espécie de período de preparação para que o pacote não parecesse recém-criado quando fosse armado.
Às 07h11 UTC, o atacante publicou a versão proc-macro1 1.0.107, acrescentando o build.rs malicioso e dependências como base64, rustls e ureq, utilizadas para montar endereços, estabelecer comunicação e baixar o payload.
Quatro minutos depois, às 07h15, surgiu o arrayref 0.3.10. A versão foi publicada utilizando a conta legítima do mantenedor, que, segundo a investigação da equipe de segurança do Rust, provavelmente teve o computador ou as credenciais comprometidos.
A alteração era extremamente pequena: o pacote recebeu uma dependência de proc-macro1 ^1.0.107. O restante do código do arrayref permanecia funcional.
O atacante ainda aplicou uma segunda técnica. Em poucos segundos, as versões 0.3.5 a 0.3.9 do arrayref foram marcadas como yanked. Isso fazia o Cargo exibir avisos indicando que a versão utilizada havia sido retirada e incentivava uma atualização.
Na prática, a estratégia podia conduzir o desenvolvedor para a única versão moderna não marcada como yanked: justamente a 0.3.10 comprometida.
A sequência continuou rapidamente. Às 07h34, foi publicado o internment 0.8.7, seguido pelo append-only-vec 0.1.9, às 07h37. Os três pacotes pertenciam ao mesmo mantenedor e receberam essencialmente a mesma dependência maliciosa.
A primeira denúncia chegou ao RustSec às 07h54 UTC. O crates.io removeu o proc-macro1 às 08h03 e retirou o arrayref 0.3.10 do índice às 08h41. O internment 0.8.7 permaneceu disponível por cerca de 90 minutos, enquanto o append-only-vec 0.1.9 chegou a aproximadamente 107 minutos.
Como funciona o malware no crate arrayref do Rust
O ponto mais perigoso do malware no crate arrayref do Rust está no mecanismo de compilação. O Cargo executa automaticamente determinados arquivos build.rs durante a construção de uma dependência.
Isso significa que não era necessário chamar uma função específica do arrayref. Se o projeto resolvesse a versão comprometida, o Cargo poderia compilar o proc-macro1 e executar seu script de construção.
O código malicioso reconstruía, a partir de fragmentos codificados em Base64, o endereço do servidor responsável pela entrega do payload. A infraestrutura observada incluía o endereço 23.254.165.112:9089, enquanto a porta 443 era utilizada para comunicação posterior. A validação de certificados TLS também havia sido deliberadamente enfraquecida no downloader.
Depois de obter o segundo estágio, o comportamento variava conforme o sistema operacional.
Linux e sistemas Unix
No Linux, o dropper gravava o artefato em /tmp/rust-setup, alterava suas permissões e executava o processo de forma desacoplada do build. Relatos posteriores indicaram mecanismos de persistência por meio de serviços systemd em nível de usuário e arquivos armazenados em diretórios de configuração do usuário.
A execução desacoplada é importante porque permitia que o processo malicioso continuasse ativo mesmo depois que o cargo build terminasse normalmente.
Windows
No Windows, o malware utilizava arquivos temporários como rust-setup.ps1 e um lançador VBScript, executado por meio do wscript.exe. O objetivo era iniciar o payload sem uma janela visível e evitar que o comportamento chamasse atenção durante a compilação.
Pesquisadores também identificaram mecanismos de persistência relacionados à chave Run do Registro, permitindo que o componente malicioso fosse iniciado novamente pelo sistema.
macOS
No macOS, a campanha utilizava um LaunchAgent em nível de usuário. Esse mecanismo permite registrar um agente para execução automática durante o login, oferecendo persistência sem exigir necessariamente privilégios administrativos.
A análise do payload identificou uma estrutura de configuração compatível com ~/Library/LaunchAgents e execução por meio do /bin/zsh.
O objetivo era roubar credenciais
O segundo estágio não tinha como objetivo simplesmente interromper a compilação. Ele funcionava como um componente de roubo de informações, com capacidade de estabelecer comunicação com a infraestrutura controlada pelo atacante.
Pesquisadores relataram acesso a bancos de dados SQLite utilizados por navegadores baseados em Chromium, incluindo Google Chrome, Brave e Microsoft Edge, em busca de informações armazenadas localmente. A infraestrutura também oferecia mecanismos de persistência e execução de comandos adicionais.
Esse comportamento aumenta significativamente o risco para desenvolvedores. Uma máquina utilizada para programar frequentemente possui tokens de GitHub, credenciais de nuvem, chaves SSH, credenciais de CI/CD, certificados, chaves de assinatura e arquivos .env.
Por isso, um computador de desenvolvimento comprometido pode se transformar em uma ponte para outros ambientes da organização.
Projetos afetados e possíveis origens da ameaça
Os três pacotes legítimos comprometidos foram:
- arrayref 0.3.10, última versão segura: 0.3.9;
- internment 0.8.7, última versão segura: 0.8.6;
- append-only-vec 0.1.9, última versão segura: 0.1.8.
O impacto potencial é muito maior do que os downloads desses três projetos sugerem. O arrayref aparece em centenas de árvores de dependências e é utilizado por componentes relacionados a BLAKE3, tiny-skia, winit, egui, além de ferramentas associadas a Ethereum e Solana.
O projeto BLAKE3, por exemplo, declara arrayref como dependência, enquanto aplicações do ecossistema gráfico Rust também podem recebê-lo de forma transitiva.
Isso não significa que esses projetos tenham sido diretamente invadidos. O ponto importante é que uma aplicação pode depender indiretamente de um crate comprometido, sem que o desenvolvedor tenha adicionado o pacote malicioso manualmente.
Pesquisadores também encontraram sinais de possível conexão com campanhas atribuídas a grupos de ameaça norte-coreanos. A análise da Wiz identificou sobreposição de infraestrutura e indicadores observados em outras operações de comprometimento de cadeias de software. A atribuição, porém, deve ser tratada como hipótese de inteligência de ameaças, e não como confirmação definitiva da identidade do operador.
O que os desenvolvedores devem fazer agora
A primeira providência é verificar todos os arquivos Cargo.lock relacionados aos projetos desenvolvidos ou compilados durante a janela do ataque.
Procure especificamente por:
arrayref 0.3.10internment 0.8.7append-only-vec 0.1.9proc-macro1proc-macro-enaovinearonearonenaotinymember
Também é importante examinar o cache local do Cargo e registros de CI. A presença de uma versão comprometida não significa necessariamente que ela tenha sido executada, mas qualquer máquina que tenha compilado uma dessas versões deve ser tratada como potencialmente comprometida.
No Linux e macOS, procure por /tmp/rust-setup e mecanismos suspeitos em LaunchAgents ou serviços systemd. No Windows, verifique rust-setup.ps1, rust-setup-launch.vbs, execuções suspeitas de PowerShell ou wscript.exe e alterações recentes nas chaves Run do usuário.
Também devem ser investigadas conexões de rede para 23.254.165.112, especialmente nas portas 9089 e 443, além de outros indicadores divulgados por pesquisadores. Em ambientes corporativos, os logs de firewall, proxy, EDR e CI podem ser decisivos para determinar se o payload chegou a ser baixado.
Se uma máquina afetada tiver acesso a informações sensíveis, a resposta deve incluir rotação de tokens de CI/CD, credenciais de nuvem, chaves SSH, chaves GPG, tokens de repositórios e segredos presentes no ambiente.
Depois da contenção, o ideal é reconstruir o ambiente a partir de uma máquina conhecida como limpa e utilizar versões seguras dos pacotes. O pinning deve manter arrayref em 0.3.9 ou anterior, internment em 0.8.6 ou anterior e append-only-vec em 0.1.8 ou anterior, conforme os indicadores publicados.
O que o ataque ensina sobre segurança no desenvolvimento
O caso do malware no crate arrayref do Rust mostra que a segurança de uma aplicação não termina no código escrito pela própria equipe.
O problema pode estar em uma dependência transitiva, em um script de compilação ou em uma conta de mantenedor que tenha sido comprometida. Nesse cenário, testes automatizados podem até passar normalmente, porque o código funcional da biblioteca permanece intacto enquanto o comportamento malicioso ocorre fora da lógica principal.
Outro ponto importante é que Cargo.lock deve ser tratado como um controle de segurança, e não apenas como um mecanismo de reprodutibilidade. Builds determinísticos, revisão das alterações de dependências, scanners de supply chain, controle de egress e ambientes de CI com privilégios mínimos podem reduzir drasticamente o impacto de incidentes semelhantes.
A comunidade Rust reagiu rapidamente, removendo os pacotes maliciosos e bloqueando as contas envolvidas. Ainda assim, a velocidade da resposta não elimina o risco para quem compilou uma versão comprometida durante a janela de exposição.
Desenvolvedores Rust, equipes de segurança e administradores devem verificar seus projetos imediatamente, especialmente aqueles compilados em 20 de agosto de 2026. O episódio reforça uma regra fundamental para qualquer cadeia moderna de software: uma dependência confiável hoje pode se tornar um vetor de ataque amanhã.
