Descoberta e escopo
Uma nova onda de ataques à cadeia de suprimentos está atingindo o ecossistema npm através de uma campanha de malware auto-propagante conhecida como CanisterWorm. A ameaça, ligada a um grupo rastreado como TeamPCP, compromete namespaces legítimos de publicadores e empurra versões de pacotes envenenadas, transformando efetivamente ferramentas de desenvolvimento confiáveis em mecanismos de entrega silenciosos para código de roubo de credenciais.
O que mudou agora
O CanisterWorm chamou a atenção pela primeira vez através de relatórios iniciais de pesquisadores de segurança da Socket e Endor Labs, que rastrearam um padrão recorrente de atualizações de pacotes maliciosos em várias contas de publicador npm. O malware é cuidadosamente escondido dentro do que parecem ser atualizações de versão de SDK rotineiras, tornando fácil para os desenvolvedores instalá-lo sem levantar suspeitas.
Vetor e exploração
Os pesquisadores da JFrog identificaram novas versões de pacotes comprometidas anteriormente não relatadas ligadas ao ataque CanisterWorm, estendendo o escopo conhecido da campanha muito além das divulgações anteriores. O impacto de uma infecção bem-sucedida vai muito além de uma única máquina. Uma vez que um desenvolvedor instala um dos pacotes contaminados, o CanisterWorm deixa um backdoor Python no host, começa a colher tokens de autenticação npm e usa essas credenciais para se espalhar autonomamente para cada pacote que o desenvolvedor comprometido mantém.
Impacto e alcance
Esse comportamento de reação em cadeia significa que uma conta de desenvolvedor afetada pode se tornar uma plataforma de lançamento para envenenar dezenas de pacotes downstream, colocando uma ampla gama de projetos dependentes e seus usuários em risco imediato. O que torna o CanisterWorm particularmente difícil de conter é como ele se mistura naturalmente nos fluxos de trabalho de desenvolvimento normais. Ao se esconder atrás de atualizações de versão e aproveitar a infraestrutura descentralizada para comunicação de comando, ele contorna os indicadores tradicionais que a maioria das ferramentas de segurança procura.
Análise técnica detalhada
O processo de infecção começa no momento em que um desenvolvedor executa npm install em um pacote comprometido. Um hook postinstall malicioso embutido no arquivo package.json é executado automaticamente e silenciosamente deixa um backdoor Python no sistema host sem nenhum aviso visível. Em máquinas Linux, o verme então registra um serviço de segundo plano persistente chamado pgmon através do systemd, garantindo que permaneça ativo e sobreviva a reinicializações do sistema.
Uma vez estabelecido, o backdoor consulta continuamente um canister do Internet Computer Protocol (ICP) — um endpoint hospedado em blockchain descentralizado — que atua como um servidor de comando e controle dead-drop. Esse design faz com que o tráfego malicioso se misture naturalmente com solicitações web regulares, dificultando significativamente a detecção por ferramentas de monitoramento de rede. Os payloads secundários recuperados através deste canal são escritos em /tmp/pglog, enquanto o verme rastreia seu estado de execução dentro de /tmp/.pg_state.
Lista de pacotes comprometidos
Abaixo estão alguns dos pacotes conhecidos comprometidos identificados pela JFrog X-ray, demonstrando a amplitude do ataque.
| Package Name | Compromised Version(s) | JFrog X-ray ID |
|---|---|---|
| @pypestream/floating-ui-dom | 2.15.1 | XRAY-955001 |
| @leafnoise/mirage | 2.0.3 | XRAY-954938 |
| @opengov/ppf-backend-types | 1.141.2 | XRAY-954962 |
| eslint-config-ppf | 0.128.2 | XRAY-954936 |
| @emilgroup/setting-sdk | 0.2.3, 0.2.2, 0.2.1 | XRAY-955067 |
| @teale.io/eslint-config | 1.8.16–1.8.9 | XRAY-954945 |
Medidas de mitigação recomendadas
Qualquer pessoa que execute qualquer uma das versões de pacotes identificadas deve tratar seu ambiente como já infectado. Os desenvolvedores devem rotacionar imediatamente todos os tokens de publicação npm armazenados em arquivos .npmrc, variáveis de ambiente e segredos de pipeline CI/CD. No Linux, o serviço pgmon deve ser parado e desabilitado usando systemctl, com seus arquivos e diretórios de serviço associados removidos inteiramente.
O que os CISOs devem fazer imediatamente
Os arquivos temporários /tmp/pglog e /tmp/.pg_state devem ser excluídos. Os diretórios node_modules afetados devem ser purgados e reconstruídos do zero usando versões de pacotes verificadas e seguras. Desenvolvedores cujos tokens foram roubados devem despublicar manualmente as versões de pacotes comprometidas do registro npm, pois simplesmente publicar uma versão mais recente não protege os usuários downstream que ainda podem instalar a versão infectada. Executar npm config set ignore-scripts true globalmente impede que hooks postinstall sejam acionados silenciosamente em instalações futuras, servindo como uma medida defensiva prática contra essa classe de ataque à cadeia de suprimentos.