O CTO da Ledger, Charles Guillemet, reportou no X um ataque à cadeia de suprimentos envolvendo pacotes NPM amplamente utilizados.
Está em curso um ataque em larga escala à cadeia de suprimentos: a conta NPM de um desenvolvedor respeitável foi comprometida. Os pacotes afetados já foram descarregados mais de 1 bilhão de vezes, o que significa que todo o ecossistema JavaScript pode estar em risco.
O payload malicioso funciona…
— Charles Guillemet (@P3b7_) 8 de setembro de 2025
De acordo com um relatório da CoinDesk, algumas versões comprometidas – totalizando mais de 1 bilhão de downloads – incluem código capaz de substituir, "em tempo real," endereços de destino em transações de criptomoedas, redirecionando fundos para carteiras controladas por atacantes. Este cenário alinha-se com as recomendações de proteção da cadeia de suprimentos publicadas por organizações do setor como a OWASP, que destacam como os compromissos na cadeia de suprimentos podem ter impactos em grande escala.
De acordo com os dados coletados pela nossa equipe de inteligência de ameaças nas últimas 24 horas, surgiram indicadores de compromisso consistentes com a técnica descrita em múltiplos repositórios e pipelines de construção. Os analistas com os quais colaboramos também enfatizam que o alcance do incidente é amplificado por dependências transitivas e pelo tamanho do registro: o registro NPM hospeda mais de 2 milhões de pacotes, aumentando a probabilidade de propagação de um módulo comprometido.
Mecanismo de Ataque: Endereços Alterados "Em Tempo Real"
Dito isso, a carga maliciosa ativa-se tanto durante operações on-chain quanto no momento da geração ou assinatura da transação. Na prática, o malware intercepta o endereço do destinatário e o substitui por um pertencente aos atores maliciosos. O usuário, ao ver uma tela aparentemente "limpa", pode não perceber que a transação final envia os fundos para um endereço diferente – uma dinâmica também confirmada pelo The Block. Deve-se notar que a manipulação visa permanecer invisível até o último passo de confirmação.
Atualização sobre o ataque NPM: O ataque felizmente falhou, com quase nenhuma vítima.
Começou com um email de phishing de um domínio de suporte npm falso que roubou credenciais e deu aos atacantes acesso para publicar atualizações de pacotes maliciosos. O código injetado visava a atividade de criptografia na web,… pic.twitter.com/lOik6k7Dkp
— Charles Guillemet (@P3b7_) 9 de setembro de 2025
Pacotes envolvidos: números, nomes provisórios e distribuição
As análises iniciais indicam que a violação ocorreu ao explorar a conta de um mantenedor com acesso a bibliotecas amplamente utilizadas. Entre os nomes circulados está, por exemplo, o pacote error-ex – cujo perfil oficial pode ser visto em npmjs.com – embora as listas oficiais ainda estejam a ser atualizadas. O impacto é amplificado pelo efeito em cascata devido a dependências: um único módulo comprometido pode se espalhar para centenas de projetos, graças às cadeias de importação. De fato, a natureza modular do código JavaScript facilita a propagação do problema quando as dependências estão profundamente aninhadas.
Escala de exposição: mais de 1 bilhão de downloads cumulativos de versões potencialmente em risco.
Vector: publicações no NPM através de credenciais roubadas ou pipeline comprometido.
Âmbito: bibliotecas principais usadas em projetos web e carteiras.
As listas oficiais de pacotes e versões afetados são parciais; é aconselhável monitorizar os avisos do NPM e os repositórios dos mantenedores. No entanto, até que comunicações definitivas sejam feitas, continua a ser prudente considerar toda a cadeia de dependências em risco.
Impacto nos usuários e nas empresas
Roubo direto de cripto após a substituição sorrateira do endereço.
Integridade da aplicação comprometida em dApps, extensões e carteiras de desktop/web.
Risco reputacional para projetos que integram pacotes contaminados.
O que Fazer Imediatamente: Lista de Verificação de Emergência
Para os usuários finais (crypto)
Prefira carteiras que exibam claramente as informações da transação ( tela e assinatura clara – Assinatura Clara ), verificando o endereço e o montante no dispositivo antes de confirmar. Para orientações práticas, consulte nosso guia sobre como verificar carteiras de hardware.
Evite a assinatura cega e limite o uso de códigos QR não verificados.
Compare o endereço exibido com uma cópia segura e use listas brancas para destinatários frequentes.
Esta precaução é crucial porque a confirmação numa carteira de hardware mostra os dados que estão realmente a ser assinados, tornando evidente qualquer substituição de endereço pelo software anfitrião. Neste contexto, a verificação no ecrã do dispositivo reduz a probabilidade de erro ou manipulação a montante.
Para equipas de desenvolvimento
Suspender temporariamente as atualizações automáticas de dependências críticas.
Realizar auditoria e reversão das versões publicadas durante o período suspeito.
Gire os tokens NPM e torne a ativação de 2FA obrigatória para mantenedores e liberadores (veja aqui).
Ative sistemas de proveniência para publicações e assine artefatos de construção.
Como verificar se um projeto está exposto
Identificar rapidamente dependências suspeitas e intervalos de versões instaladas é crucial: uma reconhecimento atempado limita o efeito dominó nos pipelines.
Listar versões instaladas e cadeia de dependências
npm ls error-ex
Verificar vulnerabilidades e avisos conhecidos
npm audit –production
npm audit –json > audit.json
Bloquear atualizações não determinísticas no CI
npm ci –ignore-scripts
Defina um limiar de auditoria mais rigoroso
npm config set audit-level=high
Verifique as versões disponíveis e as datas de publicação
npm view error-ex versions –json
npm view error-ex time –json
Em contextos de CI, definir ignore-scripts=true ajuda a reduzir o risco de executar scripts pós-instalação maliciosos. Dito isso, é aconselhável estabelecer uma linha base reprodutível imediatamente para evitar desvios inesperados. Para uma lista de verificação mais extensa sobre verificações de CI, consulte a nossa página sobre melhores práticas da cadeia de suprimentos.
Fortalecendo a cadeia de suprimentos: defesas técnicas recomendadas
Use um arquivo de bloqueio determinístico (package-lock.json) e faça a implementação com npm ci para garantir a reprodutibilidade.
Ative 2FA no NPM para publicações e acesso crítico, utilizando tokens com escopos limitados (automation vs. publish).
Implementar revisão de código obrigatória e usar um pipeline CI isolado com assinatura de artefato.
Adote sistemas de proveniência, referindo-se à documentação oficial sobre a proveniência de pacotes npm e padrões como SLSA.
Utilize ferramentas de verificação e atualizações controladas, como Dependabot, Renovate e sigstore/cosign, sempre que aplicável.
Aplique o princípio do menor privilégio para as contas dos mantenedores e bots de liberação.
Linha do tempo e estado das investigações
O alerta foi tornado público hoje, 8 de setembro de 2025, e as verificações estão atualmente em andamento. Avisos oficiais e listas atualizadas de pacotes e versões comprometidas serão lançados progressivamente. Portanto, é aconselhável manter uma abordagem cautelosa, suspendendo atualizações não essenciais até que os indicadores de compromisso sejam consolidados. Aguardando mais feedback, a prioridade continua a ser conter a exposição e documentar cuidadosamente cada alteração.
Ângulo Crítico: Uma Cadeia de Confiança Ainda Frágil
A cadeia de suprimentos de código aberto continua vulnerável quando o acesso a contas e os pipelines de publicação não estão adequadamente protegidos. O problema torna-se especialmente urgente quando, em 2025, numerosas publicações ainda ocorrem sem a adoção sistemática de medidas como 2FA, proveniência e revisões rigorosas.
Enquanto a confiança for considerada garantida, cada projeto continuará exposto ao risco gerado por outros. No entanto, até pequenas melhorias nos processos podem reduzir significativamente a superfície de ataque.
O Ponto
Este episódio destaca quão crítica é a segurança da cadeia de suprimentos em software de código aberto. Enquanto as investigações estiverem em andamento, a prioridade será limitar as superfícies de ataque, verificar cuidadosamente os dados das transações na tela e consolidar os processos de publicação por meio da adoção de 2FA, lockfile e sistemas de proveniência.
A transparência dos avisos, como notado por numerosos especialistas, será crucial na medição do impacto real e na restauração da confiança no ecossistema. Neste contexto, a adesão às melhores práticas continua a ser o único salvaguarda imediata.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
NPM sob ataque: pacotes JavaScript comprometidos, endereços de cripto hijacked. Aviso da Ledger...
O CTO da Ledger, Charles Guillemet, reportou no X um ataque à cadeia de suprimentos envolvendo pacotes NPM amplamente utilizados.
Está em curso um ataque em larga escala à cadeia de suprimentos: a conta NPM de um desenvolvedor respeitável foi comprometida. Os pacotes afetados já foram descarregados mais de 1 bilhão de vezes, o que significa que todo o ecossistema JavaScript pode estar em risco.
O payload malicioso funciona…
— Charles Guillemet (@P3b7_) 8 de setembro de 2025
De acordo com um relatório da CoinDesk, algumas versões comprometidas – totalizando mais de 1 bilhão de downloads – incluem código capaz de substituir, "em tempo real," endereços de destino em transações de criptomoedas, redirecionando fundos para carteiras controladas por atacantes. Este cenário alinha-se com as recomendações de proteção da cadeia de suprimentos publicadas por organizações do setor como a OWASP, que destacam como os compromissos na cadeia de suprimentos podem ter impactos em grande escala.
De acordo com os dados coletados pela nossa equipe de inteligência de ameaças nas últimas 24 horas, surgiram indicadores de compromisso consistentes com a técnica descrita em múltiplos repositórios e pipelines de construção. Os analistas com os quais colaboramos também enfatizam que o alcance do incidente é amplificado por dependências transitivas e pelo tamanho do registro: o registro NPM hospeda mais de 2 milhões de pacotes, aumentando a probabilidade de propagação de um módulo comprometido.
Mecanismo de Ataque: Endereços Alterados "Em Tempo Real"
Dito isso, a carga maliciosa ativa-se tanto durante operações on-chain quanto no momento da geração ou assinatura da transação. Na prática, o malware intercepta o endereço do destinatário e o substitui por um pertencente aos atores maliciosos. O usuário, ao ver uma tela aparentemente "limpa", pode não perceber que a transação final envia os fundos para um endereço diferente – uma dinâmica também confirmada pelo The Block. Deve-se notar que a manipulação visa permanecer invisível até o último passo de confirmação.
Atualização sobre o ataque NPM: O ataque felizmente falhou, com quase nenhuma vítima.
Começou com um email de phishing de um domínio de suporte npm falso que roubou credenciais e deu aos atacantes acesso para publicar atualizações de pacotes maliciosos. O código injetado visava a atividade de criptografia na web,… pic.twitter.com/lOik6k7Dkp
— Charles Guillemet (@P3b7_) 9 de setembro de 2025
Pacotes envolvidos: números, nomes provisórios e distribuição
As análises iniciais indicam que a violação ocorreu ao explorar a conta de um mantenedor com acesso a bibliotecas amplamente utilizadas. Entre os nomes circulados está, por exemplo, o pacote error-ex – cujo perfil oficial pode ser visto em npmjs.com – embora as listas oficiais ainda estejam a ser atualizadas. O impacto é amplificado pelo efeito em cascata devido a dependências: um único módulo comprometido pode se espalhar para centenas de projetos, graças às cadeias de importação. De fato, a natureza modular do código JavaScript facilita a propagação do problema quando as dependências estão profundamente aninhadas.
Escala de exposição: mais de 1 bilhão de downloads cumulativos de versões potencialmente em risco.
Vector: publicações no NPM através de credenciais roubadas ou pipeline comprometido.
Âmbito: bibliotecas principais usadas em projetos web e carteiras.
As listas oficiais de pacotes e versões afetados são parciais; é aconselhável monitorizar os avisos do NPM e os repositórios dos mantenedores. No entanto, até que comunicações definitivas sejam feitas, continua a ser prudente considerar toda a cadeia de dependências em risco.
Impacto nos usuários e nas empresas
Roubo direto de cripto após a substituição sorrateira do endereço.
Integridade da aplicação comprometida em dApps, extensões e carteiras de desktop/web.
Risco reputacional para projetos que integram pacotes contaminados.
O que Fazer Imediatamente: Lista de Verificação de Emergência
Para os usuários finais (crypto)
Prefira carteiras que exibam claramente as informações da transação ( tela e assinatura clara – Assinatura Clara ), verificando o endereço e o montante no dispositivo antes de confirmar. Para orientações práticas, consulte nosso guia sobre como verificar carteiras de hardware.
Evite a assinatura cega e limite o uso de códigos QR não verificados.
Compare o endereço exibido com uma cópia segura e use listas brancas para destinatários frequentes.
Esta precaução é crucial porque a confirmação numa carteira de hardware mostra os dados que estão realmente a ser assinados, tornando evidente qualquer substituição de endereço pelo software anfitrião. Neste contexto, a verificação no ecrã do dispositivo reduz a probabilidade de erro ou manipulação a montante.
Para equipas de desenvolvimento
Suspender temporariamente as atualizações automáticas de dependências críticas.
Realizar auditoria e reversão das versões publicadas durante o período suspeito.
Gire os tokens NPM e torne a ativação de 2FA obrigatória para mantenedores e liberadores (veja aqui).
Ative sistemas de proveniência para publicações e assine artefatos de construção.
Como verificar se um projeto está exposto
Identificar rapidamente dependências suspeitas e intervalos de versões instaladas é crucial: uma reconhecimento atempado limita o efeito dominó nos pipelines.
Listar versões instaladas e cadeia de dependências
npm ls error-ex
Verificar vulnerabilidades e avisos conhecidos
npm audit –production
npm audit –json > audit.json
Bloquear atualizações não determinísticas no CI
npm ci –ignore-scripts
Defina um limiar de auditoria mais rigoroso
npm config set audit-level=high
Verifique as versões disponíveis e as datas de publicação
npm view error-ex versions –json
npm view error-ex time –json
Em contextos de CI, definir ignore-scripts=true ajuda a reduzir o risco de executar scripts pós-instalação maliciosos. Dito isso, é aconselhável estabelecer uma linha base reprodutível imediatamente para evitar desvios inesperados. Para uma lista de verificação mais extensa sobre verificações de CI, consulte a nossa página sobre melhores práticas da cadeia de suprimentos.
Fortalecendo a cadeia de suprimentos: defesas técnicas recomendadas
Use um arquivo de bloqueio determinístico (package-lock.json) e faça a implementação com npm ci para garantir a reprodutibilidade.
Ative 2FA no NPM para publicações e acesso crítico, utilizando tokens com escopos limitados (automation vs. publish).
Implementar revisão de código obrigatória e usar um pipeline CI isolado com assinatura de artefato.
Adote sistemas de proveniência, referindo-se à documentação oficial sobre a proveniência de pacotes npm e padrões como SLSA.
Utilize ferramentas de verificação e atualizações controladas, como Dependabot, Renovate e sigstore/cosign, sempre que aplicável.
Aplique o princípio do menor privilégio para as contas dos mantenedores e bots de liberação.
Linha do tempo e estado das investigações
O alerta foi tornado público hoje, 8 de setembro de 2025, e as verificações estão atualmente em andamento. Avisos oficiais e listas atualizadas de pacotes e versões comprometidas serão lançados progressivamente. Portanto, é aconselhável manter uma abordagem cautelosa, suspendendo atualizações não essenciais até que os indicadores de compromisso sejam consolidados. Aguardando mais feedback, a prioridade continua a ser conter a exposição e documentar cuidadosamente cada alteração.
Ângulo Crítico: Uma Cadeia de Confiança Ainda Frágil
A cadeia de suprimentos de código aberto continua vulnerável quando o acesso a contas e os pipelines de publicação não estão adequadamente protegidos. O problema torna-se especialmente urgente quando, em 2025, numerosas publicações ainda ocorrem sem a adoção sistemática de medidas como 2FA, proveniência e revisões rigorosas.
Enquanto a confiança for considerada garantida, cada projeto continuará exposto ao risco gerado por outros. No entanto, até pequenas melhorias nos processos podem reduzir significativamente a superfície de ataque.
O Ponto
Este episódio destaca quão crítica é a segurança da cadeia de suprimentos em software de código aberto. Enquanto as investigações estiverem em andamento, a prioridade será limitar as superfícies de ataque, verificar cuidadosamente os dados das transações na tela e consolidar os processos de publicação por meio da adoção de 2FA, lockfile e sistemas de proveniência.
A transparência dos avisos, como notado por numerosos especialistas, será crucial na medição do impacto real e na restauração da confiança no ecossistema. Neste contexto, a adesão às melhores práticas continua a ser o único salvaguarda imediata.