Seguindo o recente relato da campanha “Atomic Arch” que tem movimentado a comunidade Linux, surgiu mais uma leva de pacotes infectados com supply-chains. A campanha, primeiramente relatada dia 12 de Junho [1], trata-se de um ataque ao repositório de contribuição comunitária – AUR (Archlinux User Repository) – onde, nos vários pacotes extras disponibilizados, 400 tiveram seus scripts de instalação alterados para incluir pacotes maliciosos, configurando uma cadeia de ataque.

Com esta situação, até o momento da postagem, 17 de Junho, não resolvida, a lista de pacotes teve um salto para 2.000 pacotes afetados e juntamente houveram alertas em um dos fórums do Archlinux que ataques continuavam com obfuscações.

Cadeia de Ataque

O ataque tem como alvo principalmente pacotes orfanados (dependências não mais necessárias) e a falta de validação em commits no AUR, alterando o ‘postInstall‘ do script para incluir etapas com gerenciadores de pacotes npm ou bun, e adicionar infostealers. Mesmo que inicialmente simples (era possível verificar a segurança apenas com um ‘grep’), houve relatos, posteriormente, de obfuscações nos ataques [2][3].

Apesar de alguns ataques serem mensagens redirecionadas pelo ‘.bashrc’, a grande maioria adiciona malwares para exfiltração de dados sensíveis, como chaves ssh, senhas, cookies, etc, e persiste por serviços do systemd. No caso específico do atomic-lockfile, o pacote npm atua como uma segunda etapa do ataque, sendo instalado pelos scripts de construção dos pacotes AUR comprometidos. Diferentemente de uma dependência legítima, ele utiliza hooks do ciclo de instalação do npm (no caso ‘preinstall‘) para executar um binário malicioso, invés de fornecer funcionalidades para o pacote que o requisitou.

Esse payload consiste em um infostealer escrito em Rust, acompanhado de componentes voltados à persistência e evasão, incluindo um rootkit (malware que se esconde e mantém acesso privilegiado) baseado em eBPF, comunicação com infraestrutura de C2 e mecanismos de persistência via systemd. Dessa forma, o comprometimento não depende da execução manual de um programa pelo usuário: o simples processo de instalação do pacote AUR pode ser suficiente para iniciar a cadeia de infecção.

Como o ataque se conclui em um infostealer e introduz persistência, apenas remover o pacote afetado não remove o malware e, remover o malware não desfaz a provável exfiltração de dados.

Mitigações

Dentre as recomendações para mitigar o ataque da campanha decorrente, ressalta-se que o usuário:

• Verifique na lista se algum dos seus pacotes foi alvo e evite atualizá-lo;
• Procure os diretórios ‘/etc/systemd/system‘ e ‘~/.config/systemd/user‘ por ‘.services’ estranhos e recentes;
• Rotacione as chaves, credenciais, secrets, senhas, etc, presentes na máquina;

Destaca-se também um dos principais avisos, dentro da própria wiki oficial, na página sobre o AUR:

Verifique criteriosamente o PKGBUILD, arquivos .install e outros dentro do repositório por comandos perigosos ou maliciosos. […]

É possível verificar por pacotes afetados, usando esta lista, com o seguinte comando:

$ curl https://md.archlinux.org/s/SxbqukK6IA | grep -Fxf - <(pacman -Qmq)

Fontes

[1] ARCH LINUX. Active AUR malicious packages incident. [S. l.], 2026. Disponível em: https://archlinux.org. Acesso em: 17 jun. 2026.

[2] ARCH LINUX. AUR malicious packages incident discussion. [S. l.], 2026. Disponível em: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/TND7HA2KBQ46OHHUMMIAHKGXZE4WALM6/. Acesso em: 17 jun. 2026.

[3] ARCH LINUX. AUR malicious packages incident discussion. [S. l.], 2026. Disponível em: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/NHRO2RT3VRXHQ7O4WQCPTNGNIOQQQAWX/. Acesso em: 17 jun. 2026.

[4] GAMINGONLINUX. The security situation with the Arch Linux AUR got a lot worse. [S. l.], 2026. Disponível em: https://www.gamingonlinux.com/2026/06/the-security-situation-with-the-arch-linux-aur-got-a-lot-worse/. Acesso em: 17 jun. 2026.

[5] SAFЕDEP. atomic-lockfile: malicious npm package. SafeDep, 2026. Disponível em: https://safedep.io/ti/packages/npm/atomic-lockfile/. Acesso em: 17 jun. 2026.