El CERT Coordination Center (CERT/CC) ha publicado información sobre dos vulnerabilidades sin corregir en la biblioteca del reproductor de vídeo HTML5 de Kaltura, que permiten a un atacante remoto no autenticado leer archivos arbitrarios desde el servidor y ejecutar código en él. Las vulnerabilidades se rastrean como CVE-2026-19913 (lectura arbitraria de archivos) y CVE-2026-19912 (ejecución remota de código). No existe parche: según CERT/CC, el centro de coordinación no logró ponerse en contacto con Kaltura para una divulgación coordinada. El problema afecta no solo a instalaciones individuales, sino también a la infraestructura CDN multitenant del proveedor, a través de la cual se atiende a todos los clientes en hosts compartidos. Se recomienda a los administradores bloquear de inmediato el acceso al endpoint vulnerable y rotar todas las credenciales.
Detalles técnicos de las vulnerabilidades
Ambas vulnerabilidades se originan en una deserialización insegura en el endpoint mwEmbedLoader.php de la biblioteca mwEmbed (también distribuida como html5lib). Según CERT/CC, ninguna de las vulnerabilidades requiere autenticación ni un token de sesión de Kaltura: la única condición para su explotación es el acceso de red al endpoint.
CVE-2026-19913 — lectura arbitraria de archivos
El endpoint mwEmbedLoader.php acepta el parámetro ServiceUrl y lo utiliza como URL de destino para las solicitudes al backend del API. El cliente PHP KalturaClientBase obtiene el contenido de la URL indicada y lo pasa a la función unserialize() sin validar el origen, el esquema ni el contenido. Si el atacante introduce una ruta con el esquema file://, el servidor lee un archivo local en lugar de la respuesta del API. La deserialización termina con un error, y el contenido sin procesar del archivo se devuelve en el mensaje de error. El investigador Gerjan Wemekamp, de AndDone, quien describió ambas vulnerabilidades en un informe técnico, asignó a esta vulnerabilidad una puntuación CVSS de 9.1 (puntuación del investigador, no de NVD).
CVE-2026-19912 — ejecución remota de código
La segunda vulnerabilidad convierte esa misma deserialización en un vector de ejecución de código a través del parámetro uiconf_id. Este parámetro se añade a la ruta del directorio de caché sin saneamiento al escribir en disco. El atacante dirige ServiceUrl hacia un objeto serializado malicioso con código PHP ejecutable. El cliente lo recupera y lo deserializa. El valor de uiconf_id, que contiene secuencias de traversal de directorios (por ejemplo, ../), redirige la escritura fuera del directorio de caché hacia una ubicación accesible vía web. Una petición directa a ese archivo provoca su ejecución bajo la cuenta del servidor web. El investigador asignó a esta vulnerabilidad una puntuación CVSS de 10.0.
Según Wemekamp, la fase de escritura de archivos depende del backend de caché basado en archivos, que es la configuración predeterminada de Kaltura. Una configuración que utilice únicamente memcache puede suprimir la escritura y, en consecuencia, este camino concreto hacia la RCE; sin embargo, ello no hace que el despliegue sea seguro.
Versiones afectadas: según CERT/CC, son vulnerables html5lib v2.45, v2.103 y anteriores, así como otros lanzamientos v2.x en los que esté disponible el endpoint vulnerable. Ninguna de las dos CVE figura en el catálogo CISA KEV a fecha de 25 de agosto de 2026. A esa misma fecha no existían entradas en NVD para ninguno de los identificadores. CERT/CC no ha publicado sus propias puntuaciones CVSS.
Estado de explotación: no se ha confirmado explotación activa in the wild, aunque el informe técnico público del investigador contiene de facto una descripción suficiente para reproducir el ataque. La cadena completa, incluyendo la colocación de una web shell, se demostró sobre una imagen Docker de Kaltura Server de 2019; el investigador afirmó que en la versión actual ambos componentes de la cadena están presentes y la deserialización se realiza tal como se describe.
Alcance del impacto y contexto histórico
Lo que agrava especialmente la situación es la arquitectura de despliegue de Kaltura. Tal como señala CERT/CC, el endpoint vulnerable está disponible no solo en instalaciones individuales de clientes, sino también en la infraestructura CDN multitenant compartida del proveedor. Esto significa que una posible intrusión afecta potencialmente a todos los inquilinos atendidos a través de esos hosts compartidos.
Resulta llamativo que Kaltura ya haya abordado problemas de deserialización insegura en el pasado. En agosto de 2017, la empresa eliminó tres llamadas inseguras a unserialize y publicó una corrección en la versión 13.2.0. Sin embargo, ese commit afectó a tres archivos, ninguno de los cuales era KalturaClientBase.php, el archivo que contiene la vulnerabilidad actual. Según la fuente original, la llamada a unserialize() en ese archivo es idéntica a lo largo de 21 versiones: desde Jupiter-10.9.0 (abril de 2015) hasta West-23.5.0 (agosto de 2026), y apareció por primera vez ya en marzo de 2014.
Fracaso de la divulgación coordinada
La cronología de los intentos de contactar con el proveedor, descrita por el investigador, es la siguiente: el primer informe se envió el 23 de marzo de 2026, un reenvío desde una dirección corporativa el 13 de abril, un acercamiento al CISO del proveedor a través de LinkedIn el 23 de mayo y una escalada a través del CERT nacional el 2 de julio. CERT/CC notificó a Kaltura el 8 de julio. El estado del proveedor para ambas CVE en el registro de CERT/CC figura como «Unknown»: no se recibió respuesta alguna. Mientras tanto, el archivo security.txt de Kaltura (última actualización: 28 de mayo de 2024) dirige los reportes de vulnerabilidades al programa de bug bounty en HackerOne e indica la dirección [email protected].
Recomendaciones de mitigación
Ante la ausencia de un parche, CERT/CC y el investigador recomiendan las siguientes medidas defensivas:
- Bloquear o eliminar el endpoint
mwEmbedLoader.phpa nivel de WAF, proxy inverso o CDN, especialmente si no se utilizan reproductores mwEmbed obsoletos. - Configurar una lista de valores permitidos para
ServiceUrl, aceptando únicamente el host del API propio del despliegue y rechazando esquemas distintos de HTTP(S). - Rechazar valores de
uiconf_idque contengan secuencias de traversal de directorios, rutas absolutas o separadores de directorios. - Prohibir la ejecución de PHP en los directorios de caché.
- Restringir el acceso de red saliente desde el servidor de aplicaciones: la ruta hacia la ejecución de código requiere descargar la carga útil desde el exterior.
- Rotar todos los secretos de
local.inien las instalaciones donde el endpoint haya estado accesible: credenciales de base de datos, contraseñas de administrador y consola, secretos de partners y claves de API.
El caso de Kaltura es un ejemplo claro de cómo la falta de respuesta del proveedor transforma una divulgación coordinada en un zero‑day de facto. El código vulnerable existe en la base de código desde hace más de 12 años, la descripción pública de la explotación está disponible y no hay parche. Las organizaciones que utilicen Kaltura —ya sea en una instalación propia o como servicio en la nube— deben comprobar de inmediato la accesibilidad del endpoint mwEmbedLoader.php, aplicar las medidas de mitigación enumeradas y rotar todas las credenciales que puedan haberse visto comprometidas mediante la lectura de archivos de configuración.
