CVE-2026-38361: Múltiplas Vulnerabilidades de DoS Não Autenticadas em dash-uploader

Múltiplos problemas de Negação de Serviço (DoS) não autenticados em fohrloop/dash-uploader (Python, PyPI), incluindo (mas não se limitando a) queda do processo por falta de memória (OOM), truncamento de arquivos para zero bytes, esgotamento permanente de disco e contorno completo do limite documentado de max_file_size. Caminhos adicionais de abuso de recursos existem através do mesmo conjunto de parâmetros não sanitizados.

⚠️ Não há patch disponível, e nenhum será lançado

O repositório foi arquivado em 2025-07-19 sem mantenedor ativo. Todas as versões publicadas (0.1.0 até 0.7.0a2) são afetadas e continuarão sendo. O pacote ainda registra cerca de 28.000 downloads mensais.

Qualquer pessoa que execute o dash-uploader em produção deve aplicar uma mitigação por conta própria. A correção recomendada é migrar para o componente dcc.Upload embutido no Plotly Dash. Consulte Mitigação para conhecer todas as opções.

CVE ID	CVE-2026-38361 (NVD)
Vulnerabilidade	Consumo Descontrolado de Recursos (CWE-400), Implementação de Fluxo de Controle Sempre Incorreta (CWE-670)
CVSS 3.1	7.5 / Alta (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Produto	dash-uploader
Versões afetadas	0.1.0 até 0.7.0a2 (todas as 18 versões)
Versão corrigida	nenhuma (projeto arquivado em 2025-07-19)
Vetor de ataque	Remoto, não autenticado
Descobridor	Muhammad Fitri Bin Mohd Sultan
Atribuído por	MITRE, 2026-05-07
Relacionado	CVE-2026-38360 (travessia de caminho na mesma biblioteca)

Descrição

O manipulador HTTP do dash-uploader aceita requisições POST não autenticadas com parâmetros controlados pelo atacante que fluem para alocação de memória, operações de arquivo e criação de diretórios, sem verificações de limites, sem limites de taxa e sem mecanismo de limpeza. Quatro problemas independentes no mesmo caminho de código:

1. Crash por OOM (verificado)

Verificado em um sistema com 7,7 GB: 5 requisições POST simultâneas com resumableTotalChunks=30000000 acionaram o OOM killer do Linux em 2 segundos. O log do kernel confirma:

Out of memory: Killed process 24203 (python3) total-vm:8302276kB, anon-rss:7068012kB

Cada requisição aloca aproximadamente 2,9 GB por meio de uma list comprehension sobre range(1, resumableTotalChunks + 1). O processo do servidor é encerrado e a aplicação fica completamente indisponível até reinicialização manual.

2. Truncamento de arquivo (verificado)

Um arquivo contendo 42 bytes de dados foi reduzido a 0 bytes por meio de uma única requisição POST com resumableTotalChunks=0. A causa raiz é o all() do Python retornar True para iteráveis vazios, o que engana o manipulador de upload fazendo-o tratar zero partes como um upload concluído. O arquivo existente é excluído via os.unlink() e substituído por um arquivo vazio.

3. Acúmulo de uploads abandonados (verificado)

10 diretórios temporários órfãos com arquivos de partes foram criados e persistidos indefinidamente no disco. Uma busca em todo o código-fonte por cleanup, ttl, expire, garbage, purge, cron, schedule e periodic retornou zero resultados. A única chamada de limpeza (shutil.rmtree) é executada exclusivamente em uploads concluídos. Não há mecanismo para recuperar espaço em disco de sessões incompletas.

4. Contorno do max_file_size (verificado)

O servidor aceitou uma parte de 5 MB para um arquivo declarando resumableTotalSize=999999999999 (~999 GB) com HTTP 200. O parâmetro max_file_size é passado apenas para o componente React JavaScript. O servidor nunca verifica o tamanho do arquivo, o tamanho da parte, o Content-Length ou o MAX_CONTENT_LENGTH do Flask. Um desenvolvedor que defina max_file_size=10 não tem proteção no lado do servidor.

Código vulnerável

# dash_uploader/httprequesthandler.py
def _post(self):
    resumableTotalChunks = request.form.get("resumableTotalChunks", type=int)   # attacker-controlled, no bounds
    ...
    chunk_paths = [
        os.path.join(temp_dir, get_chunk_name(resumableFilename, x))
        for x in range(1, resumableTotalChunks + 1)                              # unbounded; e.g. 30M -> ~2.9 GB -> OOM
    ]
    upload_complete = all([os.path.exists(p) for p in chunk_paths])              # all([]) is True -> truncation when chunks=0
    if upload_complete:
        target_file_name = os.path.join(temp_root, resumableFilename)
        if os.path.exists(target_file_name):
            os.unlink(target_file_name)                                          # existing file deleted
        with open(target_file_name, "ab") as target_file:
            for p in chunk_paths:                                                # empty list -> empty file written
                ...

O mesmo caminho de código produz tanto o OOM (resumableTotalChunks grande) quanto a primitiva de truncamento de arquivo (resumableTotalChunks=0).

Vetores de ataque

Um atacante envia requisições POST não autenticadas para o endpoint /API/resumable.

• Crash por OOM: 5 requisições simultâneas com resumableTotalChunks=30000000 alocam ~2,9 GB cada, acionando o OOM killer.
• Esgotamento de disco: iniciar uploads mas nunca concluí-los; arquivos temporários órfãos se acumulam para sempre.
• Truncamento de arquivo: enviar resumableTotalChunks=0; o all([])=True do Python engana o servidor fazendo-o sobrescrever o arquivo alvo com conteúdo vazio.
• Contorno de limite de tamanho: qualquer limite de tamanho definido pelo desenvolvedor é aplicado apenas no JavaScript do cliente, portanto uma requisição HTTP direta o contorna completamente.

Nenhuma autenticação ou privilégio é necessário.

Impacto