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

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.

• Isolation: docker compose mit der App und einem Mock-Upstream in einem isolierten Netzwerk (--network none für die Sprachprimitiv-Prüfungen). Keine Anmeldedaten eingehängt. Der Mock spricht nie mit der echten API.
• Modell des nicht vertrauenswürdigen Upstream: Der Mock spielt „einen host, der auf ein nicht vertrauenswürdiges Proxy/selbst gehostetes Gateway zeigt.“ Er wird out-of-band scharfgeschaltet (nicht über den Prompt), um eine synthetische Ziel-URL zurückzugeben — das kodiert das korrigierte Angreifermodell (der Upstream wählt die URL, der Benutzer löst nur aus).
• Nur unbedenkliche Orakel:
  • file:///etc/hostname und ein pro Lauf eindeutiges Markerkennzeichen, das nur im App-Container geschrieben wird → beweist, dass die App einen vom Upstream gewählten Pfad gelesen hat (Marker fehlt im Mock).
  • settings.php verifiziert durch sha256-Byteabgleich, Inhalt nie ausgegeben → beweist „DB-Anmeldedaten im Umfang“, ohne sie offenzulegen.
  • Ein interner HTTP-Dienst ohne öffentlichen Port → beweist internen SSRF-Antwortabruf mit einem synthetischen Token.
• Urteil ist Rohbyte, nicht HTTP 200: Erfolg = gelieferter Body bytegleich mit dem erwarteten synthetischen Wert, plus ein 200-vs-403-Autorisierungskontrast. Exitcodes sind strikt (0 ausnutzbar / 1 Vorbedingung / 2 nicht reproduziert / 3 Bereinigung fehlgeschlagen / 99 Fehler). Siehe reproducer/verdict.md.
• Transparenzhinweis: Jede Umgebungsnormalisierung (z. B. Korrektur eines Sandbox-Dateiverzeichnisbesitzers, den ein früherer Root-Lauf unbeschreibbar hinterlassen hat) ist dokumentiert und betrifft nur das Speichern/Liefern-Segment, nicht die Dateilesen-Senke selbst. Dies wird offengelegt, damit Prüfer es nicht als manipulierte Vorbedingung fehldeuten.

Siehe reproducer/README.md.

Offenlegungs-Zeitplan

Siehe timeline.md. Zusammenfassung:

Erkennungsleitfaden

Praktiker-Erkennungen liegen in detections/; die Begründung in docs/detection-engineering.md. Kurz gesagt:

• Korreliere, wer die Bildgenerierung ausgelöst hat (App-Audit), mit anomalem Egress (Proxy / EDR) zu 169.254.169.254 / Loopback / RFC1918 in einem engen Zeitfenster nach dem API-Aufruf. Alarmiere nicht allein wegen Egress.
• file://-Lesezugriffe erreichen nie das Netzwerk — erkenne sensible Dateiöffnungen durch Webprozesse über Host-Auditierung (auditd/EDR), basisliniert, sodass nur Musterabweichungen innerhalb einer Bildgen-Anfrage auslösen.
• Suche retrospektiv nach als image/* deklarierten Bytes, deren Magic Bytes kein Bild sind.
• Die meisten KI-Integrationen protokollieren nicht, welcher Benutzer welche URL abgerufen hat — füge einen Fetch-Auditdatensatz {request_id, actor, target_url, scheme, resolved_ip, content_type} hinzu. Standardprotokolle allein werden das nicht erkennen.

Referenzen

• OWASP Top 10 A10:2021 — Server-Side Request Forgery
• CWE-918 SSRF · CWE-73 externe Kontrolle von Dateiname/Pfad · CWE-441 unbeabsichtigter Proxy/Relay · CWE-610 extern kontrollierte Referenz
• PHP-Stream-Wrapper (file:// ist der Standard-Dateisystem-Wrapper; nicht durch allow_url_fopen abgeschirmt)
• Drupal-Sicherheitsteam — koordinierte Offenlegung über die „Report a security vulnerability“-Funktion des Projekts
• Advisory: Drupal SA-CONTRIB-2026-053 — https://www.drupal.org/sa-contrib-2026-053
• CVE: CVE-2026-13233 (CNA: Drupal.org)

Sicherheitshinweis

• Die Offenlegung ist abgeschlossen (CVE-2026-13233 / SA-CONTRIB-2026-053), daher sind Produkt-/Versions-/Codedetails öffentlich. Aktualisiere zuerst auf 1.1.1 / 1.2.2 — nicht gepatchte Sites sind weiterhin in freier Wildbahn vorhanden.
• Das reproducer/ ist nur für Sandboxen und verwendet synthetische Orakel. Es ist kein Exploit für Live-Ziele und enthält keine Geheimnisse. Führe es nicht gegen Systeme aus, die dir nicht gehören und für die du nicht zum Testen autorisiert bist.
• Kein funktionierender Dateilesen-PoC und keine Primärbeweise mit Geheimnissen sind hier enthalten — bewusst, auch nach dem Fix, solange nicht gepatchte Bereitstellungen existieren.

Haftungsausschluss zur verantwortungsvollen Offenlegung

Die gesamte Forschung wurde vom Autor in einer selbst betriebenen, netzisolierten Sandbox gegen einen Mock-Upstream durchgeführt — die echte Hersteller-API wurde nie kontaktiert und kein Drittsystem wurde jemals getestet. Der Befund wurde privat zuerst an das Drupal-Sicherheitsteam gemeldet und nur synchron mit dem Fix und Advisory veröffentlicht (SA-CONTRIB-2026-053, CVE-2026-13233); die Bewertung des Herstellers lautet Mäßig kritisch. Die CVSS-Zahlen des Autors sind eine vorläufige Selbsteinschätzung, keine offizielle Bewertung, und wurden bewusst konservativ gehalten (kein CVSS Critical/High) — konsistent mit der mittleren Bewertung des Herstellers. Dieses Material dient defensiven und Bildungszwecken. Siehe SECURITY.md.