CVE-2026-8161

Prova de conceito da CVE-2026-8161 (Multiparty)

Descrição

[email protected] e versões anteriores são vulneráveis a negação de serviço por meio de uma exceção não capturada.

O parser armazena campos e arquivos enviados em objetos JavaScript simples e não distingue com segurança as chaves de propriedade do parser das propriedades herdadas do objeto. Um nome de campo multipart malicioso pode fazer com que o parser leia valores inesperados da cadeia de protótipos e trave durante o processamento do upload.

Qualquer serviço que aceite uploads multipart por meio de versões vulneráveis do multiparty pode ser afetado.

Como funciona

O problema ocorre porque fields e files são objetos JavaScript simples, mas são usados como mapas seguros de chave-valor para nomes controlados pelo usuário.

var fieldsArray = fields[name] || (fields[name] = [])
fieldsArray.push(value)

var filesArray = files[name] || (files[name] = [])
filesArray.push(file)

O problema é que fields[name] e files[name] usam a busca normal de propriedades do JavaScript. Para objetos simples, essa busca pode retornar propriedades herdadas da cadeia de protótipos em vez de apenas valores armazenados no próprio objeto.

Quando o nome é __proto__, o JavaScript pode resolvê-lo por meio da cadeia de protótipos e retornar o objeto de protótipo herdado em vez de undefined. Como esse valor é truthy, a atribuição de fallback é ignorada e o parser nunca cria um array real para esse campo.

O patch corrige isso confiando apenas em chaves que pertencem diretamente ao objeto:

var filesArray = Object.prototype.hasOwnProperty.call(files, name)
  ? files[name]
  : undefined

Em seguida, o parser anexa apenas quando o valor armazenado é realmente um array; caso contrário, inicializa um novo:

if (Array.isArray(filesArray)) {
  filesArray.push(file)
} else {
  files[name] = [file]
}

Quando .push() é chamado em um valor que não é um array, ele lança um TypeError. Como isso ocorre dentro do fluxo de análise assíncrona do Multiparty, o tratamento de erros normal do lado do chamador pode não capturá-lo, permitindo que a exceção trave o processo.

Linha do tempo

• 2026-01-12: Vulnerabilidade relatada aos mantenedores do multiparty.
• 2026-01-17: Relatório aceito, o trabalho de correção começou.
• 2026-02-14: Revisão coordenada iniciada com @pillarjs/security-triage.
• 2026-02-16: Discussões sobre o patch -> Object.prototype.hasOwnProperty.call(...).
• 2026-03-29: Título e metadados do aviso atualizados para refletir o impacto de negação de serviço.
• 2026-04: Abordagem de correção revisada e aprovada.
• 2026-05-08: Aviso finalizado e CVE-2026-8161 reservada.
• 2026-05-11: Correção mesclada em pillarjs:master.

Uso da Demonstração

Execute o ambiente mocklab e envie o payload de teste para ambos os alvos:

docker compose up -d
python3 secdos.py -u http://localhost:8080/api/submit
python3 secdos.py -u http://localhost:8081/api/submit

O alvo vulnerável travará e retornará [PASS]. O alvo corrigido lidará com a solicitação com segurança e retornará [FAIL].

Se for executar novamente contra o servidor vulnerável, reinicie-o primeiro

Visão Geral da Configuração

Servidor Vulnerável

• Acesso em localhost:8080
• Servidor Nginx atuando como proxy reverso; em caso de falha, exibe página de erro com status 502
• O Nginx resolve o endereço do servidor vulnerável pelo nome do serviço
• Usa multiparty 4.2.3 (vulnerável)

Servidor Corrigido

• Executando e acessado em localhost:8081
• Nginx não é necessário
• Usa multiparty 4.3.0 (corrigido)

A construção de uma imagem corrigida a partir do dockerfile requer um argumento de build PATCHED=1

Referências

https://github.com/pillarjs/multiparty/security/advisories/GHSA-qxch-whhj-8956 https://github.com/pillarjs/multiparty/commit/8ee6aca09aca29e923da48da8260c87aa964b282