Mais uma vez o Arch User Repository (AUR) se tornou alvo de uma campanha maliciosa. Desta vez, porém, o incidente alcançou uma escala muito maior do que casos anteriores e levou a própria equipe do Arch Linux a adotar medidas emergenciais para conter novas alterações suspeitas.
Pesquisadores da Sonatype divulgaram detalhes de uma operação que recebeu o nome de “Atomic Arch”. Segundo a empresa, invasores passaram a assumir o controle de pacotes abandonados no AUR e utilizar essas páginas já existentes para distribuir código malicioso aos usuários.
As primeiras análises apontavam algumas dezenas de pacotes comprometidos. Em menos de 24 horas, entretanto, o número cresceu rapidamente. Relatos posteriores indicaram centenas de pacotes afetados e estimativas iniciais chegaram a aproximadamente 1.500 pacotes potencialmente comprometidos.
Diante da situação, a equipe do Arch Linux publicou um comunicado confirmando que estava investigando uma grande quantidade de adoções e atualizações maliciosas dentro do AUR. Como medida temporária, algumas operações relacionadas à criação de contas, adoção de pacotes e envio de atualizações passaram a sofrer restrições enquanto os mantenedores trabalhavam para remover alterações suspeitas.
Diferentemente do que muita gente imagina, os invasores não alteraram os repositórios oficiais do Arch Linux. O alvo foi exclusivamente o AUR, o repositório comunitário onde usuários compartilham definições de pacotes para softwares que não fazem parte dos repositórios oficiais da distribuição.
O método utilizado explorava uma característica conhecida do próprio AUR. Quando um pacote deixa de receber manutenção, ele pode ser marcado como órfão. Após esse processo, outro usuário pode solicitar sua adoção e assumir a responsabilidade pela manutenção do projeto.
Segundo a Sonatype, os invasores aproveitaram exatamente esse mecanismo para assumir o controle de diversos pacotes abandonados.
Após obter acesso aos projetos, eles modificavam os arquivos PKGBUILD para executar comandos adicionais durante a instalação. Em vez de conter o malware diretamente, esses comandos utilizavam ferramentas como npm e, posteriormente também o Bun, para baixar componentes maliciosos hospedados externamente.
O pacote aparentemente continuava sendo o mesmo, mas durante a instalação, passava a buscar código que não fazia parte originalmente do projeto.
O que o malware fazia
A análise realizada pelos pesquisadores encontrou indícios de funcionalidades bastante agressivas.
Entre os recursos identificados estavam mecanismos relacionados à coleta de credenciais, obtenção de tokens de autenticação e captura de informações armazenadas em aplicações amplamente utilizadas por desenvolvedores.
Também foram encontrados elementos associados à ocultação de processos e arquivos, técnicas normalmente presentes em rootkits modernos.
Segundo os pesquisadores, o código continha referências a:
- Credenciais do GitHub;
- Chaves SSH;
- Tokens do HashiCorp Vault;
- Dados do Slack;
- Informações do Discord;
- Dados do Microsoft Teams;
- Informações armazenadas pelo Telegram;
- Bancos de dados de cookies de navegadores.
Além disso, foram identificadas rotinas que indicam possível envio dessas informações para servidores remotos. Por esse motivo, a recomendação da Sonatype é que sistemas afetados sejam tratados como potencialmente comprometidos, mesmo após a remoção do pacote responsável pela infecção.
O caso lembra um incidente de 2025, mas há diferenças importantes
Quem nos acompanha talvez se lembre de outro incidente envolvendo o AUR que noticiamos em julho de 2025.
Naquela ocasião, pacotes chamados librewolf-fix-bin, firefox-patch-bin e zen-browser-patched-bin foram publicados contendo scripts que instalavam o CHAOS RAT, um malware de acesso remoto capaz de assumir controle completo da máquina da vítima. Embora os dois casos tenham ocorrido dentro do AUR, existe uma diferença importante entre eles.
Em 2025, os invasores criaram pacotes maliciosos do zero e dependiam de convencer usuários a instalá-los. Já no caso do Atomic Arch, os atacantes assumiram pacotes que já existiam e que possuíam histórico dentro da comunidade. Em vez de atrair usuários para novos projetos suspeitos, eles passaram a distribuir código malicioso por meio de pacotes que muitas pessoas já utilizavam normalmente.
Isso torna a identificação do problema significativamente mais difícil e a propagação mais eficiente. Um usuário experiente costuma desconfiar de um pacote recém-publicado por um mantenedor desconhecido. É muito mais complicado perceber que um pacote utilizado há anos recebeu uma atualização maliciosa após uma mudança de mantenedor.
O Arch Linux continua seguro?
A resposta curta é sim. Assim como aconteceu no incidente de 2025, os repositórios oficiais do Arch Linux não foram comprometidos.
O problema ocorreu exclusivamente dentro do AUR, que sempre operou sob um modelo diferente dos repositórios oficiais. O próprio projeto recomenda que os usuários revisem os arquivos PKGBUILD antes de instalar ou atualizar pacotes vindos do repositório comunitário.
Entretanto, muitos usuários utilizam ferramentas como yay ou paru para automatizar instalações e atualizações, o que acaba reduzindo a atenção dada às alterações realizadas em cada pacote.
O episódio também serve como lembrete de que software livre e código aberto oferecem transparência, mas não eliminam a necessidade de boas práticas de segurança.
Especialmente quando falamos de repositórios comunitários, revisar alterações, acompanhar mudanças de mantenedores e limitar o uso de pacotes desnecessários continua sendo uma das formas mais eficazes de reduzir riscos.
Por enquanto, a investigação continua em andamento e tanto a Sonatype quanto a equipe do Arch Linux seguem identificando pacotes potencialmente afetados.
Fique por dentro das principais novidades da semana sobre tecnologia e Linux: receba nossa newsletter!
