FlawOpen

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

● CVE-2026-105750 · CVSS 5.9 · Mittel
Sicherheitsforschung · FlawOpen

CVE-2026-105750: Offenlegung lokaler Dateien beim HTML-Rendering in Docling

Docling-Versionen vor 2.118.1 können lokale Textdateien offenlegen, wenn Python-Code nicht vertrauenswürdiges HTML mit render_page=True aus einem filesystem Path rendert und Playwright installiert ist. Der Browserpfad setzte enable_local_fetch nicht durch und beschränkte den Zugriff nicht auf das Dokumentverzeichnis. Aktualisieren Sie auf 2.118.1 oder höher.

💡 Einfache Erklärung (ELI5)

Stellen Sie sich den Konverter als jemanden vor, der eine im Browser geöffnete Seite fotografiert. Eine Einstellung sagte „keine lokalen Dateien laden“, aber ein Rendering-Pfad ließ solche Anfragen trotzdem durch. Wenn die übermittelte Seite den Browser dazu brachte, eine Datei anzuzeigen, die der Konverter lesen durfte, konnte ihr sichtbarer Text im Bild des zurückgegebenen Dokuments landen. Der Fix prüft die Einstellung und beschränkt erlaubte lokale Dateien auf das Verzeichnis des Quelldokuments.

Kernkonzepte & Begriffe

Docling HTML backend
Docling-Komponente, die HTML verarbeitet und die Seite optional in einem Headless-Browser rendert, um die visuelle Darstellung zu erfassen.
HTMLBackendOptions(render_page=True)
Option der Python-API, die den Browser-Rendering-Pfad aktiviert. Standardmäßig ist sie deaktiviert.
enable_local_fetch
Richtlinienoption dafür, ob lokale Dateien als Dokumentressourcen geladen werden dürfen. Jedes Backend muss sie bei jeder Ressourcenanfrage durchsetzen.
Playwright
Optionale Browser-Automatisierungsabhängigkeit für das HTML-Seitenrendering in Docling.
Path input
Quelldatei als Dateisystempfad. Anders als ein Stream gibt sie dem Browserpfad einen file-URL-Ursprung.
CWE-863
Incorrect Authorization: Der Anfragefilter im Rendering-Modus setzte die konfigurierte Richtlinie für den Zugriff auf lokale Dateien nicht durch.

Framework-Zuordnungen

  • CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-863

Ursachenanalyse

In betroffenen Versionen im Rendering-Modus erlaubte HTMLDocumentBackend._get_browser_request_block_reason() file:-URLs, bevor enable_local_fetch geprüft oder der aufgelöste Pfad auf das Verzeichnis des Quelldokuments begrenzt wurde. Für Docling 2.82.0–2.90.x sagt der Hinweis, dass der Rendering-Modus Anfragen überhaupt nicht filterte. Die Schwachstelle liegt in der Browser-Richtlinie für Ressourcenanfragen, nicht in der allgemeinen HTML-Verarbeitung oder jeder Docling-Bereitstellung. Das GitHub-Advisory ordnet die Ursache CWE-863 zu und führt für die Offenlegungswirkung zusätzlich CWE-552 auf; diese Seite nutzt CWE-863 als primäre Ursachenklassifizierung.

Schritt-für-Schritt Angriffsablauf

Schritt 1

Die Anwendung aktiviert optionales HTML-Rendering

Die betroffene Bereitstellung verwendet die Python-API mit HTMLBackendOptions(render_page=True) und installiertem Playwright. Standardkonfiguration, Docling-CLI und docling-serve gehören laut Advisory nicht zur betroffenen Konfiguration.

Schritt 2

Die Anwendung übergibt HTML als filesystem Path

Laut Advisory ist nicht vertrauenswürdiges HTML betroffen, das als Path übergeben wird. Stream-Eingaben verwenden page.set_content() mit einem opaken Ursprung und sind von diesem file-Unterressourcenpfad nicht betroffen.

Schritt 3

Der Headless-Browser fordert eine lokale Ressource an

HTML kann beim Rendering Unterressourcen anfordern. Der betroffene Callback erlaubte file:, ohne die Berechtigung für lokale Zugriffe durchzusetzen; selbst bei aktivierter Option fehlte die Beschränkung auf das Quellverzeichnis, die der Pfad ohne Rendering verwendete.

Schritt 4

Lesbarer Text kann im gerenderten Bild erscheinen

Die beschriebene Auswirkung beschränkt sich auf Text, den eine lokale Datei im sichtbaren Browserbereich anzeigt. Seit Docling 2.91.0 ist JavaScript im Browser deaktiviert; leiten Sie daraus keine beliebige Codeausführung oder das Lesen unsichtbarer Bytes ab.

Schritt 5

Der korrigierte Filter stellt beide Prüfungen wieder her

Docling 2.118.1 erlaubt das Quelldokument selbst, blockiert andere file-Anfragen ohne aktiviertes enable_local_fetch und beschränkt erlaubte lokale Unterressourcen auf das Dokumentverzeichnis.

Quellcode: Verwundbar vs. Sicher

Der anfällige Auszug zeigt die bedingungslose file:-Freigabe, die im Maintainer-Advisory beschrieben ist; er ist keine vollständige Quelldatei. Der korrigierte Auszug folgt dem Upstream-Commit 1612b88: Quelldokument erlauben, enable_local_fetch für andere lokale Dateien verlangen, angeforderten Pfad auflösen und auf das Dokumentverzeichnis begrenzen. Aktualisieren Sie auf 2.118.1 oder höher, statt diesen gezielten Auszug zu kopieren. Die separate Behandlung von data:, about: und blob: gehört nicht zur Regel für lokale Dateien.

Quelltextauszug: docling/backend/html_backend.py — fokussierte Auszüge aus Anfrage- und Rendering-Richtlinie

VERWUNDBARE IMPLEMENTIERUNG
# Betroffener Rendering-Pfad: file: war vor den Prüfungen der Richtlinie für lokale Abrufe freigegeben.
if scheme in {"file", "data", "about", "blob"}:
    return None
GEHÄRTETER SICHERHEITS-PATCH
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)

# Innerhalb von _get_browser_request_block_reason():
if scheme == "file":
    if self._is_allowed_browser_file_request(request_url):
        return None
    # Andernfalls einen Grund für die blockierte Anfrage zurückgeben.

Checkliste für Engineering & Systemsicherheit

Quellen