Versões maliciosas de node-ipc publicadas no npm após suspeita de comprometimento da conta de um mantenedor

Em 14 de maio de 2026, várias versões maliciosas do popular pacote npm node-ipc foram publicadas no registro do npm. As informações públicas disponíveis identificam node-ipc@9.1.6, node-ipc@9.2.3 e node-ipc@12.0.1 como versões comprometidas, contendo um payload ofuscado para roubar credenciais. O código malicioso foi adicionado ao bundle CommonJS, node-ipc.cjs, e é acionado quando o pacote é carregado por meio de require("node-ipc"). As primeiras análises sugerem que o ataque pode ter envolvido o abuso de uma conta legítima de mantenedor do npm, e não o comprometimento do pipeline de CI/CD do projeto. Organizações que instalaram ou fizeram builds com as versões afetadas devem considerar potencialmente comprometidos os segredos de desenvolvedores, CI/CD, nuvem, SSH, GitHub, Kubernetes e outros que estavam acessíveis nesses ambientes. A Snyk publicou um aviso sobre o problema como SNYK-JS-NODEIPC-16697063. As equipes devem usá-lo para identificar caminhos de dependência vulneráveis e priorizar a correção.

Componente envolvido

node-ipc é um pacote Node.js usado para comunicação entre processos e, historicamente, tem sido amplamente utilizado no ecossistema npm, tanto de forma direta quanto transitiva.

Esta não é a primeira vez que node-ipc é associado a um incidente na cadeia de suprimentos. Em 2022, a Snyk analisou o incidente envolvendo node-ipc e peacenotwar, no qual um comportamento no estilo protestware afetou usuários de pacotes dependentes. A atividade de maio de 2026 parece ser um caso separado. A análise atual não aponta para protestware, mas para versões maliciosas que contêm um payload ofuscado para roubar credenciais.

O incidente de 2026 parece ser independente do ocorrido em 2022. O payload de 2026 relatado até o momento tem como foco o roubo de credenciais e a exfiltração furtiva de dados, e não o comportamento de protestware observado em 2022. As análises públicas afirmam que o payload foi injetado no ponto de entrada CommonJS e não dependia de scripts do ciclo de vida do npm, como postinstall.

Versões afetadas conhecidas

As informações públicas disponíveis identificam essas três versões maliciosas e indicam que todas foram publicadas em 14 de maio de 2026. Os relatos também afirmam que o arquivo node-ipc.cjs comprometido era idêntico em todas as versões afetadas.

Linha do tempo

Como o comprometimento pode ter ocorrido

A hipótese pública mais consistente é que as versões maliciosas foram publicadas por meio de uma conta de mantenedor do npm com permissões legítimas de publicação. A StepSecurity relatou que as versões foram publicadas pela conta atiertant, que aparecia na lista de mantenedores, mas não tinha histórico anterior de publicações para node-ipc.

A Upwind e outros relatos públicos descreveram um possível caminho para assumir o controle de um domínio expirado: o invasor pode ter registrado novamente um domínio associado ao e-mail da conta do mantenedor, configurado o recebimento de e-mails e, em seguida, usado a recuperação de conta do npm para assumir o controle da conta.

As evidências disponíveis apontam para o abuso da identidade de um mantenedor com permissões de publicação no npm. As análises públicas sugerem que um domínio de e-mail expirado de um mantenedor pode ter permitido a recuperação da conta, mas a investigação ainda está em andamento. Essa distinção é importante porque indica que não foi necessário comprometer o próprio registro do npm, e que o repositório de código-fonte ou o pipeline de CI/CD do projeto podem não ter sido o vetor inicial do ataque.

Vetor de ataque e comportamento malicioso

O payload parece ter sido inserido em node-ipc.cjs, o bundle CommonJS usado por quem carrega o pacote com require("node-ipc"). Análises públicas informam que o ponto de entrada ESM não foi modificado da mesma forma.

Ao contrário de muitos incidentes de malware no npm, segundo relatos, esse comprometimento não usou scripts executados durante a instalação, como preinstall, install ou postinstall. Em vez disso, a lógica maliciosa foi adicionada como uma expressão de função invocada imediatamente. Isso significa que o código podia ser executado quando o pacote fosse importado durante a execução, e não apenas quando a dependência fosse instalada.

• Identificação do ambiente e do host

• Busca por credenciais locais e arquivos confidenciais de desenvolvedores

• Coleta de credenciais de nuvem, chaves SSH, tokens do Kubernetes, configurações da CLI do GitHub, estado do Terraform, credenciais de bancos de dados, histórico do shell e configurações de ferramentas de IA e desenvolvimento

• Compactação dos dados coletados

• Exfiltração de dados para uma infraestrutura controlada pelo invasor

A StepSecurity informa que o payload visava mais de 90 categorias de credenciais e exfiltrava os dados coletados para uma infraestrutura que usava o domínio azurestaticprovider[.]net.

Quem pode ter sido afetado

1. Seu projeto depende diretamente de node-ipc e resolve para a versão 9.1.6, 9.2.3 ou 12.0.1.

2. Seu projeto depende de outra dependência que, por sua vez, trouxe uma das versões afetadas.

3. Seu pipeline de CI/CD, build de contêiner, estação de trabalho de desenvolvimento ou cache de pacotes instalou uma das versões maliciosas.

4. Você usa intervalos semver que podem ter resolvido automaticamente para uma das versões afetadas, como ^9, ~9.1, ~9.2, ^12 ou instalações sem versão fixada.

5. Você executou caminhos de código que carregaram node-ipc por meio da resolução CommonJS.

Encontrar a versão apenas em um arquivo de lock não comprova que o código malicioso foi executado, mas já é motivo para iniciar uma investigação. Se o pacote foi instalado em um ambiente de desenvolvimento ou CI/CD com acesso a segredos, considere que as credenciais podem ter sido expostas.

Orientações para detecção

Verifique seu aplicativo com a CLI da Snyk, executando-a na raiz do projeto.

snyk test

Ao monitorar seu aplicativo na interface web da Snyk, você receberá um alerta automaticamente.

Se preferir, verifique as árvores de dependências e os arquivos de lock para encontrar as versões afetadas:

npm ls node-ipc

npm ls node-ipc --all 2>/dev/null | grep -E '9\.1\.6|9\.2\.3|12\.0\.1'

grep -E '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.json

grep -E 'node-ipc@(9\.1\.6|9\.2\.3|12\.0\.1)' yarn.lock

grep -E 'node-ipc.*9\.1\.6|9\.2\.3|12\.0\.1' pnpm-lock.yaml

find . -path '*/node_modules/node-ipc/node-ipc.cjs' -exec ls -lh {} \;

Os indicadores de rede e host relatados incluem conexões de saída para sh.azurestaticprovider[.]net, tráfego de saída para 37.16.75[.]69, tráfego inesperado de UDP/53 gerado por processos de aplicativo ou build, diretórios temporários correspondentes ao padrão $TMPDIR/nt-* e processos ou processos filhos que usam a variável de ambiente __ntw=1 . Esses indicadores podem mudar conforme a infraestrutura do invasor é desativada ou substituída. Portanto, a ausência desses sinais não deve ser considerada prova de segurança.

Mitigação e resposta

Remova as versões maliciosas

• Fixe node-ipc em uma versão conhecida como segura.

• Atualize os arquivos de lock.

• Limpe os caches locais e de pacotes do CI onde os arquivos tar maliciosos possam estar armazenados.

• Gere novamente os artefatos a partir de árvores de dependências limpas.

Identifique todos os ambientes em que o pacote foi instalado

• Notebooks de desenvolvedores

• Executores de CI

• Contêineres de build

• Registros internos de artefatos

• Workers de build efêmeros

• Sistemas de produção, caso tenham ocorrido importações durante a execução

Troque os segredos expostos

• Tokens do npm

• Tokens do GitHub

• Credenciais de provedores de nuvem

• Chaves SSH

• Segredos de CI/CD

• Tokens e arquivos kubeconfig do Kubernetes

• Credenciais de bancos de dados

• Credenciais de acesso ao estado do Terraform

• Credenciais de ferramentas de IA e desenvolvimento

Invalide sessões e revise os logs de acesso

• Revise os logs de auditoria da nuvem.

• Verifique os logs de auditoria da organização no GitHub.

• Revise a atividade da conta do npm e o histórico de publicação de pacotes.

• Procure comportamentos incomuns em tarefas de CI/CD, novos segredos, novas chaves de implantação ou publicações inesperadas de pacotes.

Reforce a segurança no consumo de pacotes

• Use arquivos de lock e builds determinísticos.

• Evite consumir automaticamente versões recém-publicadas de pacotes em sistemas de build de produção.

• Considere períodos de espera para atualizações de dependências ou políticas para proxies internos de pacotes.

• Exija MFA para quem publica pacotes no npm.

• Remova mantenedores inativos e domínios de e-mail expirados de projetos de código aberto.

• Monitore mudanças nas contas de mantenedores e novas publicações após longos períodos de inatividade.

• Analise e monitore continuamente seus aplicativos com a Snyk para detectar vulnerabilidades

Por que este incidente é importante

Este incidente é mais um exemplo de como invasores têm como alvo as relações de confiança que sustentam os ecossistemas de código aberto. Para ser eficaz, o pacote malicioso não precisava comprometer o funcionamento do aplicativo. Ao preservar o comportamento esperado enquanto coletava credenciais discretamente, o invasor aumentou as chances de que builds e ambientes de desenvolvimento comprometidos continuassem funcionando normalmente.

O incidente também evidencia uma fragilidade recorrente na cadeia de suprimentos: pacotes inativos ou com pouca manutenção podem continuar tendo amplo alcance no ecossistema, mesmo após longos períodos sem atividade. Se a identidade de um antigo mantenedor puder ser recuperada, sequestrada ou abusada, os invasores poderão publicar versões maliciosas em grafos de dependências sem tocar no controle de versão nem nos sistemas de CI/CD.

Avaliação atual

Com base nas informações disponíveis, este incidente deve ser tratado como um comprometimento crítico da cadeia de suprimentos do npm, cujo principal risco é o roubo de credenciais em ambientes de desenvolvimento e CI/CD. As versões afetadas confirmadas até o momento são node-ipc@9.1.6, node-ipc@9.2.3 e node-ipc@12.0.1. O caminho de ataque mais provável é o abuso de uma conta de mantenedor com permissões de publicação, possivelmente por meio da recuperação de um domínio de e-mail expirado do mantenedor. A investigação da causa-raiz ainda está em andamento.

As equipes devem verificar imediatamente se alguma versão afetada foi instalada, trocar os segredos dos ambientes expostos e monitorar possíveis abusos subsequentes das credenciais roubadas.