Mais de 1.500 pacotes do Arch User Repository foram comprometidos entre 9 e 12 de junho de 2026 na campanha Atomic Arch, um ataque de cadeia de suprimentos que usou a adoção legítima de pacotes órfãos para distribuir um infostealer em Rust com rootkit eBPF capaz de ocultar sua presença de ferramentas do sistema. Qualquer host que instalou pacotes AUR nesse período deve ser tratado como comprometido, com rotação imediata de todas as credenciais.

O que é o Atomic Arch

Entre 9 e 12 de junho de 2026, uma campanha de supply chain attack batizada de Atomic Arch comprometeu mais de 1.500 pacotes no Arch User Repository (AUR), o repositório comunitário do Arch Linux. A campanha foi classificada com CVSS 8.7 (Sonatype-2026-003775) e distribuiu um infostealer escrito em Rust com capacidade de implantar um rootkit eBPF que se esconde do sistema operacional. Os pacotes oficiais do Arch Linux não foram afetados, mas qualquer pessoa que instalou pacotes do AUR nesse período precisa agir agora.

O ataque não se baseou em técnicas sofisticadas de exploração zero-day. O invasor usou um mecanismo legítimo do AUR — a adoção de pacotes órfãos — para assumir o controle de projetos abandonados e injetar código malicioso. Segundo a SecurityWeek, o Arch Linux suspendeu novos registros na plataforma em resposta à escala do ataque.

Como o ataque funcionou

O AUR permite que qualquer usuário registado adote pacotes abandonados por seus mantenedores originais. Esse processo existe para manter pacotes úteis em funcionamento. O atacante explorou exatamente esse fluxo de trabalho:

  1. Identificou centenas de pacotes órfãos com base de usuários estabelecida;
  2. Solicitou a adoção através do processo normal do AUR;
  3. Modificou os arquivos PKGBUILD para executar um pacote npm malicioso durante a instalação;
  4. Falsificou metadados de commit git para impersonar um mantenedor conhecido (“arojas”).

A primeira onda comprometeu 408 pacotes ao injetar npm install atomic-lockfile nos scripts de build. Em 12 de junho, uma segunda onda substituiu o método por bun install js-digest e adicionou pacotes novos, elevando o total para mais de 1.500. Pesquisadores da Cloud Security Alliance observaram que o atacante está iterando métodos de entrega, o que sugere uma campanha em andamento, não um ataque único.

Segundo engenheiros da Sonatype que identificaram a campanha em 11 de junho, “os atacantes não estão construindo confiança do zero — estão adquirindo projetos que já a conquistaram”. É essa transferência implícita de confiança que torna o ataque tão difícil de detectar.

O que o malware rouba

O pacote atomic-lockfile v1.4.2 executa um binário ELF em Rust chamado deps que extrai uma gama ampla de credenciais e dados sensíveis:

  • Cookies, tokens e local storage de navegadores Chrome, Edge e Brave;
  • Sessões de aplicativos Electron: Slack, Discord, Teams e Telegram;
  • Chaves SSH privadas e histórico de shell;
  • Tokens do GitHub, npm e HashiCorp Vault;
  • Chaves de API da OpenAI e ChatGPT;
  • Credenciais Docker, Podman, perfis VPN e chaves de provedores cloud (AWS, GCP, Azure);
  • Dados de carteiras de criptomoedas.

    • A exfiltração ocorre via HTTP multipart POST para o serviço público temp.sh. O comando e controle utiliza um serviço onion na rede Tor. O conjunto de dados roubados cobre exatamente os ativos que sustentam o acesso a pipelines CI/CD e estações de trabalho de desenvolvedores — o que torna o ataque particularmente perigoso para equipes de engenharia.

    O rootkit eBPF esconde tudo

    Quando o binário executa com privilégios de root, ele carrega um programa eBPF compilado que engana ferramentas do sistema. O rootkit hooka a chamada de sistema getdents64() e mantém três mapas BPF em /sys/fs/bpf/: hidden_pids, hidden_names e hidden_inodes.

    Esses mapas filtram PIDs, nomes de arquivo e inodes de qualquer ferramenta userspace que chame getdents64(). O resultado: comandos como ls, ps e find retornam resultados limpos enquanto o malware opera. Um scan de malware convencional em um host comprometido com root não detecta nada.

    De acordo com a Latest Hacking News, o binário também verifica depuradores anexados via PTRACE antes de executar, o que complica a análise dinâmica. A persistência é garantida por um serviço systemd configurado com Restart=always, instalado em /etc/systemd/system/ (root) ou ~/.config/systemd/user/ (usuário).

    Risco para o ecossistema brasileiro

    O Brasil tem uma comunidade Linux significativa. Arch Linux e distribuições derivadas como Manjaro e EndeavourOS são populares entre desenvolvedores e administradores de sistemas. Organizações que utilizam essas distribuições em ambientes de CI/CD ou estações de trabalho ficam expostas ao roubo massivo de credenciais.

    A campanha Cordyceps demonstrou que pipelines CI/CD mal configurados representam uma superfície de ataque vasta. O Atomic Arch combina esse vetor com um rootkit que torna a detecção praticamente impossível sem ferramentas especializadas de análise de memória ou inspeção direta dos mapas eBPF.

    Há uma semana, já tínhamos registrado o primeiro alerta sobre os pacotes comprometidos no AUR, quando o total passava dos 400. A escala quadruplicou desde então, e a arquitetura do malware provou ser mais sofisticada do que o inicialmente reportado.

    O que fazer agora

    A recomendação de pesquisadores da Sonatype e da StepSecurity é direta: qualquer host com registros de instalação de pacotes AUR atualizados entre 9 e 12 de junho de 2026 deve ser tratado como comprometido. As etapas obrigatórias são:

    1. Auditar o histórico de instalação de pacotes AUR no período afetado;
    2. Rotacionar todas as credenciais armazenadas no host (tokens, chaves SSH, credenciais cloud);
    3. Em hosts com execução como root, reinstalar o sistema operacional a partir de mídia limpa;
    4. Um scan de malware não é suficiente — hosts com root comprometido exigem rebuild completo;
    5. Verificar os mapas eBPF em /sys/fs/bpf/ e inspecionar serviços systemd desconhecidos.

    A campanha Atomic Arch não é mais um ataque de typosquatting ou roubo de credenciais de mantenedor. É a exploração de uma falha estrutural: o AUR não exige assinatura criptográfica de PKGBUILDs, não tem verificação automatizada de builds e não impõe continuidade de identidade quando um pacote muda de mantenedor. Enquanto essas lacunas existirem, qualquer pacote com anos de história pode se tornar arma de ataque sem que nenhum mecanismo de detecção dispare.

    O 16º ataque de supply chain de 2026 não é anomalia. É tendência.

    Leia também

    Mais de 400 pacotes do Arch Linux são infectados por rootkit — o primeiro alerta sobre esta campanha, quando a escala ainda era menor.

    Worm IronWorm infecta pacotes npm em ataque supply chain — outro ataque de cadeia de suprimentos que explorou o ecossistema de pacotes.

    Cordyceps: CI/CD falho expõe milhões de repositórios — como pipelines mal configurados amplificam o impacto de ataques de supply chain.

    Referências