O incidente Atomic Arch no AUR e como validei minha máquina local
Em junho de 2026, o Arch User Repository (AUR) sofreu uma campanha de supply chain em múltiplas ondas. O caso começou com centenas de pacotes comprometidos, cresceu para mais de 1.500 em poucas horas e, nas listas comunitárias consolidadas, passou de 1.600 pacotes afetados.
A campanha foi nomeada **Atomic Arch** pela Sonatype, que descreveu o ataque como uma tomada de pacotes órfãos do AUR para injetar lógica maliciosa de build. O ponto mais importante: isso não atingiu os repositórios oficiais do Arch, mas sim o AUR, onde usuários executam receitas comunitárias como `PKGBUILD` e arquivos `.install`.
O modelo de risco do AUR
O AUR é útil justamente porque permite empacotar software fora dos repositórios oficiais. Mas o mesmo modelo cria risco: ao instalar via `makepkg`, `yay`, `paru` ou outro helper, o usuário executa scripts mantidos por terceiros.
Um `PKGBUILD` malicioso pode baixar código externo. Um arquivo `.install` pode executar comandos em `post_install()` ou `post_upgrade()`. E se esse fluxo chama `npm install` ou `bun add`, entra outro vetor: scripts de lifecycle como `preinstall`, que podem rodar automaticamente durante a instalação de dependências.
Foi exatamente essa combinação que tornou o incidente sério.
Linha do tempo resumida
Em 11 de junho de 2026, mantenedores do Arch abriram uma thread no `aur-general` para centralizar reports, resetar/deletar commits maliciosos e banir contas envolvidas. A primeira contagem pública falava em mais de 400 pacotes.
No mesmo dia e no dia seguinte, a estimativa subiu rapidamente. A Phoronix reportou primeiro mais de 400 pacotes comprometidos, depois mais de 1.500. Uma lista comunitária consolidada no repositório `lenucksi/aur-malware-check` passou a trabalhar com **1.600+ pacotes**, registrando 1.619 via lista atualizada em 15 de junho.
O detalhe importante é que o “all clear” foi prematuro. Depois de os desenvolvedores acreditarem que a situação principal estava sob controle, novas rodadas apareceram.
A primeira onda usava principalmente `npm install atomic-lockfile`. A segunda usava caminhos com Bun e pacotes como `js-digest` e `lockfile-js`. Na noite de 13 para 14 de junho, uma terceira fase mais elaborada apareceu: o desenvolvedor `a821` reportou commits com código ofuscado, e Nicolas Boichat mostrou um exemplo em `htbrowser-bin` que escondia um comando equivalente a entrar em `/tmp` e executar `bun add ansi-colors nextfile-js`.
Como a cadeia funcionava
Segundo a Sonatype, os atacantes adotaram pacotes órfãos do AUR, preservando a confiança do nome e da base instalada. Em vez de publicar um pacote novo e suspeito, eles herdavam pacotes legítimos abandonados e alteravam o fluxo de instalação.
A cadeia típica era:
1. O usuário instala ou atualiza um pacote do AUR.
2. O `PKGBUILD` ou `.install` foi alterado para chamar `npm` ou `bun`.
3. A dependência maliciosa é baixada.
4. O lifecycle hook, como `preinstall`, executa o payload.
5. O payload ELF chamado `deps` roda na máquina.
A análise técnica do `deps` aponta para um binário Linux escrito em Rust, com foco em estações de desenvolvedores e ambientes de build. Ele procura credenciais de navegador, tokens de GitHub/npm, material de SSH, Vault, Docker/Podman, Slack, Discord, Teams, Telegram, históricos de shell e outros segredos locais.
O relatório técnico também descreve persistência via systemd e uma capacidade eBPF opcional quando executado com privilégios suficientes. Os mapas eBPF citados incluem `hidden_pids`, `hidden_names` e `hidden_inodes`, usados para esconder processos, nomes e sockets.
Atomic Arch e IronWorm
A Sonatype rastreou a campanha como `Sonatype-2026-003775` e também indicou uma segunda leva relacionada como `Sonatype-2026-003808`. A mesma análise notou semelhanças com a campanha npm **IronWorm**, especialmente no uso de hook `preinstall` para executar binário embutido.
Relatórios técnicos também observaram padrões parecidos: payload em Rust, rootkit eBPF, upload para `temp.sh` e comunicação com C2 Tor usando caminho como `/api/agent`. Isso não prova que os operadores sejam os mesmos. A relação permanece não confirmada, mas o paralelo ajuda a entender o nível de sofisticação: não era só vandalismo em `PKGBUILD`.
O que eu validei localmente
A minha máquina é Artix, baseada em Arch, usando OpenRC em vez de systemd. Isso importa porque parte da persistência descrita no relatório dependia de systemd.
Primeiro listei os pacotes instalados fora dos repositórios oficiais:
```bash
pacman -Qm
Depois conferi datas de build e instalação:
pacman -Qi <pacote>
O ponto principal: nenhum pacote AUR local havia sido instalado ou buildado em ou depois de 11 de junho de 2026, que era a janela crítica. Os pacotes AUR mais recentes tinham sido buildados em 2 e 4 de junho.
Também procurei atividade no log do pacman:
rg "2026-06-1[1-5]" /var/log/pacman.log
Não apareceu instalação, upgrade ou reinstalação nessa janela.
Em seguida, procurei indicadores conhecidos:
rg "atomic-lockfile|js-digest|nextfile-js|bun add|ansi-colors" ~/.cache/yay /var/lib/pacman/local
find ~/.npm -name atomic-lockfile -type d
find ~/.npm /tmp /var/tmp -name deps -type f
ls -la /sys/fs/bpf
Resultado da triagem
Não encontrei evidência local de comprometimento.
Os sinais favoráveis foram:
- nenhum pacote AUR instalado/atualizado na janela de risco;
- nenhum match para atomic-lockfile, js-digest, lockfile-js, nextfile-js ou deps;
- bun não estava instalado;
- /sys/fs/bpf estava vazio;
- nenhum hidden_pids, hidden_names ou hidden_inodes;
- nenhum serviço systemd suspeito;
- nenhum C2 .onion, hash do payload ou artefato conhecido apareceu nas buscas.
Isso não substitui perícia completa. Alguns diretórios exigiam permissões elevadas, e uma máquina com rootkit eBPF ativo pode esconder processos e sockets de ferramentas de live response. Em um caso realmente suspeito, o ideal seria análise offline por live media confiável.
Como outros usuários podem checar
Além da checagem manual, a comunidade consolidou scripts no repositório:
https://github.com/lenucksi/aur-malware-check
O projeto cruza pacotes instalados contra listas de pacotes comprometidos, procura indicadores npm/bun e inclui checks para persistência systemd e artefatos eBPF. Como qualquer script de resposta a incidente, vale ler antes de executar, mas ele é útil para automatizar o básico, não usei esse script na minha triagem; fiz checagem manual. Depois, encontrei o lenucksi/aur-malware-check, que consolida checks comunitários e parece útil, mas deve ser lido antes de executar e ajustado para incluir a janela de 13-14 de junho.
Lições práticas
A primeira lição é: AUR não é repositório oficial. Um helper como yay torna a instalação conveniente, mas não transforma PKGBUILD comunitário em pacote auditado.
A segunda: revise PKGBUILD, .SRCINFO e arquivos .install, principalmente se aparecerem novos hooks como post_install() ou dependências inesperadas como npm, nodejs, bun, pnpm ou yarn.
A terceira: scripts de lifecycle importam. npm install e bun add podem executar código antes mesmo de você chegar ao software que achava estar instalando.
A quarta: a janela de tempo importa. Para este incidente, qualquer pacote AUR instalado ou atualizado em ou depois de 11 de junho de 2026 merecia revisão prioritária.
A quinta: supply chain não termina no gerenciador da distro. Neste caso, o AUR foi a porta de entrada, mas a execução passou por npm/bun, payload ELF, persistência local, coleta de credenciais e possível eBPF.
Fontes
- Sonatype, Atomic Arch: https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency
- Thread oficial aur-general: https://lists.archlinux.org/archives/list/[email protected]/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/
- Phoronix, 400+ pacotes: https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
- Phoronix, 1.500+ pacotes: https://www.phoronix.com/news/Arch-Linux-AUR-More-Than-1500
- Phoronix, nova onda ofuscada: https://www.phoronix.com/news/Arch-Linux-AUR-More-Malware
- Mensagem com bun add ansi-colors nextfile-js: https://lists.archlinux.org/archives/list/[email protected]/message/TND7HA2KBQ46OHHUMMIAHKGXZE4WALM6/
- Análise técnica deps: https://ioctl.fail/preliminary-analysis-of-aur-malware/
- IoCs e análise Atomic Arch: https://thecybersecguru.com/news/atomic-arch-aur-supply-chain-attack-ebpf-rootkit/
- Script comunitário: https://github.com/lenucksi/aur-malware-check