GitHub exige 2FA e tokens efêmeros no npm
GitHub vai exigir 2FA e tokens curtos no npm, anunciado em 23 set 2025, para conter ataques de cadeia de suprimentos após incidentes como Shai-Hulud e o pacote fezbox (476 downloads). A empresa mudará autenticação e publicação no registry: 2FA obrigatória, tokens granulares com expiração de 7 dias e trusted publishing via OIDC, elevando a verificação de proveniência e reduzindo abuso de credenciais.
Tabela de conteúdos
O que muda no npm: 2FA, tokens efêmeros e trusted publishing
Em resposta a uma onda recente de ataques à cadeia de suprimentos no ecossistema npm, o GitHub anunciou alterações “no futuro próximo” que passam a exigir 2FA para publicação local, substituem tokens clássicos, reduzem a validade de tokens granulares e incentivam a publicação com identidade derivada do CI/CD via OpenID Connect (OIDC). A proposta é diminuir a superfície de ataque onde chaves estáticas e TOTP são alvos frequentes de exfiltração e phishing.
- Descontinuação dos tokens clássicos (legados).
- 2FA por TOTP será descontinuada, com migração para 2FA baseada em FIDO.
- Tokens granulares de publicação terão expiração padrão de 7 dias.
- Acesso de publicação: tokens desabilitados por padrão; preferir trusted publishing ou 2FA local sem bypass.
- Remoção da opção de ignorar 2FA para publicações locais.
- Ampliação do rol de provedores elegíveis para trusted publishing.
“Todo pacote publicado via trusted publishing inclui prova criptográfica de sua origem e ambiente de build.”
GitHub, changelog de 31 de julho de 2025
Na prática, o trusted publishing elimina a necessidade de armazenar tokens npm em pipelines, trocando-os por credenciais efêmeras, específicas do workflow e intransferíveis. A CLI do npm gera e publica automaticamente atestações de proveniência, permitindo que consumidores validem onde e como um pacote foi construído.
Por que agora: ataques à cadeia de suprimentos e abuso de tokens
As medidas seguem o ataque batizado de Shai-Hulud, que injetou um worm autorreplicante em centenas de pacotes npm, com varredura por segredos em máquinas de desenvolvedores e exfiltração para servidores controlados por invasores. O caso mostrou que o roubo não se limita a tokens npm — qualquer segredo disponível no ambiente pode ser explorado, de chaves de nuvem a cookies.
“Ao combinar autorreplicação com a capacidade de roubar múltiplos tipos de segredos (e não apenas tokens npm), o worm poderia sustentar uma cadeia interminável de ataques sem a ação rápida do GitHub e de mantenedores.”
Xavier René-Corail, GitHub
O reforço de 2FA baseada em FIDO e a adoção de credenciais de curta duração mitigam classes inteiras de ataques: reduzem risco de phishing contra códigos TOTP, inviabilizam uso prolongado de credenciais exfiltradas e estabelecem vínculo verificável entre repositório, workflow e pacote publicado.
| Medida | Antes | Como fica |
| Autenticação 2FA | TOTP aceito | Foco em FIDO (chaves de segurança) |
| Tokens de publicação | Clássicos, longo prazo | Granulares, expiram em 7 dias |
| Publicação local | Bypass de 2FA possível | Sem bypass, 2FA obrigatório |
| Publicação via CI/CD | Tokens armazenados | Trusted publishing com OIDC |
Como funciona o trusted publishing (OIDC e atestações)
No trusted publishing, o provedor de CI/CD emite um token OIDC por execução do workflow, atestando a identidade do job (repositório, branch/tag, commit). O npm aceita a publicação ao validar a afirmação OIDC e emite credenciais efêmeras, exclusivas daquela execução. Esses segredos não podem ser exfiltrados e reutilizados fora do contexto criptograficamente autenticado.
Além disso, as atestações de proveniência publicadas pela CLI do npm permitem auditoria de build: consumidores podem verificar que o pacote veio do repositório esperado, foi construído por um workflow autorizado e não sofreu alterações fora do pipeline. Isso atende melhores práticas de cadeia de suprimentos (como SLSA e recomendações da OpenSSF).
“Seus usuários podem verificar onde e como seu pacote foi construído, aumentando a confiança na sua cadeia de suprimentos.”
GitHub (changelog de julho/2025)
Impacto para devs e empresas: passos práticos de migração
- Habilite 2FA baseada em FIDO no npm/GitHub para todos os publicadores.
- Revogue tokens clássicos e substitua por tokens granulares com escopo mínimo.
- Adote trusted publishing nos pipelines (GitHub Actions e outros provedores elegíveis).
- Bloqueie publicações de pacotes sem 2FA ou sem atestações de proveniência.
- Implemente varredura de segredos em repositórios e em imagens/ambientes de CI.
- Monitore dependências e eventos de conta; ative alertas de publicação suspeita.
Caso fezbox: QR code usado para roubar credenciais
Paralelamente, a Socket identificou o pacote malicioso fezbox, removido do npm, com 476 downloads desde 21 de agosto de 2025. O pacote se apresentava como utilitário JavaScript, mas trazia código furtivo que baixava um QR code de um servidor remoto, o decodificava e executava o payload JavaScript embutido no QR.
O payload tentava ler document.cookie, extrair usuário e senha de cookies e exfiltrar para um endpoint externo (my-nest-app-production>.up.railway[.]app) via POST HTTPS. Embora muitas aplicações não armazenem senhas em cookies, a técnica demonstra sofisticação na ofuscação e a necessidade de ferramentas dedicadas para inspecionar dependências.
“O uso de um QR code para ofuscação adicional é um toque criativo do agente de ameaça, reforçando a importância de checar dependências.”
Olivia Brown, pesquisadora na Socket
Panorama mais amplo: NuGet e RubyGems seguem na mesma direção
As mudanças no npm chegam dias após o repositório NuGet, do ecossistema .NET, adicionar suporte a trusted publishing e a Ruby Central anunciar medidas para reforçar a governança do RubyGems.org, limitando permissões administrativas a engenheiros da organização enquanto novas políticas de acesso são finalizadas. O movimento reflete uma tendência transversal de encurtar credenciais e elevar a verificação de origem nos principais registries.
Validação, fontes e transparência
- Anúncio do GitHub sobre o plano para uma cadeia npm mais segura: github.blog
- Trusted publishing (geralmente disponível): changelog 31/07/2025
- Tokens granulares do npm: docs.npmjs.com
- OpenSSF Trusted Publishers: repos.openssf.org
- Relato do ataque Shai-Hulud e worm autorreplicante: The Hacker News
- Análise do pacote fezbox (Socket): socket.dev
O que é trusted publishing no npm?
Resposta direta: publicação autenticada via OIDC e credenciais efêmeras. — Expansão: o CI/CD emite um token OIDC por workflow; o npm valida a identidade e concede credenciais de curta duração, sem armazenar tokens. A CLI publica atestações de proveniência. — Validação: veja GitHub changelog 31/07/2025 e OpenSSF Trusted Publishers.
Tokens granulares expiram em quanto tempo?
Resposta direta: por padrão, em até 7 dias. — Expansão: os tokens granulares de publicação passam a ter validade curta, reduzindo a janela de ataque caso sejam exfiltrados. Escopos mínimos são recomendados. — Validação: documentação oficial do npm sobre granular access tokens.
Como migrar de TOTP para 2FA baseada em FIDO?
Resposta direta: habilite chaves de segurança FIDO/U2F no GitHub/npm. — Expansão: registre uma chave física ou integrada (plataforma) e defina-a como método principal de 2FA; remova dependência de TOTP para publicação. Atualize políticas internas. — Validação: docs do GitHub sobre 2FA e anúncios de depreciação de TOTP no npm.
Ainda posso publicar localmente sem 2FA?
Resposta direta: não, o bypass será removido. — Expansão: publicações locais exigirão 2FA; por padrão, tokens com permissão de publish ficam desabilitados, favorecendo trusted publishing via CI/CD. — Validação: plano oficial do GitHub para tornar o npm mais seguro.
Fui afetado por Shai-Hulud/fezbox. O que fazer?
Resposta direta: revogue segredos e audite artefatos. — Expansão: invalide tokens, gire chaves, reinstale dependências, recompile versões, verifique commits/CI e publique releases com atestações. Notifique usuários e monitore IOC. — Validação: comunicados do GitHub e análise da Socket sobre fezbox.
Considerações finais sobre GitHub vai exigir 2FA e tokens curtos
Ao adotar 2FA baseada em FIDO, tokens granulares de curta duração e trusted publishing com OIDC, o GitHub eleva o patamar de segurança do npm contra abuso de credenciais e malware de cadeia de suprimentos. Para equipes de engenharia, o recado é claro: rotacione tokens, migre para fluxos com atestações e implemente verificação contínua de dependências. O momento é propício para transformar boas práticas em padrão operacional, reduzindo riscos e fortalecendo a confiança no ecossistema JavaScript.
