Falha no binary-parser permite execução de JavaScript com privilégios do processo Node.js

A vulnerabilidade CVE-2026-1245 afeta versões anteriores à 2.3.0 da biblioteca binary-parser e expõe aplicações que constroem definições de parser a partir de entrada não confiável.

Componente	Biblioteca binary-parser para Node.js, distribuída pelo npm, usada para construir parsers de dados binários em JavaScript.
Vetor	Construção dinâmica de definições de parser com valores controlados por usuário em nomes de campos ou parâmetros de codificação.
Impacto	Execução de JavaScript arbitrário com os privilégios do processo Node.js quando a aplicação compila lógica de parsing vulnerável em tempo de execução.
Prioridade	Atualizar para binary-parser 2.3.0 e impedir que valores controlados por usuário sejam usados em nomes de campos ou parâmetros de codificação.
Versões	Todas as versões anteriores à 2.3.0 são afetadas; a correção foi disponibilizada em 26 de novembro de 2025.
Identificador	CVE-2026-1245, com pontuação CVSS 6.5.

Resumo técnico

A vulnerabilidade CVE-2026-1245 atinge a biblioteca binary-parser, um pacote npm usado por aplicações JavaScript para descrever e processar estruturas binárias. O problema não está no ato de ler bytes em si, mas no modo como a biblioteca transforma definições de parser em código JavaScript executável. Em cenários vulneráveis, valores fornecidos por uma fonte não confiável podem alcançar a geração dinâmica de código sem sanitização adequada, permitindo que instruções JavaScript sejam incorporadas à função compilada em tempo de execução.

O impacto confirmado é a execução de JavaScript arbitrário com o mesmo nível de privilégio do processo Node.js que hospeda a aplicação. Dependendo de como o serviço foi implantado, isso pode permitir leitura de dados locais acessíveis ao processo, alteração da lógica da aplicação ou execução de comandos do sistema. Esse impacto depende diretamente das permissões do processo, do isolamento do ambiente, dos recursos expostos ao serviço e do caminho pelo qual a aplicação aceita ou monta definições de parser.

A falha afeta versões anteriores à 2.3.0. A correção foi publicada em 26 de novembro de 2025, e a análise complementar divulgada em janeiro de 2026 identificou o comportamento como uma consequência da interpolação insegura de nomes de variáveis e parâmetros de codificação em código gerado dinamicamente. O pesquisador Maor Caplan, da Alma Security, recebeu crédito pela descoberta e pelo reporte. O caso recebeu o nome de ParserPoison na análise técnica complementar.

Aplicações que usam apenas definições estáticas e codificadas diretamente no código, sem aceitar nomes de campos, esquemas ou parâmetros de codificação vindos de usuários, não são descritas como afetadas pela falha. A condição crítica é a existência de um caminho em que entrada externa influencia a definição do parser. Por isso, a investigação defensiva deve separar o uso normal da biblioteca, com esquemas controlados pelo desenvolvedor, dos fluxos em que a aplicação monta parsers sob demanda a partir de requisições, arquivos, metadados, configurações importadas ou outros dados não confiáveis.

Fluxo técnico

A biblioteca binary-parser oferece uma forma declarativa de descrever como buffers binários devem ser interpretados. Ela suporta tipos comuns, como inteiros, valores de ponto flutuante, strings e arrays. Para obter desempenho, a biblioteca monta uma representação em JavaScript da lógica de parsing, compila essa representação com o construtor Function e mantém a função resultante em cache para processar buffers de maneira eficiente. Esse desenho aproxima a execução de um padrão de compilação dinâmica: a definição do parser vira código e o código resultante passa a rodar dentro do processo da aplicação.

O risco surge quando partes dessa definição não são tratadas como dados, mas acabam inseridas no texto do código gerado. Nomes de campos e parâmetros de codificação são exemplos citados como entradas que podiam chegar ao código sem validação suficiente nas versões afetadas. Se a aplicação permite que um usuário, cliente, parceiro ou arquivo externo controle esses valores, o limite entre configuração e código é quebrado. A entrada deixa de ser apenas uma descrição do formato binário e passa a poder alterar a função que será compilada.

A exploração não é descrita como universal para qualquer uso da biblioteca. O pacote vulnerável precisa estar em uma aplicação que constrói definições de parser a partir de entrada não confiável. Um serviço que define os parsers no próprio código, sem aceitar nomes de campos ou codificações de origem externa, não atende à pré-condição principal. Já sistemas que recebem esquemas dinâmicos, permitem upload de descritores, importam formatos personalizados ou convertem metadados externos em definições de binary-parser devem ser considerados expostos até que o fluxo seja auditado.

A classe da falha é especialmente sensível em ambientes Node.js porque o código gerado executa no mesmo contexto de privilégio do processo. Não há indicação, no material analisado, de exploração ativa, campanha associada ou artefatos de ataque publicados como operação em andamento. A prioridade técnica, portanto, é reduzir a superfície em que dados externos influenciam geração de código, aplicar a versão corrigida e revisar a arquitetura de parsing para que nomes, parâmetros e esquemas sejam validados antes de qualquer compilação dinâmica.

Superfície afetada

A superfície afetada inclui aplicações Node.js que dependem do pacote binary-parser em versões anteriores à 2.3.0 e usam definições de parser montadas dinamicamente. O volume de adoção do pacote, descrito em aproximadamente 13 mil downloads semanais, torna importante procurar usos transitivos em projetos, serviços internos e ferramentas de processamento de arquivos binários. Mesmo quando o pacote não aparece no código de negócio, ele pode estar presente em dependências de bibliotecas que fazem parsing de formatos específicos.

A avaliação deve priorizar caminhos em que uma requisição, arquivo enviado, configuração importada, perfil de cliente ou metadado externo influencia nomes de campos do parser ou parâmetros de codificação. O risco é maior quando o serviço roda com permissões amplas, acesso a arquivos locais sensíveis, variáveis de ambiente relevantes, credenciais de serviço ou capacidade de iniciar processos do sistema. A correção no pacote reduz a exposição, mas não substitui a revisão do desenho da aplicação quando a própria arquitetura permite que usuários definam estruturas executadas como lógica de parsing.

• Projetos com binary-parser anterior à versão 2.3.0 devem ser tratados como candidatos à revisão.
• Aplicações com parsers estáticos e definidos apenas pelo desenvolvedor não são descritas como afetadas pela condição de exploração.
• Serviços que aceitam esquemas, nomes de campos ou parâmetros de codificação de origem externa têm maior prioridade de análise.
• Ambientes em que o processo Node.js possui acesso a dados locais ou permissões de sistema aumentam o impacto possível.

Hunting e telemetria

A investigação deve começar no inventário de dependências, verificando arquivos de manifesto e travamento de versões para localizar binary-parser direto ou transitivo. Em seguida, a revisão precisa mapear onde a biblioteca é instanciada e de onde vêm os nomes de campos, parâmetros de codificação e definições de parser. O ponto central não é apenas confirmar a presença do pacote, mas determinar se valores externos chegam à etapa de compilação dinâmica.

Na telemetria de aplicação, sinais relevantes incluem erros de sintaxe inesperados durante criação de parsers, exceções relacionadas a código gerado, falhas associadas ao construtor Function e variações anormais em esquemas enviados por clientes ou arquivos processados. Em endpoint e servidor, a equipe deve correlacionar eventos do processo Node.js com leituras incomuns de arquivos, tentativas de manipulação de lógica da aplicação e criação de processos filhos quando essa atividade não faz parte do comportamento esperado do serviço. Não há indicadores de rede ou hashes confirmados no material analisado; a detecção deve se concentrar no comportamento da aplicação e na origem dos dados que alimentam os parsers.

Também é útil revisar logs de API, filas, armazenamento de objetos e pipelines de ingestão que possam transportar descritores de formato binário. Ambientes que processam dados de múltiplos clientes ou permitem personalização de layout binário devem registrar a origem dos esquemas e aplicar validação antes do uso. Quando a aplicação não mantém logs detalhados dessa etapa, a correção deve incluir aumento de observabilidade defensiva para diferenciar parsing legítimo de tentativas de injetar lógica em campos que deveriam ser apenas identificadores ou parâmetros controlados.

• Presença de binary-parser anterior à 2.3.0 em dependências diretas ou transitivas.
• Definições de parser geradas a partir de requisições, arquivos, metadados, configurações importadas ou entradas de usuário.
• Exceções de compilação dinâmica, erros de sintaxe em parsers ou mensagens incomuns associadas a código gerado.
• Atividade inesperada do processo Node.js, como acesso a arquivos locais ou criação de processos fora do fluxo normal da aplicação.
• Alterações recentes em funcionalidades que permitem formatos binários personalizados ou esquemas definidos por clientes.

Mitigação

A medida principal é atualizar binary-parser para a versão 2.3.0 ou posterior, garantindo que a versão efetivamente carregada em produção corresponda à versão corrigida. A validação deve incluir dependências transitivas, lockfiles, imagens de contêiner, caches de build e artefatos publicados em registries internos. Em ambientes com múltiplos serviços, a atualização precisa ser acompanhada de rebuild e redistribuição, porque apenas alterar o manifesto não remove necessariamente a versão vulnerável dos artefatos já implantados.

Além da atualização, a aplicação deve impedir que valores controlados por usuário sejam usados diretamente como nomes de campos ou parâmetros de codificação. Esses campos precisam ser tratados como dados estritamente validados, com listas permitidas, regras de formato e rejeição de caracteres ou estruturas que não façam sentido para a gramática esperada. Quando o produto exige esquemas configuráveis, a arquitetura deve separar a validação do esquema da geração de código e registrar a origem de cada definição aceita.

A resposta defensiva também deve revisar privilégios do processo Node.js. Como o impacto ocorre com as permissões do processo, reduzir acesso a arquivos, segredos, variáveis de ambiente e execução de comandos diminui o dano em caso de exploração. Serviços que processam dados não confiáveis devem rodar com contas de menor privilégio, isolamento por contêiner ou sandbox quando aplicável, limites de sistema e políticas de saída compatíveis com a função do serviço. Depois da correção, testes de regressão devem cobrir cenários em que entradas externas tentam influenciar nomes de campos e parâmetros, confirmando que a aplicação rejeita valores inválidos antes de qualquer compilação dinâmica.

• Atualizar o pacote para binary-parser 2.3.0 ou posterior em todos os artefatos implantados.
• Auditar dependências transitivas, lockfiles, caches de build e imagens de contêiner para remover versões vulneráveis.
• Bloquear o uso direto de entrada de usuário em nomes de campos e parâmetros de codificação.
• Aplicar validação por lista permitida para esquemas dinâmicos realmente necessários.
• Executar serviços Node.js com menor privilégio e reduzir acesso local que amplifique o impacto.
• Adicionar testes que confirmem a rejeição de definições de parser não confiáveis antes da geração de código.