npm endurece autenticação, mas tokens opcionais ainda mantêm risco na cadeia de suprimentos

A eliminação de tokens permanentes reduz abuso de credenciais no npm, porém phishing de MFA, tokens de 90 dias com bypass e publicação sem credenciais verificáveis ainda deixam espaço para versões maliciosas.

Componente	Ecossistema npm, fluxos de autenticação de mantenedores, tokens de publicação e automações de CI com pacotes JavaScript.
Vetor	Comprometimento de contas de mantenedores, phishing de MFA no console do npm ou roubo de tokens com permissão de leitura e escrita para pacotes mantidos pelo autor.
Impacto	Publicação de novas versões ou pacotes maliciosos em nome de mantenedores legítimos, com risco de distribuição downstream para projetos que consomem artefatos do registro.
Prioridade	Migrar automações para OIDC Trusted Publishing, exigir MFA em publicação sempre que possível, reduzir tokens persistentes e revisar dependências publicadas em relação ao código-fonte verificável.
Artefatos	Tokens clássicos revogados, tokens de sessão curtos normalmente com duração de duas horas, tokens de até 90 dias com bypass de MFA ainda possíveis e credenciais por execução via OIDC.
Casos citados	Incidentes como Shai-Hulud, Sha1-Hulud e ataques envolvendo pacotes como ChalkJS, chalk/debug são apresentados como exemplos de abuso de confiança em mantenedores e artefatos publicados.

Resumo técnico

O npm concluiu em dezembro de 2025 uma reformulação relevante na autenticação do ecossistema, motivada pelo incidente Sha1-Hulud e por uma sequência de ataques de cadeia de suprimentos contra pacotes JavaScript. A mudança principal foi a remoção dos tokens clássicos, que eram credenciais de longa duração, amplamente escopadas e capazes de permanecer válidas por tempo indeterminado. Esse modelo criava uma condição crítica: se uma credencial fosse roubada, o operador malicioso poderia publicar versões adulteradas dos pacotes do mantenedor sem depender de código-fonte publicamente verificável.

Fluxo técnico

O novo modelo substitui tokens permanentes por tokens de sessão de curta duração em fluxos interativos. Em operações obtidas por login no npm, a sessão normalmente dura cerca de duas horas e o fluxo passa a favorecer MFA para publicação. Isso reduz a janela de abuso quando uma credencial é capturada, porque o atacante deixa de contar com um segredo reutilizável indefinidamente. Em paralelo, o npm incentiva OIDC Trusted Publishing, no qual sistemas de CI obtêm credenciais curtas e vinculadas a uma execução específica, em vez de armazenar tokens estáticos em variáveis, cofres ou configurações de pipeline.

A limitação central é que encurtar a vida útil da credencial não elimina a exploração quando o comprometimento ocorre em tempo real. O caso envolvendo ChalkJS é descrito como um phishing de MFA contra o console do npm, no qual o mantenedor foi induzido a entregar login e senha de uso único. Em uma repetição desse padrão, um operador ainda poderia capturar uma sessão curta e usá-la dentro da janela disponível para publicar uma versão maliciosa, já que a alteração de um pacote pode ocorrer em poucos minutos. A defesa melhora a contenção, mas não transforma phishing bem-sucedido em evento inofensivo.

Outro ponto técnico é a permanência de opções que preservam parte do risco anterior. MFA em publicação continua opcional, e desenvolvedores ainda podem criar tokens de até 90 dias com bypass de MFA pelo console. Esses tokens podem permitir leitura e escrita nos pacotes mantidos pelo autor. Se uma conta com essas configurações for comprometida, a situação se aproxima do modelo antigo: o atacante não precisa quebrar o registro nem explorar uma vulnerabilidade de execução remota, pois opera por meio de uma identidade autorizada a publicar artefatos.

Superfície afetada

A superfície exposta envolve mantenedores de pacotes, contas com permissão de publicação, automações de CI/CD e consumidores downstream que confiam no artefato publicado no registro. O problema não está limitado ao código-fonte do projeto: o material recebido pelo consumidor é o pacote publicado, e o texto destaca que, em grande parte dos casos de pacotes maliciosos analisados em base pública, o malware estava no artefato distribuído, não no repositório upstream. A implicação defensiva é direta: validações baseadas apenas no repositório de origem podem deixar de enxergar adulterações introduzidas no empacotamento ou na publicação.

Ambientes com tokens persistentes, tokens de 90 dias, bypass de MFA ou segredos armazenados em pipelines mantêm maior exposição. A automação é uma necessidade operacional para muitos mantenedores, mas, quando baseada em segredo estático com permissão ampla, transforma qualquer vazamento de variável, log, cache ou ambiente de build em caminho de publicação indevida. O modelo OIDC reduz essa classe de risco ao trocar segredo em repouso por credencial temporária por execução, mas sua adoção ainda depende de configuração e padronização nos fluxos de publicação.

• Contas de mantenedores que conseguem publicar novas versões em pacotes populares ou transitivamente consumidos.
• Pipelines de CI/CD que armazenam tokens de publicação em variáveis, cofres, runners ou configurações herdadas.
• Projetos que instalam artefatos diretamente do registro sem verificação adicional de proveniência ou consistência com o código-fonte.
• Organizações que dependem de lockfiles, caches e mirrors internos sem processo de invalidação após suspeita de pacote adulterado.

Hunting e telemetria

A investigação defensiva deve priorizar eventos de publicação, alterações de tokens e mudanças de autenticação. Em contas de mantenedores, sinais de risco incluem criação recente de tokens com bypass de MFA, publicação logo após novo login, alteração inesperada de configuração de MFA e versões liberadas fora do padrão habitual do projeto. Em pipelines, a análise deve buscar uso de credenciais antigas, variáveis de ambiente com escopo amplo e execuções que publicaram artefatos sem vínculo claro com um evento esperado de release.

No consumo de dependências, o hunting deve comparar versões recentemente publicadas com o repositório esperado e com o histórico normal de arquivos do pacote. Como o risco descrito inclui malware presente apenas no artefato distribuído, faz sentido observar divergências entre tarballs do registro e código-fonte upstream, scripts de instalação modificados, arquivos adicionados sem relação com a biblioteca e mudanças repentinas em permissões ou comportamento de build. A telemetria de endpoints e proxies pode complementar a análise ao identificar instalação de versões recém-publicadas em janelas compatíveis com incidentes de cadeia de suprimentos.

• Publicações realizadas minutos após login novo, troca de MFA ou criação de token de publicação.
• Tokens com duração prolongada ou configuração que evita MFA em operações sensíveis.
• Diferença entre artefato publicado e conteúdo esperado do repositório upstream.
• Instalação de versões recentes de pacotes citados em alertas internos, especialmente quando puxadas por dependências transitivas.
• Execuções de CI que acessam segredos de publicação fora do fluxo normal de release.

Mitigação

A mitigação deve começar pela redução de credenciais reutilizáveis. Mantenedores e organizações que publicam no npm devem substituir tokens clássicos remanescentes por fluxos de sessão curta ou por OIDC Trusted Publishing quando a automação permitir. Onde tokens de 90 dias ainda forem necessários, o escopo deve ser revisado, a rotação deve ser controlada e o bypass de MFA deve ser tratado como exceção de alto risco. A publicação local deve exigir MFA sempre que possível, porque isso reduz o valor de senhas ou sessões parcialmente comprometidas.

Para consumidores de pacotes, a resposta não termina na conta do mantenedor. É necessário revisar lockfiles, caches, mirrors internos e pipelines que tenham instalado versões liberadas durante uma janela suspeita. A validação deve considerar se o artefato publicado corresponde ao código-fonte esperado e se houve alteração inesperada em scripts, arquivos empacotados ou metadados. Quando houver suspeita de consumo de pacote adulterado, a organização deve congelar atualizações automáticas, identificar sistemas que instalaram a versão afetada, restaurar dependências para versões confiáveis e revisar segredos acessíveis durante builds e testes.

• Adotar OIDC Trusted Publishing para CI/CD e evitar segredos de publicação armazenados em repouso.
• Exigir MFA em publicação e remover tokens com bypass quando não houver justificativa técnica forte.
• Revisar permissões de mantenedores e reduzir contas capazes de publicar em pacotes críticos.
• Comparar artefatos publicados com o código-fonte upstream antes de promover dependências sensíveis.
• Invalidar caches e lockfiles contaminados quando uma versão maliciosa ou suspeita tiver sido instalada.
• Rotacionar segredos expostos a builds que possam ter executado pacotes adulterados.