Vazou token do npm e senha no GitHub: como escolher o que roda em Node.js

Uma investigação da empresa de segurança Apiiro encontrou 1.379 credenciais distintas em arquivos públicos do GitHub, entre senhas de bancos de dados de produção, chaves de nuvem e tokens de publicação. O achado, divulgado em 9 de novembro de 2026, não veio de uma invasão: os segredos estavam em arquivos de configuração que ferramentas de programação gravaram durante o trabalho normal de uma equipe. Na mesma semana, a iMasters publicou uma auditoria do pacote chalk-template segundo a qual um npm token comprometido teria permitido publicar versões maliciosas do pacote, usado por milhares de projetos JavaScript.

A leitura da Wortic: a pergunta deixou de ser se o time usa a linguagem e o gerenciador de pacotes da moda. Passou a ser quanto da infraestrutura depende de arquivos e credenciais que ninguém revisa. Para quem decide tecnologia, isso muda o critério de escolha de qualquer biblioteca que vai rodar em produção com Node.js.

O que muda na prática para quem decide

Uma biblioteca instalada por npm install hoje carrega, em geral, três riscos ao mesmo tempo: o código que ela baixa na instalação, a credencial que o processo precisa para publicar uma versão nova e o servidor em que esse processo roda. Quando um token de publicação vaza, o risco vira a possibilidade de alguém publicar em nome do mantenedor, sem tocar no código-fonte do projeto.

Há também o problema do ambiente. A falha CVE-2026-111497, corrigida pelo Node.js em outubro de 2026, foi um erro de escrita fora dos limites de memória no decodificador Brotli, componente escrito em C e usado por aplicações que recebem conteúdo comprimido. A correção chegou nas linhas 22, 24 e 26, e a linha 20 já estava fora do suporte, segundo a reportagem do SempreUpdate de 22 de outubro de 2026. Quem mantém o runtime atualizado ficou de fora; quem ficou parado continuou exposto.

Para o dono da operação, a consequência é direta. Um incidente de cadeia de suprimentos não derruba só o site do fornecedor da biblioteca: ele entra no ambiente de quem instalou o pacote, com as permissões que aquele processo tinha, geralmente de produção.

Como resolver, passo a passo

1. Saiba o que está instalado. Gere a lista completa de dependências com npm ls --all e guarde o resultado a cada versão que entra em produção. Sem essa lista, não existe auditoria.

2. Trate token de publicação como senha. Token do npm é credencial de escrita no registro. A consulta das versões de um pacote é pública e não pede autenticação; a publicação de uma versão nova pede. Se o token não for necessário no dia a dia da máquina de build, ele não deve estar lá.

3. Prefira código que não baixa mais código na instalação. Um pacote com zero dependências não traz um segundo instalador dentro dele. O custo de auditoria cai, porque não há árvore de terceiros para seguir.

4. Meça o custo de executar o runtime. Disco, memória e servidor crescem junto com a quantidade de bibliotecas carregadas. Antes de adicionar mais uma camada ao processo, vale medir quanto ele já consome e quanto cresceu em seis meses.

5. Mantenha o runtime na versão suportada. Aprendizado da CVE-2026-111497: atualizar o Node.js é a correção. Não existe ajuste de configuração que substitua a versão corrigida.

6. Separe o dado da ferramenta. Guarde os dados em formatos que qualquer leitor consiga abrir, com integridade verificável, para que trocar de biblioteca não vire migração de emergência.

Como o jsonW ajuda no que roda em Node.js

O jsonW é o formato de dados da Wortic, com três formas que se convertem sem perda: linha, coluna (o arquivo .jsw) e texto. Para a equipe que roda em Node.js, ele chega pelo npm como um pacote com núcleo em C de zero dependências:

npm install @wortictecnologia/jsonw

O pacote traz o addon N-API pré-compilado para macOS arm64 e Linux x64 (glibc 2.34 ou mais novo), a tipagem em TypeScript no index.d.ts e o comando jsonw, que é a ferramenta wjsw. No código, dois objetos com nomes iguais em todas as linguagens:

const { Leitor, Escritor } = require("@wortictecnologia/jsonw");

const w = new Escritor("vendas.jsw", "id:i64,produto:texto,preco:dinheiro,peso:medida[g],sku:codigo");
w.gravar({ id: 1, produto: "Café especial", preco: "12,50 BRL", peso: "250 g", sku: "CAF-0250" });
w.gravar({ id: 2, produto: "Pão de queijo", preco: "8,90 BRL", peso: "1 kg", sku: "PDQ-1000" });
w.fechar();

const r = new Leitor("vendas.jsw");
console.log(r.campo(1, "peso"));
r.conferir();
r.fechar();

Três coisas acontecem nesse trecho. O 1 kg entra na coluna medida[g] e é gravado como 1000 g. O preço guarda a moeda (12,50 BRL) sem passar por ponto flutuante. O SKU é guardado byte a byte. Depois, r.campo(1, "peso") lê um campo de uma linha sem decodificar o resto do arquivo, e r.conferir() verifica a custódia: crc32c e SHA-256 em cadeia, apontando se algum byte mudou.

flowchart LR
    N["Aplicação Node.js"] --> R["new Leitor(vendas.jsw)"]
    R --> F[["arquivo .jsw em blocos"]]
    R --> V["só o bloco e a coluna pedidos"]
    V --> D["valor com o tipo de negócio"]
    R --> C["cadeia crc32c + SHA-256"]
    C -->> OK["ok: linhas e blocos conferidos"]
    E["Escritor"] --> T["arquivo só aparece completo, troca atômica"]

O ganho que o próprio projeto publica: 4,9 vezes menos espaço que o mesmo conjunto em JSONL e leitura de um campo 3.281 vezes mais rápida, nas duas medições com 100 mil registros, contra o leitor de JSON do próprio projeto, conforme o README. O README também avisa que bibliotecas de JSON mais otimizadas reduzem a diferença na leitura completa, e que o acesso direto é o que vem do formato em colunas. Não há no README número de memória, de CPU ou de custo de servidor medido para o Node.js. Quem precisa decidir com número próprio pode rodar wjsw medir na máquina da equipe.

Sobre liberdade funcional: o arquivo é um só, legível por SDK em dez linguagens, com permissão por coluna, linha e célula declarada no esquema (cpf:codigo?+pessoal, valor:dinheiro+escopo(financeiro)). A visão é aplicada antes da resposta, então a coluna escondida sai nula em vez de sair no JSON. Detalhes em jsonw.org e no repositório.

Três situações do dia a dia

Cenário 1: auditoria pede a lista de dependências. O time roda npm ls --all, descobre 340 pacotes e não sabe qual deles precisa de token de publicação. O que fazer: separar o que é ferramenta de build do que é biblioteca do produto, revogar tokens que não são usados na máquina de build e documentar quem pode publicar. Resultado esperado: menos credenciais ativas e uma lista curta de pontos de publicação para revisar.

Cenário 2: a área de dados reclama de lentidão no relatório. O processo lê o arquivo inteiro em memória para pegar uma coluna. O que fazer: transformar o JSONL em .jsw e trocar a leitura completa por campo(i, "coluna"), medindo antes e depois na máquina de produção. Resultado esperado: identificar se o tempo está na leitura ou em outra etapa, com número próprio em vez de estimativa.

Cenário 3: sai a versão corrigida do runtime. O Node.js publicou patch de segurança e a equipe tem três serviços em linhas diferentes. O que fazer: mapear a versão de cada serviço, priorizar quem aceita conteúdo comprimido de fora e planejar a saída das linhas fora de suporte. Resultado esperado: nenhum serviço exposto à falha corrigida, com data de atualização registrada.

Perguntas que aparecem na busca

O jsonW para Node.js tem dependências?

Não. Segundo o README do pacote, o núcleo é em C, sem dependência, e o npm entrega o addon N-API já compilado, sem etapa de compilação na instalação. Isso reduz o que precisa ser auditado em cada npm install.

Quais plataformas o pacote do npm atende?

Segundo o README do pacote, macOS arm64 e Linux x64 com glibc 2.34 ou mais novo, como Ubuntu 22.04 ou posterior, Debian 12 e RHEL 9. O comando jsonw também acompanha a versão para Windows x64. O pacote declara engines com Node.js 18 ou mais novo.

Preciso trocar de banco de dados para usar?

Não. O jsonW não pede troca de banco: a ferramenta wcon leva dados de PostgreSQL, MySQL, MariaDB, SQLite, Redis e MongoDB para um arquivo .jsw e devolve para o banco em uma transação, com o esquema tirado do tipo de cada coluna.

Como conferir se o arquivo não foi alterado?

Com r.conferir() no Node.js, ou wjsw conferir arquivo.jsw na linha de comando. A resposta é do tipo ok: N linhas, B blocos, sha256 e crc32c conferidos. A custódia é uma cadeia de resumos: qualquer byte trocado falha na conferência.

O JSONL que já existe pode ser convertido?

Sim. wjsw de-texto "esquema" vendas.jsonl vendas.jsw lê JSON ou JSONL e grava o arquivo em colunas, e wjsw para-texto arquivo.jsw --json devolve o JSON sem perda. Quando o esquema já se conhece, é melhor declará-lo do que inferir.

Serve para busca por significado em dados de vendas?

O formato tem busca por significado por cosseno sobre vetores densos, nota por pedido e as k melhores por heap. No SDK de Node.js isso aparece em r.avaliar({ pesos: { preco: -1 } }, 10), que devolve as linhas e as notas, da maior para a menor.

O que muda para quem já faz segurança de dependências?

A lista de verificação continua valendo: versão atualizada do runtime, menos dependências, token de publicação revogado quando não é necessário e auditoria de quem publica. O que muda é o volume: com zero dependências no pacote, sobra menos árvore para auditar a cada instalação.

Fontes

• SempreUpdate, 09/11/2026, Claude Code expõe senhas no GitHub (investigação da Apiiro): https://sempreupdate.com.br/claude-code-expoe-senhas-chaves-github/
• SempreUpdate, 22/10/2026, Atualização de segurança no Node.js corrige falha RCE no Brotli: https://sempreupdate.com.br/atualizacao-seguranca-node-js-brotli-rce/
• iMasters, 09/11/2026, auditoria do pacote chalk-template e o npm token comprometido: https://imasters.com.br/
• Repositório do jsonW, README, AGENTS.md, docs/JSONW.md e sdk/README.md lidos em 10/11/2026: https://github.com/developer-wortic/jsonw
• Pacote publicado no npm, versão 1.2.0, metadados do registro lidos em 10/11/2026: https://www.npmjs.com/package/@wortictecnologia/jsonw
• Site oficial do jsonW: https://jsonw.org
• Registro de versões do Node.js, lido em 10/11/2026: https://nodejs.org/dist/index.json

Perguntas frequentes

O que aconteceu no vazamento de credenciais do GitHub divulgado em novembro?

A empresa de segurança Apiiro encontrou 1.379 credenciais distintas em arquivos públicos do GitHub, incluindo senhas de bancos de dados de produção, chaves de nuvem e tokens, segundo a reportagem do SempreUpdate de 9 de novembro de 2026. Os segredos estavam em arquivos de configuração gravados por ferramentas de programação.

Um npm token comprometido permite publicar versão maliciosa de um pacote?

É o risco descrito na auditoria do pacote chalk-template citada pela iMasters em 9 de novembro de 2026. O token é credencial de publicação no registro: quem tem o token pode publicar uma versão nova em nome do mantenedor, sem alterar o código-fonte do projeto.

O jsonW precisa de dependências no Node.js?

Não. Segundo o README do pacote, o núcleo é em C sem dependência e o npm entrega o addon N-API pré-compilado para macOS arm64 e Linux x64, com tipagem em TypeScript e o comando jsonw, que é a ferramenta wjsw.

Como instalar o jsonW em Node.js?

Com npm install @wortictecnologia/jsonw. No código, const { Leitor, Escritor } = require("@wortictecnologia/jsonw"). O pacote declara engines com Node.js 18 ou mais novo, e a versão 1.2.0 é a publicada no registro do npm.

Como gravar um arquivo jsonW com tipos de negócio?

O Escritor recebe um esquema de uma linha, como id:i64,produto:texto,preco:dinheiro,peso:medida[g],sku:codigo. Um peso de 1 kg entra em medida[g] e é gravado como 1000 g, e o preço guarda a moeda, no exemplo 12,50 BRL.

Como ler um campo sem carregar o arquivo inteiro?

Com r.campo(linha, "nome") no SDK de Node.js, que faz acesso direto ao campo sem decodificar o resto do arquivo. O README do projeto informa 4,9 vezes menos espaço que o JSONL e leitura de um campo 3.281 vezes mais rápida, em medição com 100 mil registros.

O jsonW substitui o banco de dados da empresa?

Não. A Wortic descreve o jsonW como formato de dados que conversa com o banco que já existe: a ferramenta wcon exporta de PostgreSQL, MySQL, MariaDB, SQLite, Redis e MongoDB para o arquivo .jsw e devolve para o banco, com ida e volta sem perda.

Fontes

• SempreUpdate: Claude Code expõe senhas no GitHub (investigação da Apiiro)
• SempreUpdate: Atualização de segurança no Node.js corrige falha RCE no Brotli
• iMasters: auditoria do pacote chalk-template e o npm token comprometido
• Repositório do jsonW (README, AGENTS.md, docs/JSONW.md, sdk/README.md)
• Pacote @wortictecnologia/jsonw no npm
• Site oficial do jsonW
• Registro de versões do Node.js

Conheça: jsonW em Node.js pelo npm.