Zum Inhalt springen
Beveiligingsnieuws

Ungepatchte Kaltura-mwEmbed-Lücken: RCE und Dateidiebstahl

Kaltura mwEmbed kwetsbaarheden

CERT/CC hat zwei ungepatchte Kaltura-mwEmbed-Lücken veröffentlicht, die Angreifer ohne Anmeldung ausnutzen können. Laut Hinweis sind sowohl das Lesen beliebiger Dateien als auch eine Codeausführung auf betroffenen Servern möglich – der wichtigste gemeinsame Faktor ist eine unsichere Serialisierung/deserialisierung im mwEmbedLoader.php-Endpoint.

Zum Zeitpunkt der Veröffentlichung gab es keinen verfügbaren Fix. Administratoren sollen deshalb vor allem den externen Zugriff auf den betroffenen Endpunkt begrenzen oder entfernen und zusätzliche Schutzmaßnahmen einführen, insbesondere beim Umgang mit bestimmten Parametern.

Worum es bei den ungepatchte Kaltura-mwEmbed-Lücken geht

Die beiden Schwachstellen tragen die Kennungen CVE-2026-19913 und CVE-2026-19912. CERT/CC beschreibt, dass beide Probleme auf derselben Ursache beruhen: einer unsicheren Deserialisierung in der mwEmbedLoader.php-Komponente der mwEmbed-Player-Bibliothek. Diese Bibliothek wird von Kaltura unter anderem als Teil von html5lib verteilt.

Wichtig ist: Für die Ausnutzung ist weder eine Authentifizierung noch ein Kaltura-Session-Token erforderlich. Als einzige Voraussetzung nennt CERT/CC den Netzwerkzugriff auf den betreffenden Endpoint. Mit anderen Worten: Wer den Endpunkt aus dem Internet erreichbar betreibt, trägt ein erhöhtes Risiko.

CVE-2026-19913: Beliebige Dateien lesen

Die erste Lücke (CVE-2026-19913) beginnt laut CERT/CC mit dem Parameter ServiceUrl. Der Endpoint mwEmbedLoader.php akzeptiert diesen Wert und verwendet ihn als Zieladresse für Backend-API-Anfragen. Anschließend verarbeitet eine PHP-Client-Komponente die Antwort und gibt sie ohne ausreichende Validierung weiter – insbesondere wird sie in der Folge an PHP’s unserialize() übergeben.

Wenn ein Angreifer statt einer erwarteten API-Antwort eine file://-Adresse als ServiceUrl übergibt, versucht die Anwendung eine lokale Datei zu holen. Die Deserialisierung schlägt zwar fehl, aber die Rohbytes der gelesenen Datei werden im Rahmen einer Fehlermeldung an den Anfragenden zurückreflektiert.

Damit entsteht ein klassischer Informationsabfluss: Der Angreifer erhält Inhalte aus dem Dateisystem, obwohl die Verarbeitung fehlschlägt. CERT/CC stufte das als entfernte, nicht authentifizierte Schwachstelle ein.

Was der Forscher konkret nachgewiesen hat

Der Security-Researcher Gerjan Wemekamp (u. a. AndDone) beschrieb in einer technischen Ausarbeitung, wie er den Dateilesevorgang praktisch eskalierte. Er nutzte dabei das Auslesen der Kaltura-Anwendungskonfiguration unter /opt/kaltura/app/configurations/local.ini. Diese Datei kann laut Bericht unverschlüsselte Zugangsdaten enthalten, darunter Datenbankverbindungsstrings, Admin- und Konsolenpasswörter sowie interne Host-Referenzen.

Wemekamp erläuterte zugleich den Rahmen seines Nachweises: Er zeigte die Kette nicht pauschal für alle Installationen, sondern präzisierte, was er auf älteren und neueren Artefakten verifiziert hatte.

CVE-2026-19912: Codeausführung unter bestimmten Bedingungen

Die zweite Lücke (CVE-2026-19912) macht aus der gleichen unsicheren Deserialisierung eine Möglichkeit zur Codeausführung. CERT/CC beschreibt, dass ein Parameter namens uiconf_id dabei eine zentrale Rolle spielt.

Der Wert von uiconf_id wird in einen Cache-Verzeichnispfad eingebunden und laut Hinweis ohne ausreichende Bereinigung verarbeitet. Dadurch kann der Parameter so manipuliert werden, dass eine Directory Traversal-Sequenz wie ../ in den Pfad gelangt und das Schreiben außerhalb des vorgesehenen Cache-Verzeichnisses in ein webzugängliches Ziel umleitet.

Der Angriff funktioniert dann in einer Kette: Der Angreifer setzt ServiceUrl auf ein bösartiges serialisiertes Objekt, das ausführbaren PHP-Code enthält. Der Client holt und deserialisiert dieses Objekt. Anschließend sorgt der uiconf_id-Wert dafür, dass der Inhalt in einen Ort geschrieben wird, von dem aus der Webserver ihn als Datei bereitstellt. Wird die Datei anschließend direkt angefordert, kann sie als der Benutzer ausgeführt werden, mit dem der Webserver-Prozess läuft.

Warum ein Cache-Setup das Risiko nicht „wegzaubert“

Wemekamp machte in seinem Bericht deutlich, dass der „File-drop“-Schritt vom verwendeten Cache-Backend abhängt. In einem Setup mit memcache-only könne der Schreibpfad unter Umständen ausbleiben und damit genau dieser RCE-Umweg weniger zuverlässig sein. Allerdings bleibt er nach seiner Aussage nicht automatisch sicher: Selbst wenn ein Teil der Kette unterdrückt wird, kann der Gesamtzustand einer Umgebung weiterhin problematisch sein.

Keine Patches verfügbar: Was CERT/CC empfiehlt

CERT/CC nennt keinen festen Software-Fix. Zusätzlich gab die Organisation an, sie habe Kaltura nicht erreichen können, um die Koordination der Schwachstellen abzustimmen. Entsprechend liegt der Fokus der Empfehlungen auf administrativen und technischen Eindämmungen.

Als betroffene Versionen nennt CERT/CC html5lib v2.45, v2.103 und frühere Varianten sowie weitere v2.x-Releases, die den problematischen Endpunkt freilegen.

1) Endpoint blockieren oder entfernen

Wenn ältere mwEmbed-Player nicht aktiv genutzt werden, empfiehlt CERT/CC, den Endpunkt über WAF, Reverse Proxy oder CDN zu blockieren bzw. zu entfernen. Ziel ist, den Netzwerkzugriff auf mwEmbedLoader.php zu unterbinden.

2) ServiceUrl strikt erlauben

Eine zentrale Maßnahme ist das Allow-listing für ServiceUrl. Es sollen ausschließlich die vorgesehenen eigenen Backend-API-Hosts zugelassen werden. Gleichzeitig sollen nicht erlaubte Schemes verworfen werden – etwa wenn statt HTTP(S) unerwartete Protokolle genutzt würden.

3) uiconf_id-Eingaben härten

Für uiconf_id empfiehlt CERT/CC, Werte zurückzuweisen, die Traversal-Sequenzen, absolute Pfade oder Directory-Separatoren enthalten. So soll verhindert werden, dass ein Angreifer den Cache-Zielpfad in ungewollte Bereiche lenkt.

4) PHP-Ausführung in Cache-Verzeichnissen verhindern

Da die RCE-Variante davon abhängt, dass ein geschriebenes Artefakt als PHP ausgeführt werden kann, sollten Administratoren außerdem PHP execution in cache directories unterbinden. Das reduziert die Wirksamkeit des „Write-to-webroot“-Teils der Angriffslogik.

5) Ausgehenden Netzwerkverkehr einschränken

Im Codeausführungspfad braucht die Anwendung laut Bericht Zugriffsmöglichkeiten, um die Nutzlast zu beschaffen. Daher empfiehlt CERT/CC, Outbound-Netzwerkzugriffe vom Anwendungsserver aus zu beschränken.

6) Geheime Daten rotieren

Weil bei der Dateileselücke (CVE-2026-19913) laut Bericht auch Konfigurationen mit Klartext-Zugangsdaten auslesbar sein können, sollten Admins die betroffenen Secrets rotieren. Dazu gehören Datenbankzugänge, Admin- und Konsolenpasswörter, Partnergeheimnisse und API-Keys – insbesondere auf Systemen, bei denen der Endpunkt extern erreichbar war.

Warum auch geteilte Plattformen betroffen sein können

CERT/CC weist zusätzlich darauf hin, dass der betroffene Loader-Endpoint auch in der shared, multi-tenant CDN Infrastruktur exponiert sein kann. Das bedeutet: Nicht nur einzelne Kunden-Installationen, sondern unter Umständen alle Tenants, die über solche gemeinsam genutzten Hosts bedient werden, sind potenziell betroffen.

Gerade in Multi-Tenant-Setups ist Eindämmung über Netzwerkfilter und restriktive Parameterlogik deshalb besonders wichtig, weil einzelne Betriebsteile nicht isoliert betrachtet werden sollten.

Einordnung: Risiko, Ausnutzungslage und betroffene Bereiche

Zum Zeitpunkt der Veröffentlichung lag laut Hinweis keine gemeldete aktive Ausnutzung vor. Außerdem tauchten die beiden CVEs (Stand 25. August 2026) nicht in der CISA-Liste „Known Exploited Vulnerabilities“ auf. Das heißt nicht, dass das Risiko gering ist – nur, dass keine bestätigten Vorfälle öffentlich dokumentiert waren.

Die Bewertung der Forscher war dennoch eindeutig: Wemekamp vergab 10.0 für CVE-2026-19912 und 9.1 für CVE-2026-19913 (Reporter-assigned). CERT/CC veröffentlichte selbst keine Scores, und für die CVEs gab es zum genannten Zeitpunkt kein NVD-Eintrag.

Technischer Hintergrund: Warum Deserialisierung so gefährlich ist

Beide Sicherheitsprobleme lassen sich auf eine gemeinsame Designschwäche zurückführen: Der Code verwendet eine unsichere Deserialisierung auf Basis von Daten, die aus einer vom Angreifer gesteuerten Quelle stammen können. Im Zusammenspiel mit unzureichender Validierung bei ServiceUrl und uiconf_id entsteht so eine „Kettenwirkung“, die von Informationsabfluss bis zur Codeausführung reichen kann.

Kurz gesagt: Wenn Eingaben bzw. Antworten aus externen Quellen unkontrolliert an unserialize() weitergereicht werden, sinkt die Hürde für Angreifer drastisch. Die beschriebenen Parameter- und Pfadmanipulationen ermöglichen dann auch die nächste Stufe: zielgerichtetes Schreiben und spätere Ausführung.

So gehen Sie jetzt konkret vor

Auch wenn es keinen Patch gibt, können Sie das Risiko erheblich reduzieren. Prüfen Sie als erstes, ob mwEmbedLoader.php in Ihrer Umgebung überhaupt aus dem Internet erreichbar ist. Falls ja, setzen Sie sofort Netzwerk-Blocking um, idealerweise so, dass alte mwEmbed-Player keine Route mehr zum Endpunkt haben.

Aktivieren Sie danach strikt die Eingabe- und Zielbeschränkungen: ServiceUrl nur auf eigene API-Hosts erlauben und uiconf_id-Eingaben so behandeln, dass Traversal und Pfadmanipulationen abgewiesen werden. Ergänzend sollten Sie die Rechte und die Ausführbarkeit im Cache-Bereich sowie ausgehende Verbindungen überprüfen.

Abschließend sollten Sie, falls der Endpoint extern verfügbar war, die in local.ini oder vergleichbaren Konfigurationen gespeicherten Geheimnisse rotieren. Damit senken Sie die Wahrscheinlichkeit, dass ausgelesene Zugangsdaten später für weitere Angriffe genutzt werden.

Fazit

Die ungepatchte Kaltura-mwEmbed-Lücken zeigen, wie kritisch unsichere Deserialisierung und unzureichend validierte Parameter sind. CERT/CC beschreibt Angriffswege, die ohne Authentifizierung Dateidiebstahl (CVE-2026-19913) und unter bestimmten Bedingungen Codeausführung (CVE-2026-19912) ermöglichen können. Da kein Fix verfügbar ist, bleibt die wichtigste Antwort: Netzwerkzugriff begrenzen, Eingaben strikt erlauben, Pfade härten, PHP-Ausführung in Cache-Verzeichnissen verhindern, Outbound-Verkehr reduzieren und betroffene Secrets rotieren.

Quelle: https://thehackernews.com/2026/08/unpatched-kaltura-mwembed-flaws-could.html