Plex ha confirmado que las vulnerabilidades de Plex Media Server publicadas en septiembre «están siendo explotadas de forma activa y amplia». La frase es literal y está en su aviso de seguridad, actualizado el 19 de octubre. Encadenados, los fallos permiten a un atacante remoto sin autenticar ejecutar código con los privilegios del proceso del servidor.
Lo llamativo no es el aviso. Es que la versión corregida está disponible desde principios de agosto y, el día antes de que la cadena se hiciera pública, alrededor de un tercio del parque seguía siendo vulnerable.
¿Qué hay que hacer, en una línea?
Actualizar a Plex Media Server 1.43.3.10861 o posterior. La versión se comprueba en Ajustes → General de Plex Web. En Plex Desktop, la corrección va en la 1.115.0.
Hay una trampa que conviene conocer: la build 1.43.3.10828 parece de la serie corregida y no lo es. Según la telemetría de Censys, unos 8.000 servidores corren precisamente esa.
Plex advierte de que en NAS puede hacer falta instalación manual si el repositorio del fabricante va con retraso, y cita a QNAP, Terramaster, Western Digital, Netgear y Synology. En Windows y macOS, conviene verificar que las actualizaciones automáticas funcionan. Y si no necesitas acceso remoto, la recomendación es desactivarlo en Ajustes → Acceso Remoto y no abrir el puerto 32400 en el router salvo necesidad.
¿Cuáles son las vulnerabilidades?
Cuatro, según Plex. Cinco, según el NVD del NIST y el aviso que CISA coordinó el 23 de septiembre, que añade una más que la compañía no menciona.
La más grave es CVE-2026-96656, un control externo de nombre y ruta de ficheros que permite escribir archivos que se cargan al arrancar: 7,2 en CVSS 3.1 y 8,6 en CVSS 4.0. Las otras tres son dos fallos de petición del lado del servidor (Plex llama a uno «sin autenticar»; el NVD atribuye privilegios bajos a los dos) y una neutralización indebida de esquemas de URI que permite invocar funciones de otros plugins. La quinta, CVE-2026-96651, es un salto de directorio que permite a un atacante que ya disponga de un token de sesión válido leer cualquier fichero accesible al usuario, incluido el token de cuenta de Plex, que da control de la cuenta y del servidor.
Un detalle que la prensa está mezclando: las puntuaciones que circulan parecen contradecirse pero no lo hacen, son escalas distintas. Y hay otra divergencia real: lo que Plex escribe el 19 de octubre no coincide con el NVD al asignar cada fallo a su identificador, aparentemente porque Plex omite el quinto y desplaza la numeración.
Por separado, algunos de los fallos requieren privilegios, incluso de administrador. Encadenados, ninguno. Todos tienen vector de red: no hace falta estar en la red local.
¿Por qué ha pasado ahora?
Por la cronología, que es la verdadera noticia. El fallo se reportó el 27 de julio y Plex lo confirmó y pagó la recompensa el 4 de agosto, el mismo día en que, según Censys, la build corregida aparece en su telemetría. El aviso público llegó cuatro semanas después, el 1 de septiembre, sin detalle técnico. Los identificadores CVE se publicaron el 23 de septiembre.
El 16 de octubre se publicó un análisis técnico detallado con prueba de concepto. Al día siguiente por la mañana se observó la primera explotación en un señuelo. El 19, Plex confirmó la explotación activa. El 20, CISA metió los cuatro fallos en su catálogo de vulnerabilidades explotadas, con plazos muy cortos para la administración estadounidense: 23 de octubre para dos de ellos y 3 de noviembre para los otros dos, con requisitos de análisis forense para el más grave.
Las cifras de parcheo explican el resto. Censys observa unos 324.000 servidores Plex expuestos, de los que alrededor del 30 % corre una versión vulnerable. Un 30 % actualizó en la primera semana tras el parche; la mitad seguía vulnerable cuando Plex publicó su aviso de septiembre; y en los tres días siguientes a la publicación de la cadena, menos del 2 % de los que aún eran vulnerables se actualizó. Estados Unidos concentra el 44 % de los servidores, y las redes más representadas son operadores de banda ancha residencial.
Importante no confundir magnitudes: esas cifras son de exposición y de parque vulnerable, no de víctimas. Nadie ha publicado un número de servidores comprometidos, y Plex tampoco.
¿Qué hacen los atacantes con el servidor?
Minar y vender tu conexión. Los payloads observados son un minero basado en XMRig y software de proxy, y la motivación es evidente si se piensa dónde vive un servidor Plex: en una conexión doméstica. «Plex puede estar alojado en una IP residencial y creo que a los actores de amenazas les encantaría tener un proxy de IP residencial», escribió el investigador que detectó la primera explotación, según recoge SecurityWeek. El software de proxy lo dice sin rodeos en sus propias condiciones: usarlo implica aceptar «el posible uso externo de tu tráfico de internet».
Plex publica indicadores para comprobar si tu servidor está comprometido: procesos desconocidos lanzados por Plex Media Server con nombres llamativos, ficheros .so o .dll desconocidos en la carpeta Codecs, conexiones salientes a un dominio concreto que recoge su aviso, y uso de CPU alto y sostenido sin que haya nada reproduciéndose. El investigador del señuelo advierte de que esos indicadores reflejan solo lo que él vio, así que pueden no cubrir todos los casos.
Si hay indicios de compromiso, o no se pueden descartar, la recomendación de Plex es dura pero sensata: reconstruir desde una instalación limpia sin reutilizar el directorio de datos anterior. Como mínimo, vaciar la carpeta Codecs, revisar el fichero de preferencias buscando opciones que no hayas configurado, cerrar sesión en todos los dispositivos, cambiar la contraseña y dar por expuesto todo aquello a lo que la cuenta de servicio de Plex tenía acceso: recursos compartidos montados, credenciales guardadas.
El descubrimiento se acredita a Zach Main, el investigador de seguridad que reportó los fallos a Plex el 27 de julio. Y un detalle que dice bastante del sector: el aviso de Plex lo firma la cuenta institucional del foro. No hay ningún directivo ni portavoz con nombre al que atribuir nada.
Mi lectura es que el problema aquí no es Plex, es el modelo. Una cadena de cuatro fallos encadenados hasta la ejecución remota sin autenticar es grave, pero se reportó de forma responsable, se pagó la recompensa y se parcheó en ocho días. Eso es un buen expediente. Lo que falla es todo lo que viene después: un software autoalojado en los 324.000 servidores que ve Censys, en buena parte conexiones domésticas, en NAS que dependen del ritmo del fabricante, con dueños que no leen foros de seguridad. El atacante no necesitó encontrar un fallo nuevo, le bastó esperar diez semanas a que alguien publicara el análisis.
Y conviene ponerlo en contexto: este incidente no tiene relación documentada con la brecha de datos que sufrió Plex en septiembre de 2025 ni con el hackeo de 2022. Aquellos fueron robos de información de cuentas en los sistemas de la empresa; esto es software que corre en tu casa. Pero la lección se repite, y es la misma que vale para cualquier NAS: un dispositivo expuesto a internet sin actualizar es un objetivo, por mucho que su única misión sea servirte películas.
☞ El artículo completo original de Natalia Polo lo puedes ver aquí
No hay comentarios.:
Publicar un comentario