CVE-2026-105751 : fuite de fichiers ODF dans Docling

Le backend ODF de Docling pouvait interpréter la référence d’image d’un document comme un chemin local et le lire hors de l’archive. Passez à la version 2.120.3 ; le correctif utilise le composant partagé de contrôle des ressources.

Vecteur CVSS

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N

💡 Explication en Langage Simple (ELI5)

Une bibliothécaire cherche une image dans un album. Si elle ne la trouve pas, le lecteur défectueux va ouvrir le dossier indiqué sur l’étiquette de l’album sans vérifier la règle de la bibliothèque interdisant les fichiers locaux. Le correctif fait passer le lecteur par le même guichet de ressources protégé que les autres formats.

Concepts Clés et Termes

OpenDocument Format (ODF): Famille de formats bureautiques comprenant les documents texte .odt. Docling lit les références d’image dans le XML du document.
draw:image: Élément XML ODF décrivant une image. Sa valeur xlink:href désigne la ressource.
xlink:href: Référence de ressource portée par un élément image ODF. Il s’agit d’une entrée du document, pas d’une décision d’autorisation du système de fichiers.
ImageResourceLoader: Chargeur d’images partagé de Docling. Il applique les options de chargement local et distant, la résolution des chemins et les vérifications des URL distantes.
enable_local_fetch: Option qui détermine si les backends compatibles peuvent charger des images locales. Un backend qui contourne le chargeur partagé contourne aussi cette protection.

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-22

Analyse de Cause Racine

Dans les versions concernées de Docling, _image_ref_from_odf_image() cherchait d’abord la ressource draw:image dans l’archive ODF. Si cette recherche ne renvoyait aucun octet, le fallback convertissait directement le xlink:href fourni par le document en Path puis appelait read_bytes() si le chemin existait. Il contournait ainsi ImageResourceLoader : le traitement ODF n’appliquait ni enable_local_fetch, ni enable_remote_fetch, ni les règles communes de résolution des ressources. Le filtre de type d’image acceptait aussi un suffixe vide, ce qui laissait passer des chemins sans extension. La lecture peut avoir lieu avant le décodage de l’image ; la divulgation dans le document résultant est démontrée lorsque les octets peuvent être décodés comme une image. L’avis du fournisseur décrit la lecture arbitraire de fichiers locaux et la divulgation de contenu image dans les formats de sortie de Docling, cette dernière étant limitée aux contenus décodables. Ce CVE concerne un document fourni et converti par un processus qui peut lire des fichiers locaux ; il ne prouve pas que toute installation de Docling soit accessible à distance. Le correctif transmet les références externes à ImageResourceLoader.load_image_data(), sans chemin de base local, propage le chargeur dans le parcours ODF et retire le suffixe vide des extensions autorisées. Le chargeur partagé refuse par défaut le chargement local et exige un chemin de base confiné s’il est activé. La CNA de GitHub attribue un score CVSS 4.0 de 6,9, modéré (UI:A) ; ne présentez pas le problème comme une exploitation distante sans authentification sans service et chemin de conversion supplémentaires accessibles.

Déroulement de l'Attaque Étape par Étape

Étape 1

Un document arrive dans le chemin de conversion ODF

L’entrée concernée est un fichier OpenDocument traité par Docling 2.107.0 à 2.120.2. Le problème se trouve dans le backend d’images ODF, pas dans tous les formats Docling ni dans toutes les intégrations HTML/RAG.

Étape 2

La référence d’image provient du XML du document

L’élément ODF draw:image fournit un xlink:href. Docling cherche d’abord la ressource dans l’archive.

Étape 3

Une partie absente de l’archive devient un chemin sur l’hôte

Si la recherche dans l’archive échoue, le helper vulnérable utilisait la même référence comme Path et la lisait directement. Le fallback ne consultait pas l’option de chargement local et ne confinait pas le chemin à l’archive.

Étape 4

Docling traite les octets comme une ressource image

La lecture du système de fichiers a lieu avant le décodage. Si le contenu est une image prise en charge, ses octets peuvent être intégrés au DoclingDocument et aux exports HTML, Markdown ou JSON.

Étape 5

Le chargeur corrigé rétablit la frontière des ressources

Docling 2.120.3 fait passer les références ODF externes par ImageResourceLoader, sans chemin de base local, et exclut les références sans extension. Gardez le chargement local désactivé lors du traitement de documents non fiables.

Code Source : Vulnérable vs Sécurisé

Il s’agit d’extraits ciblés du code upstream, pas d’un correctif autonome. Le correctif crée ImageResourceLoader avec les options enable_local_fetch et enable_remote_fetch du backend, le transmet au traitement ODF et lui confie les références externes. Avec base_path=None, les chemins locaux sont refusés même si le chargement local a été activé, car le chargeur ne peut pas établir de répertoire confiné. Le patch rejette aussi les suffixes d’image vides. Passez à la version 2.120.3 ou ultérieure au lieu de copier uniquement cet extrait.

Extrait source: docling/backend/opendocument_backend.py — extrait ciblé du code source

IMPLÉMENTATION VULNÉRABLE

# Une ressource absente de l’archive retombait sur le chemin fourni par le document.
if image_data is None and image_url:
    image_path = Path(image_url)
    if image_path.is_file():
        image_data = image_path.read_bytes()

PATCH SÉCURISÉ ET ROBUSTE

# Chemin corrigé : utiliser le chargeur partagé et les options du backend.
if image_data is None and image_url and image_loader is not None:
    image_data = image_loader.load_image_data(image_url, base_path=None)

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Mettez docling à jour vers 2.120.3 ou une version ultérieure et vérifiez la version réellement installée, y compris dans les services transitifs de traitement documentaire.
✓Inventoriez les pipelines qui acceptent des fichiers .odt, .ods ou .odp non fiables et déterminez quels fichiers du système sont lisibles par le processus de conversion.
✓Laissez enable_local_fetch désactivé pour les documents non fiables ; sur les versions vulnérables, cette option ne protège pas le chemin ODF qui contourne le chargeur partagé.
✓Exécutez la conversion sous une identité à privilèges réduits, avec une vue minimale et en lecture seule du système de fichiers, sans secret monté dans le processus.
✓Utilisez ImageResourceLoader dans les backends personnalisés au lieu d’ouvrir directement les chemins fournis par le document ; exigez une base fiable avant tout chargement local.
✓Ajoutez des tests de non-régression pour les images intégrées, les références d’archive manquantes, les références sans extension, les chemins absolus et les options de chargement local activées/désactivées, avec des fichiers-canaris jetables.
✓Vérifiez que les sorties ne contiennent que les ressources attendues ; une conversion réussie ne prouve pas qu’aucun autre fichier n’a été ouvert.
✓Si un service concerné a traité des fichiers ODF non fiables, examinez ses journaux et résultats à la recherche de données image inattendues, en limitant l’analyse aux fichiers lisibles par son compte de service.