Drupal OpenAI Provider — SSRF / lokales Dateilesen über Antwort-URL (CVE-2026-13233)

Nicht vertrauenswürdiger Upstream: der Provider, der die URL abgerufen hat, die seine Antwort ihm vorgab. Drupal OpenAI Provider (ai_provider_openai) · SSRF (CWE-918) · CVE-2026-13233 · SA-CONTRIB-2026-053

Status: Koordinierte Offenlegung abgeschlossen (2026-07-10). Privat an das Drupal-Sicherheitsteam gemeldet, behoben und als CVE-2026-13233 / Advisory SA-CONTRIB-2026-053 veröffentlicht (bewertet als Mäßig kritisch). Autor als Finder & Entwickler der Behebung genannt.

Eine Untersuchung eines klassischen Autorisierungs-/Eingabevalidierungsfehlers an einem KI-„Verbindungspunkt“: Ein KI-Bildgenerierungs-Provider rief die in der Upstream-API-Antwort enthaltene URL mit einer Allzweckfunktion ohne Scheme-Zulassungsliste ab. Bei Bereitstellungen, bei denen der konfigurierte Upstream nicht der vertrauenswürdige Standard ist (Bring-Your-Own-Endpoint / Proxy / selbst gehostetes Gateway / kompromittiertes Relay), konnte die Antwort den Server auf file:// oder eine interne Adresse verweisen.

Die nicht vertrauenswürdige Eingabe, die die Senke erreicht, ist die Upstream-Antwort-URL — nicht der Prompt des Benutzers.

• Klasse (veröffentlicht): SSRF (CWE-918). Das SSRF umfasste ein file://-lokales Dateilesen; die interne Analyse des Autors ordnete es auch CWE-73 / CWE-441 zu.
• Schweregrad: Drupal Mäßig kritisch (SA-CONTRIB-2026-053) — ein mittleres Band auf Drupals Skala ≈ CVSS Medium; nicht CVSS Critical/High. Selbsteinschätzung des Autors vor der Offenlegung: Untergrenze 3.1 / bedingt 5.3 (Medium); frühere 6.5 / 7.4 zurückgezogen, und die mittlere Bewertung bestätigte dies.
• Betroffen: Drupal OpenAI Provider (ai_provider_openai) < 1.1.1 und 1.2.0–1.2.1 (geprüft 1.2.1) auf Drupal Core 11.2
• Behoben in: 1.1.1 / 1.2.2 · CVE: CVE-2026-13233 · Advisory: https://www.drupal.org/sa-contrib-2026-053

---

Was nachgewiesen wurde (bestätigt) vs. nicht (unverifiziert)

Die gesamte Verifikation lief in einer eigenen, netzisolierten Sandbox gegen einen Mock-Upstream. Die echte OpenAI-API wurde nie aufgerufen. Leak-Orakel waren ausschließlich synthetisch.

Bestätigt (dynamisch demonstriert):

• Nicht-Admin-Auslöser → serverseitiges Lesen einer vom Upstream gewählten lokalen Datei (beliebiger Pfad belegt durch ein pro Lauf eindeutiges Markerkennzeichen; gelieferter Body byte-identisch mit dem Marker; Marker nur im App-Container vorhanden, nicht im Mock — dadurch ausgeschlossen, dass „der Mock seine eigene Datei zurückgegeben hat“).
• settings.php-Lesen bestätigt durch sha256-Byteabgleich (35,182 B) — Inhalt nie ausgegeben; DB-Anmeldedaten sind daher im Umfang enthalten.
• Interner HTTP-SSRF: Antwortabruf von einem Dienst ohne öffentlichen Port (internes Token byte-identisch).
• Autorisierungsgrenze: dasselbe Konto erhält 403 auf der Admin-Konfigurationsroute (200-vs-403-Kontrast).
• Erreichbarkeit von legitimem HTTP über einen realistischen, vom Admin konfigurierten Feld-Widget-„Generieren“-Ablauf durch einen Redakteur ohne KI-Berechtigungen.

Unverifiziert (ausdrücklich nicht behauptet):

• Cloud-Metadaten- (IMDS-) Anmeldedatendiebstahl — mechanistisch plausibel von derselben Senke, nicht versucht.
• Dynamische Erreichbarkeit des Basisklassen-Zwillings — in diesem Provider überschrieben (toter Code für dieses Ziel); als Variante mit derselben Grundursache zur Übertragung des Fixes dokumentiert, nicht als separate Behauptung.
• Passiver „Nur-Speichern“-Automator-Auslöser — getestet, negativ. „Bloßes Speichern“ löst es nicht aus.
• Stored-XSS (Content-Type-Verwechslung) und Speech-to-Text-Nebenläufigkeits-Race — separate Leads, unbelegt.

Nicht betroffen: Standard-api.openai.com über TLS. Die host-Einstellung wird von Admin / Config-Sync / Deploy gesteuert — ein Nicht-Admin-Angreifer zur Laufzeit kann sie nicht ändern.

---

Grundursache & Richtung der Behebung (Zusammenfassung)

Die Antwort-URL wurde an einen Allzweck-Fetch übergeben, der jeden registrierten PHP-Stream-Wrapper (file, php, http, data, phar, …) berücksichtigt. response_format ist standardmäßig url, daher ist der verwundbare Zweig der Standardpfad. file:// ist PHPs Standard-Dateisystem-Wrapper und wird nicht durch allow_url_fopen abgeschirmt (eine frühere Behauptung „erfordert allow_url_fopen“ war falsch und wird zurückgezogen).

Behebe das Primitiv, nicht nur die Aufrufstelle:

1. Verwende keinen Allzweck-Fetch für den Remote-Abruf; nutze den injizierten HTTP-only-Client.
2. Validiere das Scheme als http/https vor der Anfrage; deaktiviere Weiterleitungen (ein 30x kann zu file:// weiterleiten).
3. Defense in Depth: lehne aufgelöste Private-/Link-Local-/Loopback-Hosts ab oder beschränke auf die konfigurierten Image-CDN-Hosts; validiere Größe / Content-Type / Bilddekodierung.
4. Übertrage denselben Fix auf die Basisklasse, damit Geschwister-Provider ihn erben (sonst unvollständiger Fix).
5. Regressionstests sind zuerst Verweigerungsfälle: file://…, http://169.254.169.254/… und eine 302→file://-Weiterleitung müssen alle abgelehnt werden.

Vollständige Richtung: docs/fix-direction.md.

---

Verzeichnisstruktur

.
├── README.md                          # this file (English, canonical)
├── README_ja.md                       # Japanese mirror
├── SECURITY.md                        # reporting policy + responsible-disclosure disclaimer
├── .gitignore                         # blocks secrets / primary evidence from being committed
├── docs/
│   └── fix-direction.md               # root-cause fix + variant hunt + minimal-diff sketch (EN)
├── reproducer/                        # SAFE reproducer only (sandbox, mock upstream, benign oracle)
│   ├── README.md                      # how to stand up the network-isolated sandbox
│   ├── verdict.md                     # what "success" means: raw-byte match + 200-vs-403 + exit codes
│   ├── mock-openai-server.py          # benign mock; default happy-path PNG, ssrf_demo → file:///etc/hostname only
│   └── docker-compose.yml             # TEMPLATE: isolated Drupal sandbox + mock (you add the vulnerable target)
├── 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                        # disclosure timeline (single source of truth)

Die Dokumentation ist derzeit japanisch (.ja.md); englische kanonische Übersetzungen sind ein TODO. Aus diesem Repository zurückgehalten: scharfe Payloads und jeder schlüsselfertige Dateilesen-PoC. Das öffentliche reproducer/ demonstriert den Fehlermechanismus gegen einen Mock mit einem einzigen unbedenklichen Orakel (/etc/hostname) — kein Lesen beliebiger Pfade, kein settings.php-Abgriff, kein IMDS. Es ist keine Waffe gegen Live-Sites. Aktualisiere auf 1.1.1 / 1.2.2.

---

Sicherer Reproducer

Ziel: einem Forscher ermöglichen, die Fehler-Klasse zu bestätigen, ohne einen Exploit für Live-Ziele bereitzustellen oder Geheimnisse offenzulegen. Alles läuft offline.