Kaltura senza patch: RCE e file read in mwEmbed, nessuna patch…

CERT/CC ha divulgato due vulnerabilità critiche non patchate in Kaltura mwEmbed che permettono RCE e lettura arbitraria di file. Il vendor risulta irraggiungibile

Il CERT Coordination Center ha reso pubblico il 25 agosto 2026 due difetti critici nella libreria HTML5 mwEmbed di Kaltura che consentono esecuzione remota di codice e lettura arbitraria di file senza autenticazione. Non è disponibile alcuna patch ufficiale. Kaltura, contattata ripetutamente dal ricercatore Gerjan Wemekamp e dal CERT/CC dal marzo 2026, non ha risposto alle segnalazioni, lasciando l'exploit chain documentata e riproducibile aperto su oltre 600 istanze esposte.

Punti chiave

CVE-2026-19912 (RCE) e CVE-2026-19913 (arbitrary file read) derivano da unsafe deserialization in mwEmbedLoader.php tramite PHP unserialize() senza validazione di source, scheme o contenuto.
L'attacco non richiede autenticazione né token Kaltura: basta accesso di rete all'endpoint, esposto anche sull'infrastruttura CDN multi-tenant condivisa del vendor.
Il codice vulnerabile in KalturaClientBase.php è byte-identico in 21 release dal 2015 al 13 agosto 2026, con la chiamata unserialize() presente dal 2014.
Nessuna exploitation attiva è stata riportata al momento della divulgazione; nessuno dei due CVE compare nel catalogo CISA Known Exploited Vulnerabilities.

La catena d'attacco: da file read a web shell in due passaggi

Il nucleo tecnico è un'unsafe deserialization nel file KalturaClientBase.php, invocata da mwEmbedLoader.php. Il client PHP recupera un URL esterno e lo passa direttamente a unserialize() senza verificare origine, schema o contenuto.

Il primo anello, CVE-2026-19913, sfrutta il parametro ServiceUrl. Secondo il record NVD, l'endpoint accetta schemi non-HTTP come file://. Quando il client recupera un file locale, la deserializzazione fallisce e i byte raw vengono riflessi nel messaggio di errore, permettendo la lettura arbitraria di file sensibili come local.ini con credenziali database.

Il secondo anello, CVE-2026-19912, agisce sul parametro uiconf_id. Il valore viene concatenato al percorso della directory di cache senza sanitizzazione. Un attaccante può inserire sequenze di directory traversal come ../ per reindirizzare la scrittura del file fuori dalla cache, in una directory accessibile via web. A questo punto, ServiceUrl punta a un oggetto serializzato malevolo che viene scritto come web shell ed eseguito dal server.

La combinazione dei due passaggi permette RCE come utente del web server, con impatto immediato su istanze self-hosted e sui tenant della CDN condivisa di Kaltura.

"Because the affected endpoint is also exposed on Kaltura's shared, multi-tenant CDN infrastructure, these vulnerabilities affect not only individual customer installations, but also every tenant served by these shared hosts" — CERT/CC VU#308749

La timeline di un ghosting: cinque mesi di coordinated disclosure nel vuoto

La divulgazione coordinata è iniziata il 23 marzo 2026, quando Gerjan Wemekamp di AndDone ha inviato il primo report a Kaltura. Nella timeline documentata da The Hacker News, il ricercatore ha re-inviato il report il 13 aprile, ha contattato il CISO via LinkedIn il 23 maggio, ed è escalato attraverso un national CERT il 2 luglio. Il CERT/CC ha notificato Kaltura l'8 luglio. Nessuna risposta è arrivata. Il 25 agosto 2026, con le vulnerabilità ancora senza patch, il CERT/CC ha proceduto alla divulgazione pubblica.

L'aspetto sistemico è qui: il coordinated disclosure funziona solo se entrambe le parti sono raggiungibili. Il security.txt di Kaltura conferma un canale HackerOne, ma non emerge dal dossier se il ricercatore abbia utilizzato quella via formale o se i report iniziali siano stati ricevuti dal team corretto. Ciò che è documentato è l'assenza di risposta sui canali effettivamente percorsi.

600 istanze esposte e un codice vecchio di dodici anni

La persistenza del difetto è eclatante. The Hacker News ha verificato che il codice vulnerabile è byte-identico in 21 release reference, da Jupiter-10.9.0 (27 aprile 2015) a West-23.5.0 (13 agosto 2026). La chiamata unserialize() risale al 10 marzo 2014. Kaltura aveva rimosso altre chiamate unsafe nel 2017, con la release 13.2.0, ma non quella in KalturaClientBase.php.

Per quanto riguarda l'esposizione, Rescana e Kobaran convergono su oltre 600 istanze esposte su internet, identificate tramite ricerca su motori di ricerca. Queste includono installazioni self-hosted e quelle sull'infrastruttura CDN multi-tenant di Kaltura. Non è tuttavia chiara la metodologia esatta di conteggio né la distribuzione geografica delle istanze.

Wemekamp ha assegnato punteggi CVSS 10.0 a CVE-2026-19912 e 9.1 a CVE-2026-19913; questi sono reporter-assigned, non ufficiali NVD. Per CVE-2026-19913, il National Vulnerability Database pubblica un CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N pari a 7.5 HIGH. Per CVE-2026-19912, il NVD non ha ancora pubblicato un punteggio ufficiale.

Cosa fare adesso

Le mitigazioni documentate dalle fonti primarie sono parziali e non sostituiscono una patch. Le azioni prioritarie indicano:

Verificare se l'organizzazione espone mwEmbedLoader.php su installazioni Kaltura self-hosted o su CDN condivisi, con scansione degli endpoint pubblici.
Applicare restrizioni di accesso all'endpoint mwEmbedLoader.php dove tecnicamente fattibile, limitando la superficie di attacco.
Valutare configurazioni di caching alternative: secondo il ricercatore, una configurazione memcache-only può sopprimere il percorso RCE basato su scrittura file, ma non elimina la vulnerabilità sottostante di deserialization.
Monitorare i log per richieste sospette a mwEmbedLoader.php con parametri ServiceUrl o uiconf_id anomali, incluse sequenze di traversal e schemi non-HTTP.

Perché il caso Kaltura interroga la supply chain software

L'incidente non è solo tecnico. Kaltura è una piattaforma video enterprise adottata da università, broadcaster e grandi organizzazioni. La scoperta di un difetto così elementare — unserialize() senza validazione — in un componente core usato per più di un decennio, solleva interrogativi sulla maturità del security engineering del vendor.

Il fallimento del coordinated disclosure, poi, aggiunge una dimensione contrattuale. Le organizzazioni che pagano licenze enterprise si aspettano un canale di risposta alle vulnerabilità. Quando quel canale non produce risposta in cinque mesi, il rischio si trasferisce interamente sul lato acquirente, senza strumenti per mitigarlo efficacemente. Non emerge dal dossier che Kaltura abbia ignorato deliberatamente i report; ciò che è stabilito è che i canali percorsi non hanno generato alcun engagement.

Il ricercatore ha precisato i limiti del proprio test: il drop completo di web shell è stato dimostrato sull'immagine Docker Kaltura Server del 2019; sulla release corrente ha verificato che entrambe le metà della catena sono presenti e la parte di deserialization è ancora eseguibile come descritto. Questo significa che la proof-of-concept è riproducibile, anche se la configurazione specifica dell'obiettivo ne modula l'impatto.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter