Drupal OpenAI Provider — SSRF / lecture de fichier local via l'URL de réponse (CVE-2026-13233)

Amont non fiable : le fournisseur qui a récupéré l'URL que sa réponse lui indiquait. Drupal OpenAI Provider (ai_provider_openai) · SSRF (CWE-918) · CVE-2026-13233 · SA-CONTRIB-2026-053

Statut : Divulgation coordonnée terminée (2026-07-10). Signalé en privé à l'équipe de sécurité Drupal, corrigé et publié comme CVE-2026-13233 / avis SA-CONTRIB-2026-053 (noté Modérément critique). L'auteur est crédité comme découvreur et développeur de la correction.

Une étude d'un défaut classique d'autorisation / de validation des entrées sur un « point de connexion » d'IA : un fournisseur de génération d'images IA récupérait l'URL contenue dans la réponse de l'API amont à l'aide d'une fonction générique sans liste blanche de schémas. Sur les déploiements où l'amont configuré n'est pas la valeur par défaut de confiance (apportez-votre-propre-endpoint / proxy / passerelle auto-hébergée / relais compromis), la réponse pouvait pointer le serveur vers file:// ou une adresse interne.

L'entrée non fiable qui atteint le puits est l'URL de réponse de l'amont — pas l'invite de l'utilisateur.

• Classe (publiée) : SSRF (CWE-918). La SSRF incluait une lecture de fichier local file:// ; l'analyse interne de l'auteur l'a également rattachée à CWE-73 / CWE-441.
• Sévérité : Drupal Modérément critique (SA-CONTRIB-2026-053) — une bande moyenne sur l'échelle Drupal ≈ CVSS Moyen ; pas CVSS Critique/Élevé. Auto-évaluation pré-divulgation de l'auteur : plancher 3.1 / conditionnel 5.3 (Moyen) ; les 6.5 / 7.4 antérieurs sont rétractés, et la note moyenne l'a confirmé.
• Versions concernées : Drupal OpenAI Provider (ai_provider_openai) < 1.1.1 et 1.2.0–1.2.1 (audité 1.2.1) sur Drupal core 11.2
• Corrigé dans : 1.1.1 / 1.2.2 · CVE : CVE-2026-13233 · Avis : https://www.drupal.org/sa-contrib-2026-053

Ce qui a été démontré (confirmé) vs. non (non vérifié)

Toute la vérification s'est déroulée dans un bac à sable détenu et isolé du réseau contre un amont simulé (mock). La vraie API OpenAI n'a jamais été appelée. Les oracles de fuite étaient uniquement synthétiques.

Confirmé (démontré dynamiquement) :

• Déclenchement non-admin → lecture côté serveur d'un fichier local choisi par l'amont (chemin arbitraire prouvé avec un marqueur unique par exécution ; le corps servi est octet-pour-octet égal au marqueur ; le marqueur n'est présent que dans le conteneur applicatif, absent sur le mock — excluant « le mock a renvoyé son propre fichier »).
• Lecture de settings.php confirmée par correspondance d'octets sha256 (35 182 octets) — contenu jamais affiché ; les identifiants de base de données sont donc concernés.
• Récupération de réponse SSRF HTTP interne depuis un service sans port public (jeton interne à correspondance d'octets brute).
• Frontière d'autorisation : le même compte reçoit 403 sur la route de configuration admin (contraste 200-vs-403).
• Atteignabilité HTTP légitime via un flux « Generate » de widget de champ configuré par un admin, par un éditeur sans aucune permission IA.

Non vérifié (explicitement non revendiqué) :

• Vol d'identifiants de métadonnées cloud (IMDS) — mécaniquement plausible depuis le même puits, non tenté.
• Atteignabilité dynamique du jumeau de classe de base — surchargé sur ce fournisseur (code mort pour cette cible) ; enregistré comme variante de même cause racine pour porter la correction, pas comme une revendication séparée.
• Déclenchement passif « enregistrement seul » de l'automator — testé, négatif. Le simple « enregistrement » ne le déclenche pas.
• XSS stocké (confusion de type de contenu) et course concurrentielle de transcription vocale — pistes séparées, non prouvées.

Non concerné : api.openai.com par défaut sur TLS. Le réglage host est contrôlé par admin / config-sync / déploiement — un attaquant non-admin au moment de l'exécution ne peut pas le modifier.

Cause racine & direction de correction (résumé)

L'URL de réponse était passée à une récupération générique qui honore tous les wrappers de flux PHP enregistrés (file, php, http, data, phar, …). response_format par défaut est url, donc la branche vulnérable est le chemin par défaut. file:// est le wrapper de système de fichiers par défaut de PHP et n'est pas conditionné par allow_url_fopen (une affirmation antérieure « nécessite allow_url_fopen » était erronée et est rétractée).

Corriger la primitive, pas seulement le site d'appel :

1. Cesser d'utiliser une récupération générique pour l'extraction à distance ; utiliser le client injecté limité au HTTP.
2. Valider que le schéma est http/https avant la requête ; désactiver les redirections (un 30x peut rebondir vers file://).
3. Défense en profondeur : rejeter les hôtes résolus privés / link-local / loopback, ou contraindre aux hôte(s) CDN d'images configuré(s) ; valider la taille / le type de contenu / le décodage d'image.
4. Porter la même correction à la classe de base afin que les fournisseurs frères en héritent (sinon correction incomplète).
5. Les tests de régression sont prioritairement des cas de refus : file://…, http://169.254.169.254/…, et une redirection 302→file:// doivent tous être refusés.

Direction complète : docs/fix-direction.md.

Structure du répertoire

.
├── README.md                          # ce fichier (anglais, canonique)
├── README_ja.md                       # miroir japonais
├── SECURITY.md                        # politique de signalement + avertissement de divulgation responsable
├── .gitignore                         # empêche les secrets / preuves primaires d'être commités
├── docs/
│   └── fix-direction.md               # correction de cause racine + chasse aux variantes + esquisse de diff minimal (EN)
├── reproducer/                        # reproducteur SÛR uniquement (bac à sable, amont simulé, oracle bénin)
│   ├── README.md                      # comment mettre en place le bac à sable isolé du réseau
│   ├── verdict.md                     # ce que « succès » signifie : correspondance d'octets brute + 200-vs-403 + codes de sortie
│   ├── mock-openai-server.py          # mock bénin ; PNG par défaut du chemin nominal, ssrf_demo → file:///etc/hostname uniquement
│   └── docker-compose.yml             # MODÈLE : bac à sable Drupal isolé + mock (vous ajoutez la cible vulnérable)
├── detections/
│   ├── README.md
│   ├── sigma/web-egress-to-internal-after-imagegen.yml
│   ├── sigma/php-sensitive-file-open.yml
│   ├── sentinel/imagegen-egress-correlation.kql
│   └── splunk/imagegen-content-type-mismatch.spl
└── timeline.md                        # chronologie de divulgation (source unique de vérité)

Les docs sont actuellement en japonais (.ja.md) ; les traductions canoniques en anglais sont à faire. Retirés de ce dépôt : les payloads d'armement et tout PoC clé-en-main de lecture de fichier. Le reproducer/ public démontre le mécanisme du défaut contre un mock en utilisant un seul oracle bénin (/etc/hostname) — pas de lecture de chemin arbitraire, pas de récupération de settings.php, pas d'IMDS. Ce n'est pas une arme contre des sites en production. Mettez à jour vers 1.1.1 / 1.2.2.

Reproducteur sûr

Objectif : permettre à un chercheur de confirmer la classe de défaut sans fournir d'exploit contre une cible réelle ni exposer de secrets. Tout fonctionne hors ligne.

• Isolement : docker compose avec l'application et un amont simulé sur un réseau isolé (--network none pour les vérifications de primitives du langage). Aucun identifiant monté. Le mock ne parle jamais à la vraie API.
• Modèle fidèle d'amont non fiable : le mock joue « un host pointant vers un proxy / une passerelle auto-hébergée non fiable. » Il est armé hors bande (pas via l'invite) pour renvoyer une URL cible synthétique — cela encode le modèle d'attaquant corrigé (l'amont choisit l'URL, l'utilisateur ne fait que déclencher).
• Oracles bénins uniquement :
  • file:///etc/hostname et un marqueur unique par exécution écrit uniquement dans le conteneur applicatif → prouve que l'application a lu un chemin choisi par l'amont (marqueur absent sur le mock).
  • settings.php vérifié par correspondance d'octets sha256, contenu jamais émis → prouve « identifiants de base de données concernés » sans les divulguer.
  • Un service HTTP interne sans port public → prouve la récupération de réponse SSRF interne avec un jeton synthétique.
• Le verdict est en octets bruts, pas en HTTP 200 : succès = corps servi octet-pour-octet égal à la valeur synthétique attendue, plus un contraste d'autorisation 200-vs-403. Les codes de sortie sont stricts (0 exploitable / 1 précondition / 2 non-reproduit / échec de nettoyage / erreur). Voir .

Voir reproducer/README.md.

Chronologie de la divulgation

Voir timeline.md. Résumé :

Recommandations de détection

Les détections pour praticiens se trouvent dans detections/ ; la justification dans docs/detection-engineering.md. En bref :

• Corréler qui a déclenché la génération d'images (journal d'audit applicatif) avec un trafic sortant anormal (proxy / EDR) vers 169.254.169.254 / loopback / RFC1918 dans une fenêtre temporelle étroite après l'appel API. Ne pas alerter sur le seul trafic sortant.
• Les lectures file:// ne passent jamais par le réseau — détecter les ouvertures de fichiers sensibles par les processus web via l'audit hôte (auditd/EDR), avec une ligne de base afin que seules les lectures hors motif au sein d'une requête de génération d'images déclenchent.
• Rechercher rétrospectivement les octets déclarés image/* dont les octets magiques ne sont pas une image.
• La plupart des intégrations IA ne journalisent pas quel utilisateur a récupéré quelle URL — ajouter un enregistrement d'audit de récupération {request_id, actor, target_url, scheme, resolved_ip, content_type}. Les journaux standard seuls ne suffiront pas à détecter cela.

Références

• OWASP Top 10 A10:2021 — Falsification de requête côté serveur
• CWE-918 SSRF · CWE-73 contrôle externe du nom/chemin de fichier · CWE-441 proxy/relais involontaire · CWE-610 référence contrôlée en externe
• Wrappers de flux PHP (file:// est le wrapper de système de fichiers par défaut ; non conditionné par allow_url_fopen)
• Équipe de sécurité Drupal — divulgation coordonnée via le « Report a security vulnerability » du projet
• Avis : Drupal SA-CONTRIB-2026-053 — https://www.drupal.org/sa-contrib-2026-053
• CVE : CVE-2026-13233 (CNA : Drupal.org)

Avis de sécurité

• La divulgation est terminée (CVE-2026-13233 / SA-CONTRIB-2026-053), donc les détails produit/version/code sont publics. Mettez à jour vers 1.1.1 / 1.2.2 d'abord — des sites non corrigés restent en production.
• Le reproducer/ est réservé au bac à sable et utilise des oracles synthétiques. Ce n'est pas un exploit contre des cibles réelles et ne contient aucun secret. Ne l'exécutez pas contre des systèmes que vous ne possédez pas et n'êtes pas autorisé à tester.
• Aucun PoC de lecture de fichier fonctionnel et aucune preuve primaire contenant des secrets ne sont inclus ici — délibérément, même après la correction, tant que des déploiements non corrigés existent.

Avertissement de divulgation responsable

Toutes les recherches ont été menées par l'auteur dans un bac à sable auto-détenu et isolé du réseau, contre un amont simulé — la vraie API du fournisseur n'a jamais été contactée, et aucun système tiers n'a jamais été testé. La découverte a été signalée en privé à l'équipe de sécurité Drupal en premier et publiée uniquement en synchronisation avec la correction et l'avis (SA-CONTRIB-2026-053, CVE-2026-13233) ; la note du fournisseur est Modérément critique. Les chiffres CVSS de l'auteur sont une auto-évaluation provisoire, pas un score officiel, et ont été délibérément conservés prudents (pas de CVSS Critique/Élevé) — conformes à la bande moyenne du fournisseur. Ce contenu est à des fins défensives et pédagogiques. Voir SECURITY.md.