Das Koordinationszentrum CERT (CERT/CC) hat Informationen veröffentlicht zu zwei ungepatchten Schwachstellen in der HTML5-Videoplayer-Bibliothek Kaltura, die es einem entfernten, nicht authentifizierten Angreifer ermöglichen, beliebige Dateien vom Server zu lesen und dort Code auszuführen. Die Schwachstellen werden unter den Kennungen CVE-2026-19913 (beliebiges Lesen von Dateien) und CVE-2026-19912 (Remote Code Execution) verfolgt. Ein Patch fehlt: Nach Angaben von CERT/CC gelang es dem Koordinationszentrum nicht, für eine koordinierte Offenlegung Kontakt mit Kaltura herzustellen. Das Problem betrifft nicht nur einzelne Installationen, sondern auch die mandantenfähige CDN-Infrastruktur des Herstellers, über die alle Kunden auf gemeinsamen Hosts bedient werden. Administratoren wird empfohlen, den Zugriff auf den verwundbaren Endpunkt umgehend zu blockieren und sämtliche Zugangsdaten zu rotieren.
Technische Details der Schwachstellen
Beide Schwachstellen wurzeln in einer unsicheren Deserialisierung im Endpunkt mwEmbedLoader.php der Bibliothek mwEmbed (auch als html5lib verbreitet). Laut CERT/CC erfordert keine der Schwachstellen eine Authentifizierung oder ein Kaltura-Session-Token – einzige Voraussetzung für einen Exploit ist der Netzwerkzugang zu diesem Endpunkt.
CVE-2026-19913 — beliebiges Lesen von Dateien
Der Endpunkt mwEmbedLoader.php akzeptiert den Parameter ServiceUrl und verwendet ihn als Ziel-URL für Anfragen an das Backend-API. Der PHP-Client KalturaClientBase ruft den Inhalt von der angegebenen URL ab und übergibt ihn ohne Validierung von Quelle, Schema oder Inhalt an die Funktion unserialize(). Gibt ein Angreifer einen Pfad mit dem Schema file:// an, liest der Server eine lokale Datei anstelle einer API-Antwort. Die Deserialisierung bricht mit einem Fehler ab, und der unbehandelte Dateiinhalt wird in der Fehlermeldung zurückgegeben. Der Forscher Gerjan Wemekamp von AndDone, der beide Schwachstellen in einem technischen Bericht beschrieben hat, bewertete diese Schwachstelle mit einem CVSS-Score von 9.1 (Forscherbewertung, nicht NVD).
CVE-2026-19912 — Remote Code Execution
Die zweite Schwachstelle verwandelt dieselbe Deserialisierung über den Parameter uiconf_id in einen Vektor für Remote Code Execution. Dieser Parameter wird beim Schreiben auf die Festplatte ohne Sanitization an den Pfad des Cache-Verzeichnisses angehängt. Der Angreifer lässt ServiceUrl auf ein bösartiges serialisiertes Objekt mit ausführbarem PHP-Code zeigen. Der Client ruft dieses ab und deserialisiert es. Der Wert von uiconf_id, der Verzeichniswechsel-Sequenzen enthält (z. B. ../), lenkt den Schreibvorgang aus dem Cache-Verzeichnis heraus in einen per Web zugänglichen Speicherort um. Ein direkter Aufruf dieser Datei führt zu deren Ausführung im Kontext des Webserver-Benutzers. Der Forscher bewertete diese Schwachstelle mit einem CVSS-Score von 10.0.
Nach Angaben Wemekamps hängt die Phase des Dateischreibens vom File-Backend des Caches ab, das in Kaltura standardmäßig konfiguriert ist. Eine Konfiguration, die ausschließlich memcache verwendet, kann das Schreiben und damit diesen konkreten Weg zur RCE unterbinden; sie macht das Deployment jedoch nicht sicher.
Betroffene Versionen: Laut CERT/CC sind html5lib v2.45, v2.103 und frühere Versionen verwundbar, ebenso wie andere Releases der v2.x-Reihe, in denen der verwundbare Endpunkt verfügbar ist. Keine der CVE wurde mit Stand 25. August 2026 in den CISA-KEV-Katalog aufgenommen. NVD-Einträge für beide Kennungen lagen zum selben Datum nicht vor. CERT/CC hat keine eigenen CVSS-Bewertungen veröffentlicht.
Status der Ausnutzung: aktive Ausnutzung in freier Wildbahn ist nicht bestätigt, der öffentliche technische Bericht des Forschers enthält jedoch im Wesentlichen eine Beschreibung, die für die Reproduktion des Angriffs ausreicht. Die vollständige Kette mit Ablage eines Webshells wurde auf einem Docker-Image von Kaltura Server aus dem Jahr 2019 demonstriert; der Forscher erklärte, dass im aktuellen Release beide Bestandteile der Kette vorhanden sind und die Deserialisierung wie beschrieben erfolgt.
Umfang der Auswirkungen und historischer Kontext
Besonders brisant ist die Architektur des Kaltura-Deployments. Wie CERT/CC feststellt, ist der verwundbare Endpunkt nicht nur auf individuellen Kunden-Installationen, sondern auch auf der gemeinsamen mandantenfähigen CDN-Infrastruktur des Herstellers erreichbar. Das bedeutet, dass eine Kompromittierung potenziell alle Mandanten betrifft, die über diese gemeinsamen Hosts bedient werden.
Bemerkenswert ist, dass Kaltura bereits in der Vergangenheit Probleme mit unsicherer Deserialisierung behoben hat. Im August 2017 hat das Unternehmen drei unsichere unserialize-Aufrufe entfernt und im Release 13.2.0 ein Fix veröffentlicht. Dieser Commit betraf jedoch drei Dateien, von denen keine KalturaClientBase.php war – die Datei, welche die aktuelle Schwachstelle enthält. Laut Ausgangsmaterial ist der Aufruf von unserialize() in dieser Datei über 21 Releases hinweg identisch – von Jupiter-10.9.0 (April 2015) bis West-23.5.0 (August 2026) – und tauchte erstmals im März 2014 auf.
Gescheiterte koordinierte Offenlegung
Die vom Forscher beschriebene Zeitleiste der Kontaktversuche mit dem Hersteller stellt sich wie folgt dar: Erster Bericht am 23. März 2026, erneute Einsendung von einer Firmenadresse am 13. April, Kontaktaufnahme mit dem CISO des Herstellers über LinkedIn am 23. Mai, Eskalation über das nationale CERT am 2. Juli. CERT/CC informierte Kaltura am 8. Juli. Der Herstellerstatus in den CERT/CC-Einträgen für beide CVE ist als „Unknown“ gekennzeichnet – es ging keinerlei Antwort ein. Gleichzeitig verweist die security.txt-Datei von Kaltura (letzte Aktualisierung: 28. Mai 2024) für Meldungen zu Schwachstellen auf das Bug-Bounty-Programm bei HackerOne und nennt die Adresse [email protected].
Empfehlungen zur Mitigation
In Abwesenheit eines Patches empfehlen CERT/CC und der Forscher folgende Schutzmaßnahmen:
- Den Endpunkt
mwEmbedLoader.phpauf Ebene von WAF, Reverse Proxy oder CDN blockieren oder entfernen – insbesondere, wenn veraltete mwEmbed-Player nicht verwendet werden. - Eine Allowlist für zulässige Werte von
ServiceUrlkonfigurieren, die nur den eigenen API-Host des Deployments erlaubt und Schemata ablehnt, die nicht HTTP(S) sind. - Werte von
uiconf_idablehnen, die Verzeichniswechsel-Sequenzen, absolute Pfade oder Verzeichnistrenner enthalten. - Die Ausführung von PHP in Cache-Verzeichnissen verbieten.
- Den ausgehenden Netzwerkzugang vom Applikationsserver einschränken – der Weg zur Codeausführung erfordert das Laden des Payloads von außen.
- Alle Secrets aus
local.inirotieren auf Installationen, auf denen der Endpunkt erreichbar war: Datenbank-Zugangsdaten, Administrator- und Konsolenpasswörter, Partner-Secrets und API-Keys.
Die Situation bei Kaltura ist ein anschauliches Beispiel dafür, wie fehlende Reaktion eines Herstellers eine koordinierte Offenlegung faktisch in einen Zero Day verwandelt. Der verwundbare Code existiert seit über 12 Jahren in der Codebasis, eine öffentliche Exploit-Beschreibung liegt vor, ein Patch jedoch nicht. Organisationen, die Kaltura einsetzen – sei es als eigene Installation oder als Cloud-Service –, sollten umgehend prüfen, ob der Endpunkt mwEmbedLoader.php erreichbar ist, die genannten Mitigationsmaßnahmen umsetzen und sämtliche Zugangsdaten rotieren, die durch das Auslesen von Konfigurationsdateien kompromittiert worden sein könnten.
