Le CERT/CC a publié un avis préoccupant concernant les failles Kaltura mwEmbed. Deux vulnérabilités non corrigées touchent la bibliothèque HTML5 de lecture vidéo mwEmbed. Selon les informations communiquées, un attaquant distant et non authentifié pourrait lire des fichiers arbitraires sur le serveur et exécuter du code sur celui-ci.
Le point le plus inquiétant est l’absence de correction disponible à ce stade. Le CERT/CC indique aussi que la coordination avec l’éditeur n’a pas abouti, ce qui laisse les administrateurs avec des recommandations de réduction du risque plutôt que des correctifs immédiats.
De quoi s’agit-il exactement ?
Les faiblesses sont suivies sous les identifiants CVE-2026-19913 et CVE-2026-19912. Elles proviennent d’un même mécanisme : une désérialisation non sécurisée dans l’endpoint mwEmbedLoader.php utilisé par mwEmbed. Cette logique est fournie par Kaltura à travers le lecteur mwEmbed et également distribuée via un composant mentionné comme html5lib.
Le CERT/CC précise qu’aucune authentification ni jeton de session Kaltura n’est nécessaire. La condition préalable mentionnée est avant tout l’accessibilité réseau de l’endpoint vulnérable.
Pourquoi c’est exploitable à distance sans compte ?
Le scénario décrit repose sur des paramètres HTTP exposés par mwEmbedLoader.php. L’attaque peut être déclenchée en manipulant des valeurs transmises au serveur, notamment via un paramètre appelé ServiceUrl.
Dans le cas de la première faille (CVE-2026-19913), ServiceUrl est accepté par l’endpoint et utilisé comme URL cible pour des requêtes à des API backend. Le client PHP Kaltura récupère la réponse et tente ensuite de la désérialiser via unserialize(), sans validation stricte de la source, ni du schéma, ni du contenu reçu.
Le résultat : si l’attaquant fournit une valeur de type file://, le serveur peut essayer de récupérer un fichier local plutôt qu’une réponse attendue d’API. La désérialisation échoue alors, mais une partie des octets bruts du fichier récupéré se retrouve renvoyée dans un message d’erreur, ce qui ouvre la voie à la lecture de contenu (selon les modalités décrites par le CERT/CC et l’étude du rapport).
De la lecture de fichiers à l’exécution de code
La deuxième vulnérabilité (CVE-2026-19912) exploite la même faiblesse de désérialisation, mais conduit cette fois à une exécution de code (RCE). Le CERT/CC explique que l’attaquant peut influencer une écriture sur disque via un paramètre uiconf_id.
Le mécanisme décrit : la valeur de uiconf_id est ajoutée à un chemin de dossier de cache sans nettoyage approprié. En incluant des séquences de traversée du type ../, l’attaquant pourrait tenter de faire sortir l’écriture du répertoire de cache prévu, afin de viser un emplacement accessible depuis le web.
Ensuite, en appelant directement le fichier ainsi déposé, il pourrait être exécuté par l’utilisateur du serveur web. Le rapport souligne que cette étape dépend du backend de cache configuré, notamment du stockage sur fichiers. Si la configuration n’utilise pas le backend fichier (par exemple si un mode memcache-only est en place), la chaîne exacte pourrait être atténuée, mais cela ne rend pas le déploiement sûr selon les explications du chercheur.
Portée : installations clients et hôtes partagés
Le CERT/CC indique que le point d’entrée vulnérable est exposé non seulement sur des installations de clients, mais aussi sur des hôtes de production partagés gérés par Kaltura. Plus précisément, comme l’endpoint est servi via une infrastructure de CDN multi-tenant, l’impact ne se limite pas à une instance isolée.
En d’autres termes, si un attaquant vise les hôtes partagés, plusieurs tenants pourraient être concernés dans le périmètre décrit par l’avis.
Aucune correction disponible : que faire maintenant ?
Le CERT/CC ne mentionne pas de correctif prêt à l’emploi. En conséquence, l’accent est mis sur des actions défensives visant à réduire la surface d’attaque.
Parmi les recommandations, on retrouve notamment :
- Bloquer ou supprimer l’endpoint au niveau du WAF, d’un proxy inverse ou d’une couche CDN, en particulier si des lecteurs mwEmbed “legacy” ne sont pas nécessaires.
- Mettre en place une liste d’autorisation (allow-list) stricte pour le paramètre ServiceUrl, afin d’autoriser uniquement l’hôte API backend légitime et de rejeter les schémas non HTTP(S).
- Rejeter des valeurs dangereuses pour uiconf_id : traversées de répertoires (../), chemins absolus, ou séparateurs de répertoires.
- Désactiver l’exécution PHP dans les répertoires de cache concernés.
- Limiter les connexions sortantes depuis le serveur applicatif, car le chemin d’exécution dépend de la capacité à récupérer une charge utile depuis l’extérieur (selon la description fournie).
- Faire une rotation des secrets présents dans la configuration exposée : mots de passe base de données, identifiants d’admin et de console, clés partenaires et clés API, en particulier dans les environnements où l’endpoint a été exposé.
Ce que le chercheur a rapporté
Le chercheur crédité, Gerjan Wemekamp, explique dans son travail technique comment l’escalade a été démontrée pour la lecture de fichiers. La méthode mentionnée consiste à récupérer un fichier de configuration à l’emplacement /opt/kaltura/app/configurations/local.ini, susceptible de contenir des chaînes de connexion et des éléments sensibles tels que des mots de passe et des références d’hôtes internes.
Le rapport précise aussi la transparence du périmètre : l’auteur détaille ce qui a été vérifié et ce qui n’a pas été montré de manière end-to-end sur tous les environnements.
Niveaux de gravité et présence dans les catalogues
D’après les informations disponibles, Wemekamp a attribué une sévérité de 10.0 à CVE-2026-19912 et de 9.1 à CVE-2026-19913, en qualité de “reporter-assigned”. Le CERT/CC indique ne pas avoir publié de score et précise qu’il n’y avait pas de trace dans le catalogue CISA KEV au 25 août 2026 (selon la date mentionnée dans l’avis).
Le CERT/CC note également l’absence d’entrée dans NVD pour ces identifiants au moment indiqué.
Versions concernées
L’avis liste des versions du composant html5lib touchées : v2.45, v2.103 et les versions antérieures, ainsi que d’autres déclinaisons de la branche v2.x exposant l’endpoint vulnérable.
Le chercheur a aussi vérifié une stabilité du fichier PHP contenant l’appel à unserialize() sur de nombreuses références de release publiques consultées, ce qui suggère que le code à risque est resté identique à travers plusieurs points de version.
Pourquoi ce cas rappelle d’autres incidents de désérialisation
Le CERT/CC rappelle implicitement un problème plus large : la désérialisation non sécurisée revient régulièrement dans des surfaces applicatives. Le texte mentionne qu’un retrait d’appels non sûrs a déjà été effectué à certaines périodes dans le codebase Kaltura, mais que dans ce cas précis, la désérialisation vulnérable n’apparaît pas avoir été corrigée.
Le document souligne aussi que d’autres technologies ont fait l’objet, la même année, d’attaques similaires, notamment via des failles de désérialisation dans des bibliothèques populaires.
Plan d’action recommandé pour les administrateurs
En pratique, si vous utilisez Kaltura mwEmbed (ou si vos lecteurs vidéo “legacy” reposent sur ces composants), la priorité est de couper l’accès public à l’endpoint à risque ou de le contenir strictement.
Voici une approche opérationnelle basée sur les conseils du CERT/CC :
- Commencez par identifier où mwEmbedLoader.php est accessible (internet direct, CDN, reverse proxy, WAF).
- Appliquez immédiatement un filtrage en entrée : allow-list de ServiceUrl, validation stricte et rejet des patterns dangereux pour uiconf_id.
- Renforcez les protections système : empêcher l’exécution PHP dans les répertoires de cache et réduire les flux sortants nécessaires à un éventuel chargement de payload.
- Si l’exposition a été confirmée, procédez à une rotation des secrets et auditez les journaux afin de comprendre s’il y a eu tentative d’exploitation.
Conclusion
Les failles Kaltura mwEmbed mises en avant par le CERT/CC combinent deux risques majeurs : lecture de fichiers et exécution de code à distance, sans authentification. En l’absence de correctif, la meilleure stratégie consiste à limiter immédiatement l’accès à l’endpoint, durcir la validation des paramètres et appliquer des mesures de confinement (cache, sorties réseau, rotation de secrets).
Si votre environnement exploite les versions mentionnées ou si l’endpoint a été exposé via une infrastructure partagée, agissez sans attendre pour réduire la probabilité d’exploitation.
Source: https://thehackernews.com/2026/08/unpatched-kaltura-mwembed-flaws-could.html
