Plex2Shell: cadena de exploits en Plex explotada en un día

El 16 de octubre, el investigador Zach Main publicó el análisis técnico y el código de prueba de concepto de Plex2Shell, una cadena de cuatro vulnerabilidades de Plex Media Server que permite ejecutar código en un servidor expuesto sin credenciales válidas. La mañana del 17 de octubre, un honeypot de Plex vulnerable gestionado por otro investigador registró los primeros ataques reales: los atacantes instalaron un minero de criptomonedas basado en XMRig y, más tarde, un programa proxy.

Las correcciones existen desde septiembre. Si todavía no has actualizado, sobre todo si tu servidor es accesible desde internet, hazlo ahora: SecurityWeek, Security Affairs, Ars Technica y el aviso de KISA/KrCERT coinciden en que la actualización es la prioridad.

Cronología

• 27 de julio: los fallos se comunican a Plex;
• 4 de agosto: Plex los confirma y paga una recompensa (bug bounty);
• principios de septiembre: salen las versiones corregidas; según SecurityWeek, el 1 de septiembre Plex anuncia que ya ha distribuido las correcciones y pide actualizar;
• 16 de octubre: publicación del análisis y del PoC;
• 17 de octubre: primera explotación observada en el honeypot;
• 20 de octubre: aviso de actualización de KISA/KrCERT.

Detalles técnicos

La cadena usa CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 y CVE-2026-96656. El aviso coreano incluye en la misma actualización también CVE-2026-96651, y Ars Technica confirma que se publicaron cinco CVE, una con una puntuación de 8.6 sobre 10. Los tipos, según KISA/KrCERT:

• CVE-2026-96651: path traversal;
• CVE-2026-96652 y CVE-2026-96655: server-side request forgery (SSRF);
• CVE-2026-96654: neutralización incorrecta de esquemas URI codificados en una página web;
• CVE-2026-96656: control externo del nombre o de la ruta de un archivo.

Versiones afectadas: Plex Media Server anteriores a la 1.43.3.10861. Corregidas: 1.43.3.10861 y posteriores.

Según el desglose que recoge Ars Technica, el exploit avanza por pasos: una SSRF sin autenticación, un pivote a través de la interfaz de loopback, el robo de un token de seguridad, la entrega del payload y, por último, su ejecución. Security Affairs, citando el análisis original, describe el último paso: un ajuste relacionado con la transcodificación permite escribir una biblioteca compartida en la carpeta de códecs. El cargador de Plex no comprueba el nombre, el permiso de ejecución, la firma ni los símbolos de la biblioteca; como dlopen ejecuta los constructores ELF (DT_INIT_ARRAY) antes de resolver los símbolos, basta una segunda transcodificación para que la carpeta se vuelva a leer y el código se ejecute con el usuario del servicio (uid=1000(plex) en el PoC).

Las fuentes hablan de ejecución «si se cumplen las condiciones necesarias», sin enumerarlas todas: en la práctica, el mayor riesgo afecta a los servidores accesibles desde fuera. El investigador declaró que usó mucho un modelo de lenguaje para encontrar y encadenar los fallos, aunque las decisiones las tomó él.

Técnicas MITRE ATT&CK correspondientes (asignación nuestra): T1190 Exploit Public-Facing Application, T1129 Shared Modules, T1496 Resource Hijacking, T1090 Proxy.

Qué instalaron los atacantes

La información procede de un solo honeypot, como subraya el propio investigador:

• un minero de criptomonedas basado en XMRig;
• más tarde, ese mismo día, un programa llamado myawesomeproxy, un software proxy que muestra un aviso según el cual quien lo ejecuta acepta que otros usen su conexión.

El investigador advierte de que los datos son parciales: el honeypot no permitía tráfico de salida y algunos payloads no se descargaron. Los atacantes usaron el exploit público, quizá modificado. Los indicadores publicados solo valen para la actividad vista en el honeypot; ninguna fuente estima cuántos servidores reales se han visto comprometidos ni atribuye los ataques.

Por qué también afecta a las empresas

Plex nace para el uso doméstico, pero también se instala en NAS, máquinas virtuales y contenedores Docker (Security Affairs los cita todos entre las instalaciones que hay que actualizar): por eso puede estar en una pequeña oficina o en la red doméstica de quien teletrabaja. El punto más delicado es el proxy: como escribe el investigador, un servidor Plex con una dirección IP residencial es valioso para quien quiere llegar a VPN y correo corporativos desde direcciones que parecen legítimas y superan los filtros de reputación y geolocalización.

Para las entidades sujetas a NIS2, un servidor comprometido en la red corporativa debe evaluarse como posible incidente significativo, con notificación al CSIRT nacional si se dan las condiciones. También conviene revisar los accesos a VPN y correo desde IP residenciales inusuales.

Qué hacer ya

1. Inventario: busca instancias de Plex Media Server en servidores, NAS, máquinas virtuales y contenedores Docker, incluidas las instaladas al margen de los procesos de TI.
2. Actualiza a la 1.43.3.10861 o posterior; valora las actualizaciones automáticas.
3. Reduce la exposición: si es posible, limita Plex a la red local; si tiene que ser accesible, Ars Technica sugiere pasar por un proxy inverso en lugar de exponer el puerto predeterminado 32400.
4. Busca rastros, porque actualizar no elimina lo que ya se ha instalado:
   • procesos hijos inesperados lanzados por el servicio Plex, en especial mineros o proxies;
   • consumo de CPU anómalo;
   • archivos desconocidos, sobre todo bibliotecas .so, en la carpeta de códecs de Plex;
   • conexiones salientes hacia direcciones no reconocidas. Los nombres de archivo y la infraestructura pueden cambiar: no te bases solo en una lista fija de indicadores.
5. Si encuentras rastros: aísla la máquina, reinstálala desde cero y cambia las credenciales de la cuenta de Plex y las guardadas en el equipo.

Cómo ayuda ARXDOME

En ordenadores y servidores con el agente de ARXDOME, ARX Sentry recoge el inventario de software, procesos y puertos y controla la integridad de los archivos en las carpetas elegidas: una instalación de Plex no declarada o una biblioteca nueva en la carpeta de códecs se vuelven visibles. ARX Watch encuentra en la red dispositivos sin sonda, como los NAS; ARX Expose muestra qué servicios y productos de tu empresa son visibles desde internet, y ARX Shield permite aislar de la red una máquina sospechosa.

Última actualización: 20 de octubre de 2026