La cadena de vulnerabilidades apodada Plex2Shell — compuesta por cuatro fallas distintas en Plex Media Server — está siendo explotada activamente desde el 17 de octubre de 2026, menos de 24 horas después de la publicación de un código de prueba de concepto (PoC). El ataque no requiere credenciales, ni inicio de sesión, ni interacción del usuario: cualquier servidor expuesto a internet con versión inferior a 1.43.3.10861 está bajo ataque. En cuestión de horas, investigadores ya confirmaban la instalación de mineradores de criptomonedas y un backdoor de proxy residencial en servidores honeypot.
Lo que hace a Plex2Shell particularmente peligroso no es la gravedad aislada de cada CVE — el más alto tiene puntuación CVSS 8,6 —, sino la elegancia de la cadena: cuatro vulnerabilidades aparentemente menores se encadenan para permitir ejecución arbitraria de código en el contexto del servicio Plex, sin ninguna autenticación previa. La primera falla, CVE-2026-96652 (CVSS 5,3), es un SSRF no autenticado en el endpoint `/player/timeline`, donde el parámetro `protocol` no es validado y fuerza al servidor a enviar peticiones POST a cualquier destino controlado por el atacante. Luego, el CVE-2026-96654 (CVSS 6,9) explota una falla de neutralización de URL en el endpoint `searchOne`, permitiendo extraer el token de administrador del propietario sin contraseñas.
Con el token en manos, el atacante usa el CVE-2026-96655 (CVSS 5,3) para realizar SSRF autenticado a través de la ruta `/video/:/transcode/universal`, accediendo a recursos internos o externos. El golpe final — y el más peligroso — es el CVE-2026-96656 (CVSS 8,6): una falla de control externo de nombre de archivo que permite escribir un objeto compartido ELF en cualquier ruta del directorio `Codecs` del Plex. La arquitectura de carga de bibliotecas de Plex es el punto crucial: cuando el servicio necesita transcodificar un vídeo, enumera automáticamente todos los archivos `.so` en el directorio Codecs y los carga mediante `dlopen`. El cargador no verifica el prefijo `lib`, los permisos de ejecución, la firma digital ni los símbolos exportados. Una biblioteca `.so` con solo una función constructora (DT_INIT_ARRAY) ejecuta su código apenas se carga — y corre con la misma identidad del servicio Plex (uid 1000). Esto significa que la cadena entera, desde el SSRF inicial hasta la ejecución arbitraria, opera sin credenciales.
Zach Main, el investigador que descubrió las fallas y publica en zmain.info bajo el seudónimo "ZM", reportó las vulnerabilidades a Plex el 27 de julio de 2026. La empresa otorgó un bug bounty de US$ 500 el 4 de agosto y liberó el parche el 3 de agosto (versión 1.43.3.10861). Un aviso público fue emitido el 1 de septiembre. Sin embargo, el estudio de Shadowserver Foundation realizado el 9 de septiembre — seis semanas después del parche — encontró más de 36.000 instancias aún vulnerables, de aproximadamente 300.000 servidores Plex expuestos en internet. Cuando el PoC completo salió el 16 de octubre, muchos de esos servidores permanecían sin parchear. La explotación comenzó al día siguiente.
La primera carga útil observada fue un minador de criptomonedas basado en XMRig, bautizado `mylovelyminer`, conectado al servidor `ota.proxystream.st`. Días después, el mismo investigador que operaba el honeypot identificó un segundo programa llamado `myawesomeproxy`, un backdoor de proxy residencial Linux que convierte el servidor comprometido en un nodo de tráfico. El binario se conecta a `global.relay.proxystream.st` — un subdominio vinculado por Bitsight en agosto de 2026 a la botnet AISURU de DDoS y proxyware. La conexión con la AISURU es significativa: la misma infraestructura que operaba ataques de denegación de servicio y reventa de ancho de banda está siendo usada para hospedar los servidores de minería y enrutamiento del Plex2Shell. Esto sugiere reutilización de infraestructura entre campañas, posiblemente por los mismos operadores.
Lo que diferencia esta campaña de explotación de vulnerabilidades típicas en servicios domésticos es la sofisticación de las cargas útiles. Los minadores por sí solos serían un ganancia limitada — el Monero (XMR) cayó en valor y la minería en CPUs domésticas rara vez compensa el costo de electricidad. El proxy residencial, sin embargo, tiene valor real: cada nodo comprometido se convierte en una IP residencial que puede sortear bloqueos de IP corporativos, acceder a VPNs corporativas y sistemas de correo interno, y servir como puente para ataques a redes corporativas. La reputación de IP residencial, frecuentemente usada para burlar sistemas anti-bot, transforma un servidor Plex doméstico en infraestructura de ataque de alto valor.
La persistencia es otro aspecto crítico. Las cargas útiles no desaparecen con el reinicio del servicio: el archivo `.so` permanece en el directorio Codecs y es recargado siempre que Plex necesite transcodificar. Detener y reiniciar el servicio Plex no elimina la infección. El parche resuelve el problema en la raíz, pero los servidores ya comprometidos necesitan limpieza manual — inspección del directorio Codecs, remoción de archivos no autorizados, verificación de procesos hijos sospechosos y, idealmente, reinstalación completa a partir de una imagen limpia.
La lección del Plex2Shell no es nueva para administradores de infraestructura self-hosted, pero gana urgencia con la escala: 36.000 servidores sin parchear, 300.000 expuestos, y una cadena de exploits que opera en menos de 24 horas. El parche estaba disponible por 75 días antes de la explotación pública, y aún así la mayoría de los servidores permanecieron vulnerables. Cuando la puerta se abrió, la explotación fue casi inmediata — y las cargas útiles apuntan mucho más allá de la simple minería de criptomonedas.
Fuentes: The Hacker News, SecurityWeek, Security Affairs
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
