O Nx, uma das ferramentas mais populares para gerenciamento de monorepositórios em projetos JavaScript e TypeScript, registra mais de 3,5 milhões de downloads semanais no NPM. Por isso, a notícia de que pacotes dessa biblioteca foram comprometidos em um sofisticado ataque à cadeia de suprimentos — batizado de s1ngularity — gerou grande choque na comunidade de desenvolvimento.
- O que aconteceu? O alerta sobre o ataque s1ngularity
- Anatomia do ataque: como a vulnerabilidade foi explorada
- O payload malicioso: o que o código fazia na sua máquina?
- A nova fronteira: usando IAs como ferramenta de ataque
- Você foi afetado? Passos imediatos para verificação e remediação
- Conclusão: lições aprendidas e o futuro da segurança na cadeia de suprimentos
O ataque Nx explorou uma vulnerabilidade no GitHub Actions, permitindo a publicação de versões maliciosas no NPM. Esses pacotes foram projetados para roubar credenciais de serviços de nuvem, GitHub, NPM e até ferramentas de inteligência artificial como Claude, Gemini e Amazon Q. No total, 2.349 credenciais de desenvolvedores foram vazadas.
Neste artigo, você vai entender em detalhes o que foi o ataque s1ngularity, como ele explorou uma brecha crítica, o que o payload malicioso fazia, como verificar se você foi afetado e, sobretudo, como se proteger contra ataques futuros à cadeia de suprimentos.

O que aconteceu? O alerta sobre o ataque s1ngularity
O ataque se deu quando versões comprometidas do pacote Nx e de seus plugins foram publicadas no NPM registry. Esses pacotes continham código malicioso que, após a instalação, buscava exfiltrar credenciais dos sistemas infectados.
Pacotes e versões afetadas
De acordo com os mantenedores do Nx, os seguintes pacotes foram comprometidos:
- [email protected] a 19.8.0-dev.5
- @nx/[email protected] a 19.8.0-dev.5
- @nx/[email protected] a 19.8.0-dev.5
- @nx/[email protected] a 19.8.0-dev.5
Essas versões foram rapidamente removidas, mas já haviam sido baixadas por milhares de usuários.
Impacto direto
O relatório preliminar indicou que 2.349 credenciais foram comprometidas, incluindo tokens de acesso a GitHub, AWS, OpenAI, NPM e outras plataformas críticas. Essas credenciais foram expostas em repositórios públicos do GitHub, criados automaticamente pelo malware no perfil da própria vítima.
Anatomia do ataque: como a vulnerabilidade foi explorada
A porta de entrada: a falha no pull_request_target do GitHub Actions
O vetor inicial do ataque foi o uso inseguro do gatilho pull_request_target
no GitHub Actions. Esse evento é usado para executar workflows em pull requests vindos de forks, mas com permissões elevadas.
Isso significa que, se mal configurado, um atacante pode injetar código em um workflow privilegiado, explorando o GITHUB_TOKEN que tem privilégios de escrita no repositório.
Foi exatamente isso que aconteceu no caso do Nx: um atacante abriu um Pull Request com título malicioso, que acionou o workflow de publicação.
Do acesso ao roubo: a exfiltração do token NPM
O código injetado forçou a execução do publish.yml, responsável por publicar pacotes no NPM.
Com isso, o invasor conseguiu roubar o token de publicação dos mantenedores e enviá-lo para um webhook controlado por eles. Em seguida, o token foi usado para publicar as versões maliciosas no registro oficial.
O payload malicioso: o que o código fazia na sua máquina?
Varredura de credenciais e o vazamento para o GitHub
Após a instalação de uma versão maliciosa, um script pós-instalação era executado. Esse script fazia uma varredura no sistema em busca de:
- Tokens de autenticação (GitHub, NPM, AWS, OpenAI, etc.)
- Arquivos de configuração em diretórios comuns de desenvolvedores
- Chaves de API em arquivos
.env
e.json
Todos esses dados eram enviados automaticamente para repositórios públicos criados no GitHub da vítima, com o padrão s1ngularity-repository.
Uma armadilha perigosa nos arquivos .zshrc e .bashrc
Outra técnica usada foi a modificação dos arquivos .zshrc
e .bashrc
, adicionando uma linha que executava:
sudo shutdown -h 0
Essa tática forçava o usuário a digitar sua senha de administrador, acreditando ser apenas um ajuste de ambiente. No entanto, ao fornecer a senha, a máquina era desligada e o invasor tinha acesso ao cache de credenciais sudo.
A nova fronteira: usando IAs como ferramenta de ataque
O que mais chamou atenção foi o uso de ferramentas de IA em linha de comando como parte da operação. O malware explorava CLIs de IA como:
- Claude
- Google Gemini
- Amazon Q
Usando flags como –dangerously-skip-permissions, o código conseguia escanear diretórios completos e exfiltrar dados sensíveis, transformando assistentes de IA em ferramentas de espionagem automatizada.
Esse aspecto mostra que a integração crescente de IAs no desenvolvimento pode ser explorada como vetor de ataque.
Você foi afetado? Passos imediatos para verificação e remediação
Se você usou Nx recentemente, siga os passos abaixo para verificar e proteger seu ambiente:
Passo 1: Verifique suas versões
Rode o comando abaixo no terminal:
npm list nx
Se você encontrar alguma das versões 19.8.0-dev.1 a 19.8.0-dev.5, significa que esteve exposto.
Passo 2: Inspecione seus arquivos de configuração
Confira os arquivos .zshrc
e .bashrc
com:
cat ~/.zshrc | grep shutdown
cat ~/.bashrc | grep shutdown
Se encontrar a linha sudo shutdown -h 0, remova-a imediatamente.
Passo 3: Busque por repositórios maliciosos
Acesse sua conta do GitHub e verifique se há repositórios criados com o nome s1ngularity-repository.
Caso existam, remova-os e investigue os commits.
Passo 4: Rotacione todas as suas credenciais
Revogue e regenere todos os tokens e chaves de API que possam ter sido expostos:
GitHub, NPM, AWS, OpenAI, Google Cloud e quaisquer outros serviços sensíveis.
Conclusão: lições aprendidas e o futuro da segurança na cadeia de suprimentos
O ataque Nx via s1ngularity demonstrou como vulnerabilidades em pipelines de CI/CD podem ser exploradas para comprometer até mesmo ferramentas amplamente confiáveis. Ele combinou técnicas de supply chain attack com métodos inovadores, como o uso de CLIs de IA como armas de espionagem.
As principais lições que a comunidade pode tirar são:
- Auditar workflows do GitHub Actions e evitar o uso inseguro de
pull_request_target
. - Ativar autenticação em dois fatores (2FA) para publicação no NPM.
- Rotacionar credenciais regularmente.
- Compartilhar conhecimento: alertar colegas de equipe e comunidade para reduzir o impacto coletivo.
A cadeia de suprimentos de software é um dos alvos mais sensíveis do cenário atual de cibersegurança. Estar preparado, informado e vigilante é a melhor defesa contra ataques desse porte.