Las vulnerabilidades Kaltura mwEmbed que ha divulgado CERT/CC son especialmente preocupantes por su combinación de impacto y simplicidad de acceso. Según el aviso, dos fallos en el reproductor HTML5 mwEmbed permiten a un atacante remoto, sin autenticación, leer archivos arbitrarios del servidor y, en un segundo caso, ejecutar código en el sistema afectado.
Además, no existe una versión corregida disponible al momento del reporte. Por eso, las recomendaciones se enfocan en reducir exposición de red, controlar parámetros sensibles y limitar el alcance de las rutas que el reproductor usa para comunicarse con servicios backend.
Qué vulnerabilidades son y por qué importan
CERT/CC describió dos fallos no parcheados identificados como CVE-2026-19913 y CVE-2026-19912. Ambos provienen del mismo problema base: una deserialización insegura relacionada con el endpoint mwEmbedLoader.php de la librería mwEmbed. Kaltura también distribuye esta librería como html5lib, por lo que el riesgo puede aparecer en diferentes despliegues que incluyan esos componentes.
El punto clave es que ninguna de las dos vulnerabilidades requiere autenticación ni un token de sesión de Kaltura. En otras palabras: si el atacante puede alcanzar el endpoint afectado a través de la red, ya tiene la condición previa principal indicada por CERT/CC.
Ausencia de parche y alcance en instalaciones y CDNs
En el momento del aviso, no había parche para instalar. CERT/CC también señaló que no pudo coordinarse con Kaltura para facilitar la respuesta coordinada a tiempo.
El alcance no se limita necesariamente a una instalación individual. CERT/CC advierte que el endpoint también se expone en infraestructuras compartidas de CDN con múltiples “tenant”. Eso significa que las vulnerabilidades Kaltura mwEmbed pueden afectar no solo a clientes con su propio despliegue, sino también a otros usuarios servidos por los mismos hosts compartidos.
Cómo funciona el fallo de lectura de archivos (CVE-2026-19913)
El problema de lectura arbitraria comienza con el parámetro ServiceUrl, que mwEmbedLoader.php acepta y luego utiliza como URL objetivo para realizar solicitudes a servicios backend.
Dentro del flujo descrito, la librería cliente en PHP (incluida en el paquete) obtiene lo que devuelva la URL y lo pasa directamente a PHP’s unserialize() sin validar la fuente, el esquema (por ejemplo, si es http/https) ni el contenido esperado.
El impacto se entiende así: si el atacante proporciona un esquema tipo file://, el servidor puede intentar acceder a un archivo local en lugar de tratarlo como respuesta de una API. Luego, aunque la deserialización falle, los bytes del archivo recuperado se reflejan de vuelta en el mensaje de error que recibe el solicitante.
Un aspecto relevante del reporte es que se trata de un mecanismo que filtra contenido de archivos, lo que convierte el endpoint en un vector para exponer datos sensibles sin necesidad de credenciales.
Demostración y datos potenciales: local.ini
En su análisis técnico, el investigador acreditado con la divulgación (Gerjan Wemekamp) indicó que escaló el escenario de lectura obteniendo el archivo de configuración de Kaltura ubicado en /opt/kaltura/app/configurations/local.ini.
Ese fichero, tal como se describe en el reporte, contiene información en texto plano como cadenas de conexión a bases de datos, contraseñas de administradores y de consola, así como referencias internas de host.
En conjunto, esto ilustra por qué CERT/CC considera el riesgo alto: no solo se trata de leer “algún archivo”, sino de potencialmente recuperar credenciales y rutas internas que luego facilitan ataques posteriores.
Cómo se convierte en ejecución remota de código (CVE-2026-19912)
El segundo fallo transforma el mismo tipo de deserialización insegura en ejecución de código mediante la manipulación de un parámetro adicional: uiconf_id.
De acuerdo con CERT/CC y el análisis del investigador, el valor de uiconf_id se concatena en la ruta de una carpeta de caché sin sanitización al escribir en disco. Esto abre la puerta a que el atacante inserte secuencias de recorrido de directorios (por ejemplo, ../), de modo que la aplicación escriba fuera del directorio previsto.
El paso final depende del backend de caché por archivos. Si el despliegue usa el valor por defecto (caché basada en archivos), el atacante puede redirigir la escritura a un directorio accesible desde la web y luego solicitar ese archivo para que el servidor lo ejecute con el usuario del servidor web.
El investigador también aclaró un matiz importante: aunque una configuración basada solo en memcache podría suprimir la escritura específica que habilita el camino de RCE, eso no vuelve seguro el despliegue. El problema de deserialización y los componentes de la cadena siguen siendo parte del riesgo.
Condiciones de explotación y dónde está expuesto el endpoint
Según CERT/CC, la única precondición de red es que el endpoint mwEmbedLoader.php sea accesible desde Internet u otra red donde esté el atacante. No se requiere cuenta, ni token, ni interacción autenticada.
Además, el reporte indica que la exposición puede estar presente tanto en instalaciones de clientes como en hosts de producción compartidos del propio proveedor. Esto aumenta la necesidad de inventario: organizaciones que usan Kaltura con reproductores legacy podrían no haber considerado que el endpoint aún está activo.
Versiones afectadas
CERT/CC listó afectación para html5lib v2.45, v2.103 y anteriores, y también menciona otras versiones 2.x que expongan el endpoint vulnerable.
Dado que el punto central es la presencia del endpoint y su flujo de deserialización, conviene validar no solo el número de versión, sino si el componente vulnerable se encuentra en el despliegue actual y si está accesible públicamente.
Mitigaciones recomendadas (sin parche disponible)
Mientras se espera una corrección, las recomendaciones se orientan a cortar el acceso al endpoint o reducir drásticamente lo que el sistema puede hacer con parámetros controlados por el atacante. CERT/CC y el análisis del investigador proponen medidas como las siguientes.
- Bloquear o eliminar el endpoint en WAF, reverse proxy o CDN cuando no se sirvan reproductores mwEmbed legacy.
- Aplicar allow-list a ServiceUrl, permitiendo únicamente el host/API del backend legítimo y rechazando esquemas que no sean HTTP/S.
- Rechazar uiconf_id que contenga secuencias de recorrido (../), rutas absolutas o separadores de directorio.
- Denegar la ejecución de PHP en directorios de caché. Esta capa reduce la probabilidad del paso final que habilita la RCE.
- Restringir el acceso saliente (egress) desde el servidor de aplicaciones, dado que el camino de ejecución necesita comunicación para recuperar el payload.
- Rotar credenciales asociadas al archivo local.ini expuesto donde el endpoint estuvo accesible: credenciales de base de datos, contraseñas de admin y consola, secretos de partners y claves de API.
En términos prácticos, estas acciones son un “plan por capas”: cortar acceso, validar entradas, reducir privilegios y asumir que un atacante pudo haber intentado enumerar o extraer información.
Prioridad y señales de explotación observadas
Al momento del reporte, no se indicaba que existiera explotación documentada. Además, el reporte señala que los identificadores CVE no aparecían en el catálogo CISA KEV al 25 de agosto de 2026.
Con todo, el hecho de que el fallo sea no autenticado y que pueda llegar a datos sensibles o incluso código ejecutable significa que la ventana de exposición no debe minimizarse solo por la falta de evidencia pública de ataques.
Por qué la deserialización insegura vuelve a aparecer
El reporte contextualiza que Kaltura ya había eliminado llamadas inseguras a unserialize en el pasado. Sin embargo, se indica que el problema de deserialización insegura sin una corrección disponible puede reaparecer en otros componentes o ramas.
El mensaje para equipos de seguridad es claro: cuando un flujo “deserializa lo que viene de la red” sin validaciones estrictas, la superficie de ataque se amplía de manera severa, especialmente si además existe la posibilidad de reflejar errores o de escribir en rutas controlables.
Qué hacer ahora si usas mwEmbed o html5lib
Si tu organización utiliza reproductores relacionados con mwEmbed o librerías html5lib de Kaltura, la prioridad es reducir riesgo de inmediato. Empieza con un inventario: identifica si el endpoint vulnerable está presente y si está expuesto a Internet.
Luego, aplica mitigaciones en el orden más efectivo: bloqueo del endpoint cuando sea viable, allow-list estricta de ServiceUrl, validación y rechazo del parámetro uiconf_id, endurecimiento de permisos sobre directorios de caché y control de tráfico saliente.
Finalmente, asume impacto potencial y realiza rotación de secretos si hubo exposición: si el endpoint estuvo accesible, es prudente tratarlo como un incidente hasta descartar filtraciones.
Conclusión
Las vulnerabilidades Kaltura mwEmbed descritas por CERT/CC muestran cómo una única decisión de diseño—deserializar entradas no confiables—puede escalar rápidamente de lectura de archivos a ejecución remota de código. Como no hay parche disponible en el reporte, las acciones más urgentes pasan por restringir el endpoint, controlar estrictamente parámetros y rotar credenciales potencialmente expuestas.
Si administras instalaciones con mwEmbed legacy o distribuciones que exponen el endpoint mencionado, actúa con rapidez: la ausencia de autenticación y la accesibilidad de red hacen que el riesgo sea real incluso sin señales públicas de explotación.
Fuente: https://thehackernews.com/2026/08/unpatched-kaltura-mwembed-flaws-could.html
