FlawOpen

flawopen.com/Teardowns/cve-2026-105750-docling-html-render-local-file-disclosure

● CVE-2026-105750 · CVSS 5.9 · Média
Pesquisa · FlawOpen

CVE-2026-105750: Divulgação de arquivo local no renderizador HTML do Docling

Versões do Docling anteriores à 2.118.1 podem divulgar arquivos de texto locais quando código Python renderiza HTML não confiável de um filesystem Path com render_page=True e Playwright instalado. O caminho do navegador não aplicava enable_local_fetch nem limitava o acesso ao diretório do documento. Atualize para 2.118.1 ou posterior.

💡 Explicação em Linguagem Simples (ELI5)

Pense no conversor como alguém que fotografa uma página aberta no navegador. Uma configuração dizia “não busque arquivos locais”, mas um caminho de renderização liberava essas requisições mesmo assim. Se a página enviada fizesse o navegador mostrar um arquivo que o conversor podia ler, o texto visível poderia aparecer na imagem do documento retornado. A correção verifica a configuração e mantém os arquivos locais permitidos dentro do diretório do documento de origem.

Conceitos Centrais e Termos

Docling HTML backend
Componente do Docling que interpreta HTML e pode renderizar a página em um navegador sem interface para capturar sua apresentação visual.
HTMLBackendOptions(render_page=True)
Opção da API Python que ativa o caminho de renderização em navegador. Ela vem desativada por padrão.
enable_local_fetch
Opção de política que controla se arquivos locais podem ser buscados como recursos do documento. Cada backend deve aplicá-la a todas as requisições de recursos.
Playwright
Dependência opcional de automação de navegador usada pela renderização de páginas HTML do Docling.
Path input
Arquivo de origem fornecido como caminho do sistema de arquivos. Diferentemente de um stream, ele dá ao fluxo do navegador uma origem file URL.
CWE-863
Incorrect Authorization: o filtro de requisições do modo de renderização não aplicava a política configurada para acesso a arquivos locais.

Mapeamentos de frameworks

  • Referência CWE para a fraqueza descrita neste guia: CWE-863

Análise de Causa Raiz

Nas versões afetadas em modo de renderização, HTMLDocumentBackend._get_browser_request_block_reason() permitia URLs file: antes de verificar enable_local_fetch ou restringir o caminho resolvido ao diretório do documento de origem. Para Docling 2.82.0–2.90.x, o aviso informa que o modo de renderização nem sequer filtrava as requisições. A fronteira vulnerável é a política de requisições de recursos do navegador, não a interpretação geral de HTML nem toda implantação do Docling. O aviso GitHub classifica a causa como CWE-863 e também lista CWE-552 para o impacto de divulgação; esta página usa CWE-863 como mapeamento primário da causa.

Fluxo de Ataque Passo a Paso

Passo 1

A aplicação ativa a renderização HTML opcional

A implantação vulnerável usa a API Python com HTMLBackendOptions(render_page=True) e tem Playwright instalado. A configuração padrão, a CLI Docling e docling-serve não fazem parte da configuração afetada descrita no aviso.

Passo 2

A aplicação fornece HTML como filesystem Path

O aviso limita a entrada afetada a HTML não confiável fornecido como Path. Entradas em stream usam page.set_content() com origem opaca e não são afetadas por esse caminho de sub-recurso file.

Passo 3

O navegador sem interface solicita um recurso local

O HTML pode fazer a renderização solicitar sub-recursos. O callback de requisições vulnerável permitia file: sem aplicar a autorização de busca local; mesmo com a opção habilitada, não restringia o recurso ao diretório de origem, como fazia o caminho sem renderização.

Passo 4

Texto legível pode aparecer na imagem renderizada

O impacto divulgado limita-se ao texto que um arquivo local exibe na área visível do navegador. O JavaScript está desativado no navegador desde Docling 2.91.0; não generalize a falha como execução arbitrária de código ou leitura de bytes invisíveis.

Passo 5

O filtro corrigido restaura os dois controles

Docling 2.118.1 permite carregar o próprio documento de origem, bloqueia outras requisições file salvo quando enable_local_fetch está ativo e limita os sub-recursos locais permitidos ao diretório do documento.

Código-Fonte: Vulnerável vs. Seguro

O trecho vulnerável mostra a regra que permitia file: sem condição, conforme documentado pelo aviso dos mantenedores; não é um arquivo-fonte completo. O trecho corrigido segue o commit upstream 1612b88: permite o HTML de origem, exige enable_local_fetch para outros arquivos locais, resolve o caminho solicitado e exige que ele permaneça dentro do diretório do documento. Atualize para 2.118.1 ou posterior em vez de copiar este trecho focado. O tratamento separado de data:, about: e blob: não faz parte da regra de arquivos locais.

Trecho de origem: docling/backend/html_backend.py — trechos específicos da política de requisições e renderização

IMPLEMENTAÇÃO VULNERÁVEL
# Caminho de renderização afetado: file: era permitido antes das verificações da política de acesso local.
if scheme in {"file", "data", "about", "blob"}:
    return None
PATCH SEGURO E ROBUSTO
def _is_allowed_browser_file_request(self, request_url: str) -> bool:
    local_base_path = self._get_browser_local_base_path()
    if local_base_path is not None and request_url == local_base_path.as_uri():
        return True  # The source document itself must remain loadable.

    if not self.options.enable_local_fetch or local_base_path is None:
        return False

    requested_path = Path(url2pathname(urlparse(request_url).path)).resolve()
    return requested_path.is_relative_to(local_base_path.parent)

# Em _get_browser_request_block_reason():
if scheme == "file":
    if self._is_allowed_browser_file_request(request_url):
        return None
    # Caso contrário, retorne o motivo pelo qual a solicitação foi bloqueada.

Lista de Verificação de Segurança para Engenharia

Fontes