Twee Kaltura mwEmbed kwetsbaarheden zetten het beveiligingsniveau van on-gepatchte HTML5-video-integraties onder druk. CERT/CC (CERT Coordination Center) waarschuwt dat een aanvaller, zonder authenticatie, via het mwEmbedLoader.php-endpoint zowel willekeurige bestanden kan uitlezen als code op de server kan uitvoeren. Het vervelende: er is (ten tijde van de melding) geen vaste oplossing beschikbaar.
In dit artikel zetten we uiteen wat er precies misgaat, welke voorwaarden CERT/CC noemt en welke praktische mitigaties beheerders kunnen uitvoeren om het risico te beperken.
Wat CERT/CC precies rapporteert
CERT/CC beschrijft twee niet-gepatchte kwetsbaarheden in Kaltura’s HTML5 video player library. Het gaat om:
- CVE-2026-19913: remote file read (bestanden uitlezen)
- CVE-2026-19912: remote code execution (code uitvoeren)
Beide problemen hebben dezelfde technische kern: een unsafe deserialization die plaatsvindt via het mwEmbedLoader.php-endpoint. Kaltura verspreidt deze loader ook als onderdeel van een html5lib-variant.
Volgens CERT/CC is er geen Kaltura-sessie of authenticatie nodig. Alleen netwerktoegang tot het betreffende endpoint is voldoende om de aanvalsketen te starten.
Waarom unsafe deserialization zo gevaarlijk is
Het misbruik draait om hoe de applicatie een parameter gebruikt als basis voor backend-aanroepen en daarna data verwerkt via PHP-constructies. In grote lijnen werkt het als volgt:
- De applicatie accepteert een parameter ServiceUrl en gebruikt die als doel-URL voor backend API requests.
- De client haalt de reactie op en geeft de inhoud door aan PHP’s unserialize(), zonder te valideren wat de bron is of wat de inhoud precies is.
Door die combinatie kan een aanvaller de input sturen op een manier die leidt tot het uitlezen van bestanden of, in het tweede scenario, tot code-uitvoering.
CVE-2026-19913: bestand uitlezen via ServiceUrl
Bij CVE-2026-19913 begint de aanval met de ServiceUrl-parameter. CERT/CC meldt dat mwEmbedLoader.php ServiceUrl gebruikt als target voor backend API requests.
Omdat de toepassing niet verifieert welke URL het werkelijk moet ophalen, kan de aanvaller een file://-pad meegeven. Daardoor probeert de server een lokaal bestand op te halen in plaats van een verwachte API-respons.
De deserialisatiepoging faalt vervolgens, maar de impact is al groot: CERT/CC geeft aan dat de raw bytes van het opgehaalde bestand terugkomen in een foutmelding die de aanvaller kan inzien.
Een onderzoeker, AndDone, beschreef in een technische write-up hoe hij in zijn verificatie de Kaltura-applicatieconfiguratie kon ophalen, waaronder plaintext databaseverbindingen en wachtwoorden. Welke exacte velden dat zijn, staat niet als generiek advies in de melding, maar wel als categorieën: database-strings, admin/console-passwords en interne hostreferenties.
CVE-2026-19912: van deserialization naar code execution
De tweede kwetsbaarheid (CVE-2026-19912) gebruikt dezelfde onveilige deserialisatie, maar zet die om naar remote code execution. Het verschil zit in de manier waarop een uiconf_id-parameter wordt verwerkt.
De uiconf_id-waarde wordt volgens CERT/CC appended aan een cachefolderpad zonder voldoende sanitatie wanneer de applicatie data opslaat op disk. Daardoor kan een aanvaller door middel van padtraversal:
- de write buiten de beoogde cache-map laten plaatsvinden
- richting een locatie sturen die webtoegankelijk is
- vervolgens een bestand direct laten uitvoeren door het webserver-proces
CERT/CC en de onderzoeker benadrukken daarnaast een belangrijk detail: het daadwerkelijke “file-drop” pad hangt af van een file-based cache backend. In een configuratie met alleen memcache kan de specifieke codepad-uitkomst mogelijk worden onderdrukt. Dat betekent echter niet dat de deployment veilig is—de onderliggende unsafe deserialization blijft immers aanwezig.
Geen patch, wel duidelijke randvoorwaarden
Ten tijde van de melding is er geen patch beschikbaar. CERT/CC stelt bovendien dat het niet lukte om Kaltura te bereiken voor coördinatie.
Ook meldt CERT/CC dat er op het moment van schrijven geen actieve exploitatie bekend was. Daarnaast staan de CVE’s op niet als gemarkeerd in CISA’s Known Exploited Vulnerabilities-catalogus (KEV), al was dat peilmoment specifiek op 25 augustus 2026.
Dat geeft misschien wat ademruimte, maar het is geen reden om achterover te leunen: als er geen patch is, moet je het systeem beveiligen met gerichte mitigaties.
Waarom dit niet alleen “jullie installatie” raakt
CERT/CC meldt dat de endpoint niet alleen bij individuele klanten kan voorkomen, maar ook wordt blootgesteld op Kaltura’s shared, multi-tenant CDN infrastructuur. Dat betekent dat een zwakke schakel in de loader gevolgen kan hebben voor meerdere tenants die via gedeelde hosts worden bediend.
Voor beheerders is dat een extra reden om meteen te checken of jullie omgeving (of een CDN/leverancierpad) die mwEmbedLoader.php endpoint extern bereikbaar maakt.
Mitigaties: wat je nu kunt doen
Omdat er geen vaste update klaarstaat, adviseert CERT/CC vooral om de aanvalsroutes te blokkeren en de invoer te beperken. Je kunt deze maatregelen als prioriteitenlijst zien.
- Blokkeer of verwijder het endpoint waar legacy mwEmbed players niet worden gebruikt. Denk aan WAF, reverse proxy of CDN-niveaus.
- Gebruik allow-listing voor ServiceUrl: sta alleen de API-host toe die bij de eigen deployment hoort. Weiger bovendien niet-HTTP(S)-schema’s.
- Valideer uiconf_id strikt: weiger traversal-sequenties, absolute paden en directory separators.
- Ontzeg PHP-uitvoering in cache directories. Daarmee verlaag je de kans dat een “file-drop” eindigt in code-executie.
- Beperk outbound netwerktoegang voor de applicatieserver. De code-uitvoeringsketen heeft volgens de melding behoefte aan netwerktoegang om een payload op te halen.
- Rotate secrets en credentials die mogelijk in local.ini zijn blootgesteld wanneer het endpoint ergens extern bereikbaar was. CERT/CC noemt database-credentials, admin/console-passwords, partner secrets en API keys.
Met name de combinatie van “endpoint afschermen” en “parameters hard valideren” is belangrijk: daarmee haal je de basis weg onder zowel file read als code execution.
Extra checks voor beheerders en ontwikkelteams
Als je deze melding doorzet naar je beheer- en developmentkolom, is het verstandig om breder te kijken dan alleen “is er een patch?”. Kaltura heeft eerder unsafe unserialize-punten verwijderd in andere perioden, maar hier ontbreekt nog een vaste fix. Daarom zijn defensieve controles noodzakelijk.
Praktische vervolgvragen die je intern kunt stellen:
- Wordt mwEmbedLoader.php extern aangeboden via CDN of reverse proxy, ook als “legacy embed” eigenlijk niet meer gebruikt wordt?
- Hoe hard is de validatie rond ServiceUrl en uiconf_id in de integratie? (Staat er een allow-list of wordt er alleen “gewoon doorgelaten”?)
- Is PHP uitvoering expliciet verboden in cache- of uploadpaden die als tussenstap kunnen dienen?
- Kunnen app-servers outbound verbindingen maken naar externe adressen, of staan er egress-restricties?
Dit soort lessen past ook bij bredere beveiligingsprincipes rondom inputvalidatie, deserialisatie en het beperken van externe blootstelling. Als je wil verdiepen in vergelijkbare risico’s in infrastructuur en detectie, kijk dan ook naar MFA-valkuil: authenticatie geen identiteit—niet omdat het dezelfde bug is, maar omdat het laat zien hoe “toegang” niet altijd hetzelfde is als “veiligheid”.
Wat betekent dit voor je prioriteit?
Zodra een systeem een kwetsbaarheid zonder patch heeft die zonder authenticatie kan leiden tot file read of RCE, verschuift het gesprek van “volgen” naar “mitigeren”. Zelfs als er op dat moment geen openbare exploitatie bekend is, blijft het potentiële impactniveau hoog.
CERT/CC’s advies is daarom vooral gericht op het verminderen van blootstelling (endpoint blokkeren) en het verkleinen van misbruikmogelijkheden (allow-listing en strikte parametervalidatie). Combineer dat met het veilig maken van cache-directories en het omdraaien van secrets als er aanleiding is dat de endpoint extern bereikbaar was.
Conclusie
De Kaltura mwEmbed kwetsbaarheden (CVE-2026-19913 en CVE-2026-19912) tonen hoe gevaarlijk unsafe deserialization kan zijn wanneer URL- en padparameters onvoldoende worden gevalideerd. Zonder authenticatie en zonder patch kunnen aanvallers bestanden uitlezen en in bepaalde omstandigheden zelfs code op de server uitvoeren.
De kern van de oplossing ligt nu bij beheermaatregelen: sluit het endpoint af waar het niet nodig is, voer allow-listing door voor ServiceUrl, beperk en valideer uiconf_id, voorkom PHP-executie in cachepaden en reduceer outbound verkeer. Ten slotte: roteer credentials als er sprake was van externe blootstelling.
Bron: https://thehackernews.com/2026/08/unpatched-kaltura-mwembed-flaws-could.html
