Der Ausgangspunkt für den Dateizugriff (CVE-2026-19913) ist der Parameter ServiceUrl, den mwEmbedLoader.php entgegennimmt und als Ziel-URL für Backend-API-Anfragen verwendet. Der PHP-Client KalturaClientBase holt ab, was diese URL zurückliefert, und übergibt das Ergebnis an PHPs unserialize() — ohne Herkunft, Schema oder Inhalt zu prüfen. Ein Pfad mit file:// bringt den Server dazu, statt einer API-Antwort eine lokale Datei zu laden. Die Deserialisierung scheitert, und die Rohbytes der geladenen Datei erscheinen in der resultierenden Fehlermeldung beim Anfragenden.
Gerjan Wemekamp, Forscher bei AndDone und als Melder beider Lücken genannt, beschrieb in einer technischen Veröffentlichung, wie er den Dateizugriff eskalierte: Er las die Kaltura-Konfiguration unter /opt/kaltura/app/configurations/local.ini aus, die Datenbank-Verbindungsdaten, Administrator- und Konsolenpasswörter im Klartext sowie interne Host-Verweise enthält.
Die zweite Lücke, CVE-2026-19912, macht aus derselben Deserialisierung eine Codeausführung — über den Parameter uiconf_id, der beim Schreiben auf die Festplatte ungeprüft an den Pfad des Cache-Ordners angehängt wird. Der Angreifer lässt ServiceUrl auf ein bösartiges serialisiertes Objekt mit ausführbarem PHP-Code zeigen; der Client lädt und deserialisiert es. Ein uiconf_id-Wert mit Traversal-Sequenzen wie ../ lenkt den Schreibvorgang aus dem vorgesehenen Cache-Verzeichnis in ein über das Web erreichbares um. Der direkte Aufruf dieser Datei führt sie mit den Rechten des Webserver-Nutzers aus.
„Der Schreibschritt hängt vom dateibasierten Cache-Backend ab, das bei Kaltura Standard ist. Eine reine Memcache-Konfiguration kann den Schreibvorgang und damit diesen konkreten RCE-Pfad unterbinden. Sicher ist die Installation dadurch aber nicht", so Wemekamp.
Zum Umfang seiner Nachweise äußerte sich der Forscher ausdrücklich: „Um beim Umfang genau zu sein: Das vollständige Ablegen einer Web-Shell habe ich am Docker-Image des Kaltura Servers von 2019 demonstriert. Am aktuellen Release habe ich verifiziert, dass beide Hälften der Kette vorhanden sind und dass die Deserialisierungs-Hälfte weiterhin wie beschrieben ausgeführt wird."
CERT/CC nennt als betroffen html5lib v2.45, v2.103 und früher sowie weitere 2.x-Versionen, die den verwundbaren Endpunkt bereitstellen. Wemekamp bewertete CVE-2026-19912 mit 10.0 und CVE-2026-19913 mit 9.1, kennzeichnete beide Werte aber als selbst vergeben. CERT/CC veröffentlichte keine Bewertung, und mit Stand 25. August 2026 existierte zu keinem der beiden Bezeichner ein NVD-Eintrag. NIST hatte im April erklärt, nicht mehr jede CVE anzureichern, sondern jene im KEV-Katalog, in der Bundesverwaltung eingesetzte Software sowie nach Executive Order 14028 als kritisch eingestufte Software zu priorisieren.
The Hacker News verglich am 25. August Kalturas öffentliches Server-Repository und stellte fest, dass deployment/uiconf/KalturaClientBase.php — die Datei mit dem unserialize()-Aufruf — über 21 Release-Referenzen hinweg byte-identisch ist, von Jupiter-10.9.0 (Commit vom 27. April 2015) bis West-23.5.0 (13. August 2026). Aufruf und Fehlermeldungs-Reflexion finden sich sogar schon in einer Release-Referenz vom 10. März 2014. Bereits im August 2017 hatte Kaltura, wenige Wochen vor einem Advisory von Telekom Security zu drei Plattformfehlern, drei unsichere unserialize-Aufrufe entfernt und die Probleme in Release 13.2.0 behoben — betroffen waren damals drei Dateien, KalturaClientBase.php war nicht darunter.
Da keine korrigierte Version verfügbar ist, empfiehlt CERT/CC Administratoren, den externen Zugriff auf den Endpunkt einzuschränken oder zu deaktivieren und für den Parameter ServiceUrl eine strikte Positivliste durchzusetzen, die ausschließlich legitime Backend-API-URLs zulässt.
Kalturas security.txt, zuletzt am 28. Mai 2024 aktualisiert, verweist auf ein Bug-Bounty-Programm bei HackerOne und nennt security@kaltura.com. Wemekamps Zeitleiste verzeichnet eine erste Meldung an einen Sicherheitskontakt des Herstellers am 23. März 2026, eine erneute Zusendung von einer Firmenadresse am 13. April, einen Kontaktversuch beim CISO über LinkedIn am 23. Mai und eine Eskalation über ein nationales CERT am 2. Juli. CERT/CC informierte Kaltura am 8. Juli; in der Meldung ist der Herstellerstatus für beide CVEs als unbekannt geführt, eine Stellungnahme liegt nicht vor.