veilletech.frCe qui se passe
Le CERT Coordination Center publie deux vulnérabilités dans mwEmbed, la
bibliothèque de lecteur vidéo HTML5 de Kaltura, également distribuée sous le nom
html5lib. Les deux partent de la même désérialisation non sûre exposée par le
point d'entrée mwEmbedLoader.php.
Versions touchées : html5lib v2.45, v2.103 et antérieures, ainsi que les autres versions 2.x qui exposent ce point d'entrée. Aucune authentification, aucun jeton de session : le seul prérequis est d'atteindre l'URL.
Le mécanisme, un paramètre à la fois
CVE-2026-19913 — lecture de fichiers. Le paramètre ServiceUrl sert d'URL
cible pour les appels à l'API. Le client KalturaClientBase récupère ce que
l'URL retourne et le passe à unserialize() sans vérifier ni la source, ni le
schéma, ni le contenu. Une valeur en file:// fait donc lire un fichier local ;
la désérialisation échoue, et les octets bruts du fichier sont renvoyés dans le
message d'erreur. Le chercheur a exploité ce chemin pour lire
/opt/kaltura/app/configurations/local.ini : chaînes de connexion à la base en
clair, mots de passe d'administration et de console, hôtes internes.
CVE-2026-19912 — exécution de code. Même désérialisation, second paramètre :
uiconf_id est concaténé au chemin du dossier de cache sans assainissement. Un
ServiceUrl pointant vers un objet sérialisé malveillant, un uiconf_id
contenant des ../, et l'écriture atterrit hors du cache, dans un répertoire
servi par le web. Une requête sur ce fichier l'exécute avec les droits du serveur
web.
Cette seconde moitié dépend du cache sur fichiers, qui est le réglage par défaut de Kaltura. Une configuration uniquement memcache peut supprimer l'écriture — sans rendre l'installation sûre pour autant.
Pourquoi ça compte
Trois raisons, dans l'ordre.
Le point d'entrée est aussi exposé sur l'infrastructure CDN mutualisée de Kaltura : tous les clients servis par ces hôtes partagés sont concernés, pas seulement les installations autonomes.
Le code est ancien. The Hacker News a vérifié que
deployment/uiconf/KalturaClientBase.php, le fichier qui porte l'appel à
unserialize(), est identique octet pour octet sur 21 références de version,
de Jupiter-10.9.0 (27 avril 2015) à West-23.5.0 (13 août 2026). L'appel et la
réflexion dans le message d'erreur existent depuis une version de mars 2014.
Enfin, personne ne répond. La note du CERT/CC dit les choses en trois mots — « unable to reach Kaltura » — et la divulgation se fait donc sans coordination avec l'éditeur. Le chercheur Gerjan Wemekamp, d'AndDone, a signalé le problème le 23 mars 2026, puis passé par le CERT/CC le 8 juillet. Publication le 26 août, sans éditeur en face.
Ce qu'on peut faire aujourd'hui
- Bloquer ou supprimer le point d'entrée au niveau du WAF, du reverse proxy ou du CDN si vous ne servez plus de lecteur mwEmbed historique
- Restreindre
ServiceUrlà l'hôte d'API du déploiement, et rejeter tout schéma qui n'est pas HTTP(S) - Rejeter les
uiconf_idcontenant une traversée, un chemin absolu ou un séparateur de répertoire - Interdire l'exécution de PHP dans les répertoires de cache
- Restreindre le réseau sortant du serveur applicatif : la chaîne d'exécution en a besoin pour récupérer sa charge utile
- Faire tourner tous les secrets de
local.inipartout où le point d'entrée a été exposé
Source : The Hacker News · note de vulnérabilité CERT/CC VU#308749 · analyse technique de Gerjan Wemekamp