Typosquatting: a ameaça silenciosa no `npm install`

Vá direto para um resumo gerado por IA desta postagem do blog

Você digitou npm install mil vezes. Provavelmente, você também já digitou errado o nome de um pacote pelo menos uma vez e teve sorte. Nem todo mundo tem essa sorte. Os invasores contam com esse único deslize — a confiança na memória muscular, o toque rápido na tecla Enter — e o mesmo ecossistema de pacotes que torna o desenvolvimento em JavaScript tão rápido é o que torna o typosquatting tão eficaz.

Esta publicação explica o que é o “typosquatting”, como identificá-lo e o que você pode fazer para proteger seus projetos.

O que é o “typosquatting”?

O “typosquatting” é a prática de publicar um pacote malicioso com um nome que se assemelha bastante se assemelha a um pacote popular e legítimo, na esperança de que os desenvolvedores digitem o nome incorretamente, o interpretem erroneamente, o copiem de uma fonte não confiável ou deixem de verificar novamente antes de instalar.

Alguns padrões comuns incluem:

Troca de caracteres, omissões ou erros ortográficos: lodash torna-se lodahs ou loadsh
Dicas sobre o uso do hífen: babel-core vs babelcore
Pluralização: cores vs cor
Dicas sobre escopo e namespace: @types/react (um pacote com escopo real) vs. um falso, sem escopo types-react
Homóglifos: substituição de uma letra minúscula l por um I, ou usar outros caracteres que se parecem

Depois de instalados, esses pacotes podem fazer tudo o que um pacote npm de verdade pode fazer: ler variáveis de ambiente, extrair arquivos .env ou chaves SSH, instalar backdoors ou injetar discretamente código malicioso na saída da sua compilação. Como os scripts do ciclo de vida do npm podem ser executados durante a instalação, o dano pode ocorrer antes mesmo de você ter analisado o código.

O typosquatting não se limita a pacotes. Ele também aparece em URLs. Veja, por exemplo, guthub.com. Se você já tentou digitar “github.com” e acabou acessando “guthub.com”, teve sorte: esse domínio redireciona para o site verdadeiro. Mas esse redirecionamento é uma cortesia que alguém configurou, não uma garantia. Quem registra um erro ortográfico comum controla para onde ele aponta, e se um malfeitor for o proprietário, um único erro de digitação pode levá-lo a um clone criado para roubar credenciais. No ecossistema de pacotes, o perigo é ainda mais direto, pois o mesmo tipo de erro pode introduzir código executável diretamente no seu projeto.

Por que justamente o JavaScript?

Isso não é exclusivo do JavaScript, mas o ecossistema do npm é um alvo particularmente atraente. O repositório é enorme, muitos pacotes são mantidos por pequenas equipes ou por indivíduos, e as árvores de dependências modernas podem ter centenas ou milhares de pacotes em sua estrutura devido às dependências transitivas aninhadas. Combine isso com as baixas barreiras à publicação e a natureza casual da instalação de dependências — do tipo “dar uma olhada e pronto” —, e o typosquatting tem amplo espaço para ter sucesso.

Esse mesmo risco se aplica a todos os gerenciadores de pacotes. A única diferença é o comando:

yarn add nome_do_pacote
pnpm add nome_do_pacote
bun add nome_do_pacote

Se você usa fios, pnpmou bun, a sintaxe difere do npm: todos os três usam add em vez de install. Mas todos eles obtêm os pacotes da mesma fonte — o registro do npm —, portanto, o comando muda, mas o problema de confiança permanece. Um pacote digitado incorretamente ou injetado de forma maliciosa pode chegar ao seu projeto, independentemente do gerenciador que você use, mesmo que você nunca digite “npm install” por conta própria.

O npm também não revoga o acesso de publicação de um mantenedor apenas porque a conta fica inativa, e o ataque ao Mastra, em junho de 2026, mostrou o que isso permite. Os invasores assumiram o controle da conta de um ex-colaborador do Mastra, cujo acesso ao escopo @mastra nunca havia sido revogado, e então injetaram o easy-day-js — que, por sua vez, é um typosquat da popular biblioteca dayjs — em mais de 140 pacotes do Mastra. Um escopo confiável tornou-se um canal de distribuição para uma dependência maliciosa com nome semelhante.

Como identificar um pacote que seja vítima de typosquatting

Os sinais de alerta nem sempre são óbvios, mas algumas verificações podem ajudar você a identificar um pacote suspeito antes que ele entre no seu projeto:

Verifique o número de downloads e o histórico de publicações. Um pacote que se diz ser uma biblioteca “popular”, mas com apenas algumas centenas de downloads e uma data de publicação da semana passada, é um sinal de alerta. Compare-o com as estatísticas do pacote original em npmjs.com.

Verifique quem é o mantenedor. A conta de publicação corresponde aos mantenedores conhecidos do projeto real? Uma conta totalmente nova, um mantenedor desconhecido ou um pacote sem histórico significativo de publicações merece uma análise mais detalhada.

Leia o arquivo package.json com atenção. Verifique a URL do repositório, a licença e a descrição. Os “typosquats” costumam copiar esses campos diretamente do pacote legítimo, mas, às vezes, o link do repositório leva a um endereço inesperado ou simplesmente não está presente.

Verifique os scripts de instalação antes de executá-los. Verifique os scripts de instalação antes de executá-los. pré-instalação, installe postinstall no `package.json` merecem atenção especial, pois podem executar código durante a instalação. Se uma biblioteca utilitária simples vier com um script de pós-instalação ofuscado que acessa uma URL remota, considere isso um sinal de alerta grave — foi exatamente assim que a dependência `easy-day-js` funcionou no ataque ao Mastra, baixando e executando uma carga útil de segundo estágio.

Use a pesquisa oficial no Registro, não adivinhe. Pesquise npmjs.com, copie o comando de instalação da documentação oficial do projeto ou use o preenchimento automático do seu IDE, em vez de digitar nomes de pacotes desconhecidos de memória. A memória muscular é útil até o momento em que instala o pacote errado.

Fique atento a alterações de última hora nas dependências. Se um package-lock.json ou yarn.lock , ou pnpm-lock.yaml Se o diff mostrar uma alteração no nome de uma dependência que você não esperava, pare e investigue antes de fazer a fusão. O mesmo se aplica a qualquer pacote recém-adicionado que ninguém da equipe tenha introduzido intencionalmente.

Estratégias práticas para o seu projeto

A revisão manual ajuda, mas não é escalável por si só. A abordagem mais eficaz consiste em incorporar proteções estruturais à forma como sua equipe instala, revisa e promove dependências:

Fixem suas dependências. Faça o commit do seu package-lock.json ou yarn.lock e use npm ci nos pipelines de CI/CD em vez de npm install. Isso garante que as compilações utilizem exatamente as versões que você verificou, e não aquelas que forem encontradas no momento da instalação.

Utilize ferramentas de verificação automatizadas. O npm audit, Snyk, Socket e GitHub Dependabot — conhecidas coletivamente como ferramentas de análise de composição de software (SCA) — podem sinalizar vulnerabilidades conhecidas, pacotes maliciosos e scripts de instalação inesperados. O Socket, em particular, foi desenvolvido especificamente para detectar riscos na cadeia de suprimentos, como typosquatting e ganchos pós-instalação maliciosos. Nenhuma dessas ferramentas detecta tudo, mas, juntas, elas oferecem à sua equipe uma chance muito maior de identificar riscos antes que eles cheguem à produção.

Defina versões exatas para dependências críticas. Evite intervalos de versão semver excessivamente amplos (^ ou ~) para pacotes que envolvam operações sensíveis, de modo que uma atualização automática não possa introduzir silenciosamente uma versão comprometida. A fixação também mantém o comportamento do pacote consistente entre equipes, ambientes e pipelines de CI/CD.

Desative os scripts por padrão quando for adequado.

Desative os scripts por padrão sempre que for adequado. Execute as instalações com –ignore-scripts na CI e, em seguida, incluir explicitamente na lista de permissões os pacotes que realmente precisam de etapas de compilação, reduz o alcance de um gancho pós-instalação malicioso. Vale a pena considerar o pnpm aqui também: desde a v10, ele bloqueia scripts do ciclo de vida das dependências por padrão e exige que você os aprove por meio de uma lista de permissões.

Executando npm install –ignore-scripts na CI e, em seguida, incluir explicitamente na lista de permissões os pacotes que realmente precisam de scripts de instalação, reduz o alcance de um gancho pós-instalação malicioso. Esse é um ótimo caso de uso para o pnpm. O pnpm ignora scripts de instalação por padrão desde a v10. Você pode usar a opção –ignore-scripts na linha de comando ou no arquivo .npmrc e no nível global.

Adote um registro privado ou um proxy. Ferramentas como Verdaccio, Sonatype Nexus, JFrog Artifactory ou os próprios recursos de registro privado do npm permitem que as equipes espelhem, aprovem e controlem pacotes antes que eles fiquem disponíveis para os desenvolvedores. Isso oferece um ponto de verificação onde cópias suspeitas podem ser bloqueadas antes mesmo de chegarem ao computador de um desenvolvedor.

Analise novas dependências como parte da revisão de código. Trate a adição de um novo pacote da mesma forma que trataria a adição de um novo colaborador com acesso ao seu código-fonte, pois, em termos funcionais, isso se aproxima do que você está fazendo. Crie uma política de segurança que defina como os novos pacotes serão aprovados, o que os revisores devem verificar e de quais fontes sua equipe tem permissão para fazer instalações. Ferramentas como o SecureChain podem auxiliar nesse processo, fornecendo às equipes uma fonte selecionada de pacotes de código aberto previamente avaliados.

Informe sua equipe. Uma conversa de cinco minutos sobre padrões de typosquatting pode evitar um incidente que pode custar caro. Incorpore isso ao treinamento de integração para qualquer função que tenha contato com o package.json. Crie uma política para a equipe, certifique-se de incluir verificações de segurança como prioridade máxima e faça com que ela seja cumprida.

Uma lista de verificação mental rápida

Antes de adicionar QUALQUER nova dependência, pergunte-se:

Será que esse é mesmo o nome que eu pretendia digitar?
O número de downloads e o histórico de publicações parecem legítimos?
O repositório de código-fonte corresponde a um projeto que eu reconheço ou que posso verificar?
Existem scripts de instalação? E será que eu entendo o que eles fazem, por que existem e se são necessários?
A minha ferramenta de verificação identificou alguma coisa?

Considerações finais

O typosquatting é eficaz porque se aproveita da confiança e da rotina, dois fatores nos quais os desenvolvedores confiam constantemente. A boa notícia é que, para reduzir o risco, não é necessário reformular todo o seu fluxo de trabalho.

A transição da memória muscular para nomes de pacotes verificados, árvores de dependências bloqueadas, verificação automatizada, registros aprovados e um momento de ceticismo saudável antes de cada nova instalação eliminará a grande maioria dessa superfície de ataque.

Resumo