Bug-Report erhalten: angebliches Umgehen der Onebox-iFrame-Whitelist. Kann jemand das verifizieren?

Unterstützung
1

Wir betreiben ein Discourse-Forum und haben einen externen Bericht erhalten, der eine gespeicherte Code-Injection-Schwachstelle über den Onebox-/allowed_onebox_iframes-Mechanismus behauptet. Bevor wir Maßnahmen ergreifen, würde ich gerne die Unterstützung der Community/des Teams bei der Bestätigung einholen, ob das beschriebene Verhalten in der aktuellen Discourse-Version tatsächlich möglich ist.

Der Bericht behauptet:

  • Discourse erstellt Oneboxes für einzelne URLs auf einer eigenen Zeile undbettet den twitter:player der Seite als iframe für alle Betrachter ein.
  • Die Ursprungsübereinstimmung für die iframe-Whitelist ist nur “prefixbasiert”, sodass ein Host wie www.youtube.com.attacker.example als legitime YouTube-Einbettung akzeptiert würde, während HTML vom Angreifer bereitgestellt wird.
  • Die Standard-allowed_onebox_iframes ist effektiv ein Wildcard-Eintrag.

Meines Erachtens gilt: (a) Discourse stimmt erlaubte iframe-Hosts auf Domain-Grenzenbasis ab, nicht nur als bloßen Präfix, und (b) die Standard-Onebox-iframe-Whitelist ist eine kuratierte Anbieterliste, kein *. Kann jemand bestätigen, wie die Host-Abgleichsfunktion für allowed_onebox_iframes in der aktuellen Version funktioniert und ob ein Subdomain-Suffix-Trick wie der beschriebene die Validierung tatsächlich passieren könnte?

Wir verwenden Discourse Version v2026.8.0-latest. Gerne teilen wir den rohen Bericht privat mit dem Sicherheitsteam, falls dies hilfreich ist.

Danke.

2

Ich vermute, dass dies ein LLM-Sicherheitsbericht aus einer unvollständigen Pipeline ist.

Eine vollständig entwickelte LLM-Sicherheitspipeline würde eine Theorie entwickeln, dann eine Testinstallation von Discourse einrichten, die problematischen Site-Einstellungen konfigurieren und das Problem dort nachweisen. Das scheint hier nicht passiert zu sein, und sie sind von der Theorie direkt zum Versenden des Berichts an dich übergegangen.

5

Hi @Saurabh1,

ich kann bestätigen, dass die Schwachstelle real ist und wir bereits eine Lösung in der Pipeline haben.

6

Eine Lösung für dieses Problem ist in July 31st 2026 intermediate releases enthalten