Em junho 2026, invasores comprometeram mais de 1,500 pacotes no Arch User Repository (AUR). Pesquisadores da Sonatype nomearam a campanha como Atomic Arch. É um dos maiores ataques já realizados contra o AUR.

O AUR é uma coleção mantida pela comunidade de scripts de construção de pacotes. Ele é separado dos repositórios oficiais do Arch Linux. Os repositórios oficiais não foram afetados.

O ataque não explorou uma falha no Arch Linux ou no pacman. Ele abusou do processo de adoção de pacotes do AUR para assumir pacotes órfãos que os usuários já confiavam.

Este artigo explica o que aconteceu, por que funcionou e o que você pode fazer para reduzir o risco no futuro.

Atomic Arch: Ataque de malware ao AUR (junho 2026)

Os invasores não exploraram uma vulnerabilidade no Arch Linux. Eles abusaram de um recurso legítimo do AUR chamado adoção de pacotes. A adoção de pacotes permite que pacotes órfãos recebam um novo mantenedor após o mantenedor original parar de mantê-los.

Os invasores adotaram pacotes órfãos e modificaram seus arquivos PKGBUILD. Um PKGBUILD é um script Bash que instrui o makepkg sobre como baixar, construir e empacotar software. Por ser um script, ele pode executar comandos arbitrários durante a construção.

Muitos dos arquivos PKGBUILD modificados baixavam um pacote npm malicioso chamado atomic-lockfile. Um pacote npm é um software distribuído através do registro do Node Package Manager (npm). O pacote npm instalava um executável ELF do Linux no sistema. Um executável ELF é o formato binário padrão usado pelo Linux.

O malware roubava cookies do navegador, tokens de sessão, credenciais de login, chaves SSH, credenciais do Docker, perfis de VPN e segredos da nuvem. Ele também podia implantar um rootkit eBPF opcional após obter privilégios de root. Um rootkit eBPF usa o framework Extended Berkeley Packet Filter (eBPF) do Linux para ocultar atividades maliciosas do sistema operacional.

A campanha começou com cerca de 400 pacotes comprometidos e cresceu para mais de 1,500 nos dias seguintes. Os mantenedores do Arch congelaram novos registros de contas no AUR enquanto investigavam o incidente e removiam os pacotes maliciosos.

Os repositórios oficiais do Arch (core, extra, multilib) nunca foram afetados. O ataque teve como alvo o modelo de confiança do AUR, não a infraestrutura de empacotamento ou assinatura de pacotes do Arch Linux.

Por que isso aconteceu

O ataque não teve sucesso porque o Arch Linux era inseguro. Teve sucesso porque o AUR é construído sobre confiança.

O AUR é uma coleção mantida pela comunidade de scripts de construção de pacotes. Qualquer um pode enviar novos pacotes, e pacotes órfãos podem ser adotados por novos mantenedores. Diferente dos repositórios oficiais, os pacotes do AUR não passam por uma revisão formal antes de se tornarem disponíveis.

Isso não torna o AUR inseguro. Significa que a responsabilidade de decidir se um pacote é confiável pertence ao usuário. O AUR foi projetado para facilitar o empacotamento comunitário, não para certificar que todo pacote é confiável.

Os invasores tiraram vantagem desse modelo. Em vez de criar novos pacotes maliciosos, eles adotaram pacotes órfãos que já tinham usuários existentes e um histórico estabelecido. Depois de se tornarem mantenedores, modificaram os arquivos PKGBUILD para incluir código malicioso.

Este incidente mostra que a confiança pertence aos mantenedores, não aos pacotes. Quando um pacote muda de mãos, essa confiança deve ser conquistada novamente. Um pacote que era confiável no ano passado não é automaticamente confiável hoje. Revisar as mudanças é tão importante quanto revisar um pacote pela primeira vez.

Como usar o AUR com mais segurança

Você não precisa parar de usar o AUR. Você precisa ser mais deliberado sobre quando e como usá-lo.

1. Prefira os repositórios oficiais

Verifique os repositórios oficiais antes de usar o AUR. Os pacotes oficiais passam pelo processo de empacotamento do Arch e são mantidos pela equipe do Arch Linux. Use o AUR apenas quando o software não estiver disponível nos repositórios oficiais.

Alguns fornecedores de software também fornecem repositórios oficiais do Arch ou pacotes oficiais. Quando o fizerem, prefira esses em vez de pacotes do AUR mantidos pela comunidade. As atualizações vêm diretamente do editor em vez de um mantenedor do AUR.

2. Revise o PKGBUILD antes de construir

Um PKGBUILD é um script Bash. Revise-o antes de construir o pacote. Se você já confia no pacote, concentre-se no que mudou desde a última atualização.

Preste muita atenção se o pacote tem um novo mantenedor ou foi adotado recentemente. Procure por downloads inesperados, comandos que não estão relacionados à construção do software ou mudanças que não correspondem ao projeto upstream.

Um arquivo .install acompanhante também pode executar comandos durante a instalação do pacote. Revise-o se o pacote incluir um.

Leia os comentários do pacote. Outros usuários frequentemente relatam builds quebrados, mudanças de mantenedor ou comportamento suspeito.

3. Construa pacotes em um chroot limpo

Um chroot limpo é um ambiente de construção isolado que contém apenas os pacotes necessários para a construção. Ele reduz o risco de um script de construção acessar arquivos do seu ambiente de trabalho e ajuda a produzir construções limpas e reproduzíveis. O pacote devtools fornece ferramentas para criar e usar chroots limpos.

Você pode encontrar mais detalhes no link abaixo:

4. Considere o Flatpak para aplicativos de desktop

O Flatpak distribui aplicativos de desktop pré-construídos que rodam dentro de uma sandbox. Uma sandbox limita o que o aplicativo pode acessar, a menos que você conceda permissões adicionais. Isso reduz o impacto de um aplicativo comprometido, mas não garante que o aplicativo seja confiável.

Você pode instalar o flatpak e habilitar o repositório flathub usando os comandos:

sudo pacman -S flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

5. Use contêineres quando precisar de software de outra distribuição

Se você precisar de software que é mais fácil de instalar em outra distribuição Linux, considere executá-lo dentro de um contêiner Distrobox em vez de depender de um pacote AUR não oficial. O Distrobox mantém esse software isolado do seu sistema principal enquanto o integra com seu desktop.

Para instalar o Distrobox e criar contêineres (exemplo: Void Linux), faça:

sudo pacman -S distrobox
distrobox create --name void-box --image voidlinux/voidlinux
distrobox enter void-box

6. Audite pacotes AUR instalados

O seguinte comando lista pacotes estrangeiros, que são pacotes que não estão instalados dos repositórios oficiais:

pacman -Qm

Revise a lista regularmente. Preste atenção extra a pacotes que mudaram recentemente de mantenedor ou foram adotados após se tornarem órfãos.

7. Mantenha snapshots do sistema

Um snapshot do sistema de arquivos captura o estado atual do seu sistema. Ferramentas como Snapper ou Timeshift permitem reverter após uma atualização, instalação de pacote ou mudança de configuração ruim. Um snapshot não pode proteger credenciais que já foram roubadas, mas pode tornar a recuperação do sistema muito mais rápida.

Antes de instalar ou atualizar um pacote AUR, faça a si mesmo três perguntas:

  • O software está disponível nos repositórios oficiais ou do editor?
  • As mudanças recentes no PKGBUILD fazem sentido?
  • Eu confio no mantenedor atual?

Se você não puder responder a todas as três com confiança, pare e investigue antes de continuar.

Resumo

A campanha de malware do AUR de junho 2026 não é uma razão para parar de usar o Arch Linux ou o AUR. É um lembrete de que a confiança deve ser conquistada e revisada ao longo do tempo.

O ataque não explorou uma vulnerabilidade no Arch Linux. Explorou a confiança que os usuários depositavam em pacotes que mudaram de mantenedor. A mesma ideia aparece em muitos ataques à cadeia de suprimentos de software. Os invasores frequentemente visam software confiável em vez de vulnerabilidades técnicas.

O AUR oferece à comunidade uma maneira simples de empacotar e compartilhar software que não está disponível nos repositórios oficiais. Essa abertura também significa que os usuários devem decidir em quais pacotes confiar.

Cada recomendação neste artigo segue o mesmo princípio. Reduza a quantidade de confiança que você deposita no software e reduza o impacto se essa confiança for mal colocada.

Trate cada PKGBUILD como código executável, porque é exatamente isso que ele é. Revise as mudanças antes de construir. Preste atenção às mudanças de mantenedor. Use o AUR quando ele agregar valor, não simplesmente porque é conveniente.

Segurança não é sobre evitar todos os riscos. É sobre entender onde a confiança existe e decidir se ela foi conquistada.

Se você é novo no Arch, construa seu sistema base a partir dos repositórios oficiais, use Flatpak para extras, use contêineres para necessidades entre distribuições e trate o AUR como algo que você lê antes de confiar.

Recursos e leituras adicionais: