QNAP avisa de NAS atacados por Plex2Shell y pide reinstalar Plex

Diecisiete días después de que CISA metiera en su catálogo KEV los cuatro CVE de Plex2Shell, QNAP reconoció el 6 de noviembre de 2026 que recibe avisos de usuarios con el Plex Media Server de su NAS comprometido y pidió a todos reinstalarlo desde cero si el puerto 32400 estuvo abierto a internet. La cadena, formada por CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 y CVE-2026-96656, permite ejecutar código en el servidor sin credenciales, y el mapa de Censys sitúa 6.867 servidores Plex expuestos en España.

• QNAP recibe desde el 6 de noviembre informes de NAS con Plex Media Server comprometido por Plex2Shell y su soporte está atendiendo los casos. QTS y QuTS hero no están afectados por sí mismos.
• La cadena encadena cuatro CVE de puntuación media para ejecutar código sin credenciales en cualquier Plex anterior a 1.43.3.10861, incluida la build 1.43.3.10828.
• Los atacantes instalan el minero XMRig y el proxy myawesomeproxy, con infraestructura en proxystream.st que Bitsight relaciona con la botnet AISURU.
• Censys cuenta unos 324.000 servidores Plex expuestos, un 30 % vulnerable, y 6.867 en España. CISA metió los cuatro CVE en KEV el 20 de octubre.
• Si el puerto 32400 estuvo abierto con una versión vulnerable, actualizar no basta: hay que reinstalar Plex desde cero, vaciar Codecs y rotar las credenciales de Plex y del NAS.

Lo que QNAP ha recibido de sus usuarios y lo que su PSIRT descarta

El aviso de QNAP, fechado en Taipéi el 6 de noviembre, no cuantifica los equipos afectados. Dice que ha recibido informes de algunos usuarios cuyo Plex Media Server parece comprometido a través de estas vulnerabilidades y que «QNAP Technical Support is assisting the affected users» (el soporte técnico de QNAP está atendiendo a los usuarios afectados). El PSIRT del fabricante acota el problema a la app de terceros, con una frase que conviene leer completa: los fallos están solo en Plex Media Server, y QTS, QuTS hero y el resto de sistemas operativos de QNAP no están afectados por sí mismos. El matiz importa, porque el proceso de Plex corre dentro del NAS y lo que un atacante consiga desde él depende de lo que ese proceso alcance.

La versión corregida, Plex Media Server 1.43.3 (build 1.43.3.10861), está en el App Center desde el aviso. QNAP dice que publicará versiones posteriores cuando las verifique, y pide no esperarlas. La captura de su propia FAQ muestra dónde se comprueba la versión instalada, en App Center y en la sección My Apps.

La FAQ de QNAP añade dos indicadores que no están en el aviso de Plex. El primero es que Malware Remover, la app de limpieza del propio fabricante, puede reportar una detección con el código MR2104 en un NAS afectado. El segundo son las vías por las que Plex pudo quedar expuesto sin que el usuario lo decidiera: la función Remote Access de Plex abre el puerto por UPnP, y la configuración automática del router de myQNAPcloud puede haberlo hecho también. Si cualquiera de esas opciones estuvo activa con la 1.43.2 o anterior, QNAP pide tratar el NAS entero como posiblemente comprometido, no únicamente la app.

De un X-Plex-Token falso a un .so en la carpeta Codecs, la cadena de Zach Main

Los cuatro fallos los encontró el investigador Zach Main, que los reportó a Plex el 27 de julio de 2026. Plex los reconoció y pagó la recompensa el 4 de agosto, los CVE se asignaron el 23 de septiembre y la publicación completa, con PoC en GitHub, llegó el 16 de octubre. Main cuenta que buscó los fallos con modelos de lenguaje en un ciclo de reconocimiento, caza, verificación con un agente que intenta refutar cada hallazgo y encadenado, y cierra el texto con un agradecimiento: «Thanks to the Plex security team for the quick response and fixes» (gracias al equipo de seguridad de Plex por la respuesta y las correcciones rápidas). El diagrama que SonicWall reproduce en su análisis resume las cinco etapas tal como las describe el autor.

La entrada es el endpoint /player/timeline del protocolo de acompañamiento, el que usan mandos y dispositivos de casting. Su comprobación solo verifica que la cabecera X-Plex-Token existe, no que sea válida, así que cualquier cadena sirve. El parámetro protocol se concatena sin filtro en la URL de callback, y si contiene una URL completa el servidor hace un POST contra ella desde 127.0.0.1. Ese es CVE-2026-96652, un SSRF ciego pero suficiente, porque la API de plugins /system/agents/ no exige token cuando la petición llega por loopback.

Desde ahí, CVE-2026-96654 permite forjar una llamada a cualquier función de plugin: la guarda de identificadores de searchOne devuelve dentro de un decorador que descarta el resultado y nunca detiene nada, y el identificador se inserta sin codificar, de modo que un signo de interrogación abre la query y una almohadilla trunca el resto de la ruta. El objetivo es GetResultFromNetwork, una función del agente de TheTVDB que descarga la URL que se le pasa. El framework de plugins añade el token de administrador del propietario a toda URL que empiece por http://127.0.0.1, con una comparación de prefijo sin límite, y un nombre como 127.0.0.1.45-194-92-222.sslip.io pasa el filtro y resuelve a la IP del atacante. Es CVE-2026-96655, y con ese token el atacante ya es el propietario del servidor.

Las dos últimas etapas son CVE-2026-96656. La preferencia TranscoderH264Options se añade tal cual a las opciones de x264 en cada transcodificación, y la opción de depuración dump-yuv escribe los fotogramas decodificados en la ruta que se le indique. Con calidad sin pérdidas, los fotogramas son una copia exacta del vídeo de entrada, y el vídeo de entrada es un objeto compartido ELF empaquetado como fotograma. El atacante apunta el transcodificador a su propio item.xml, el fichero .so aparece en la carpeta Codecs y, en la siguiente transcodificación, la libavutil de Plex lo carga con dlopen sin comprobar firma, bit de ejecución ni símbolos. El constructor del ELF se ejecuta como el usuario plex.

Las puntuaciones proceden de la ficha de NVD y de las de los otros tres registros, todos publicados el 23 de septiembre y en estado analizado. Ninguna pasa de 8,6, y la explicación está en que cada CVE describe una etapa que por separado exige privilegios o no llega a ejecutar nada. El 9,8 es la nota del conjunto que asigna Main. SonicWall atribuye en su análisis un 8,6 al SSRF inicial, cifra que no coincide con la de NVD para ese CVE y sí con la de CVE-2026-96656, así que aquí nos quedamos con la fuente primaria. Junto a los cuatro, el mismo 23 de septiembre se publicó CVE-2026-96651, un path traversal en /system/agents/media/get con 7,1 en CVSS 4.0 que deja leer el PlexOnlineToken con una sesión válida. Se corrige en la misma build, pero no forma parte de la cadena ni está en KEV.

Mineros XMRig, el proxy myawesomeproxy y una infraestructura que Bitsight ya vio en AISURU

La explotación la vio primero un investigador que firma como boredhackerblog, con un honeypot que montó tras el aviso de Plex del 1 de septiembre, y que escribió en su entrada del 17 de octubre que esa mañana por fin había observado explotación real. El primer intento llegó desde 45.194.92.222 con el agente de usuario Python-urllib/3.10 y una URI que ya contenía el nombre sslip.io con la IP del atacante. Después se sumaron 91.92.40.202 y 176.65.139.228. Cuando permitió tráfico saliente al señuelo, el proceso de Plex descargó de 217.60.194.116 un script llamado docker y un binario llamado x. Su resumen del binario cabe en una frase: «Of course it's a cryptominer» (claro que es un criptominero).

El árbol de procesos que publicó muestra la cadena completa: el proceso Plex Media Server lanza un shell que descarga docker con wget o curl, y de ahí sale x12345 con los parámetros de XMRig, donate-level 5 y el pool en ota.proxystream.st:3333, con el identificador de rig plexdocker. Ese mismo día, en una segunda actualización, vio ejecutarse myawesomeproxy, un binario que al arrancar avisa de que usarlo supone aceptar «potential external use of your internet traffic» (el posible uso externo de tu tráfico de internet). Es decir, un servidor doméstico convertido en nodo de proxy residencial para quien pague por él.

El dominio proxystream.st tiene historia. Según The Hacker News, Bitsight señaló en agosto de 2026 el subdominio global.relay.proxystream.st en su análisis de la botnet AISURU, de la que el proxy obtiene su lista de dominios. Ninguna fuente atribuye la campaña contra Plex a un grupo concreto, y el propio investigador advierte de que su honeypot bloqueaba la salida al principio, así que pudo perderse payloads de otros operadores.

Johannes Ullrich repasó la explotación en el Stormcast del SANS Internet Storm Center del 20 de octubre, en inglés, junto a otros fallos de esa semana.

Los indicadores que reúnen el honeypot y el aviso de Plex del 19 de octubre van en la tabla siguiente.

A los nombres de proceso que da Plex, myawesomeproxy, mylovelyminer y x12345, hay que sumar cualquier fichero .so o .dll que no se reconozca en la carpeta Codecs y un consumo de CPU sostenido sin nada en reproducción. The Hacker News recogió el 19 de octubre varios hilos de Reddit con usuarios que encontraron mylovelyminer en sus servidores, sin que entonces se pudiera confirmar que procedieran de Plex2Shell.

328.000 servidores Plex a la vista y 6.867 en España, según Censys

Plex se instala en servidores domésticos, y eso se nota en el reparto. En su aviso del 20 de octubre, Censys cuenta unos 324.000 hosts con Plex Media Server expuesto, las mayores redes son operadores de banda ancha residencial y Estados Unidos concentra cerca del 44 %. Alrededor del 30 % corre una build vulnerable, y casi 8.000 tienen la 1.43.3.10828, una build intermedia de la rama que Plex nombró como corregida en septiembre y que sigue siendo explotable, el caso más fácil de confundir con un servidor parcheado. El mapa que acompaña al aviso, con 328.096 hosts en el momento de la captura, pone a España en el octavo puesto con 6.867 servidores, por detrás de Alemania y por delante de Suecia.

La serie temporal de Censys es la parte del aviso que más sirve para planificar parcheos. La build corregida apareció a principios de agosto y la proporción de servidores vulnerables cayó del 98 % al 70 % en pocos días, al 51 % cuando Plex publicó su aviso del 1 de septiembre y al 39 % cuando NVD publicó los CVE. El 16 de octubre, con la cadena pública, quedaba un 31 %, y en los tres días siguientes el ritmo no se aceleró: «Under 2 percent of still-vulnerable hosts upgraded in that window» (menos del 2 % de los hosts todavía vulnerables actualizó en esa ventana), por debajo de las dos ventanas equivalentes de las semanas anteriores.

Shadowserver escanea desde el 4 de septiembre las versiones sin parchear de Plex Media Server y las etiqueta como vulnerable-plex en sus informes de HTTP vulnerable. Su primer recuento público, del 9 de septiembre, lo anunció en Bluesky: «Over 36K instances found still unpatched» (más de 36.000 instancias siguen sin parchear), con Estados Unidos a la cabeza.

The Shadowserver Foundation@shadowserver.bsky.social

Since 2026-09-04 we are scanning/reporting daily unpatched versions of Plex Media Server in response to an advisory issued by Plex forums.plex.tv/t/important-... for v1.43.2 & earlier. Over 36K instances found still unpatched! Top affected: US World Map: dashboard.shadowserver.org/statistics/c...

September 9, 2026 at 8:14 AM UTC

Al escribir esta noticia, el 8 de noviembre, ni INCIBE-CERT ni CCN-CERT habían publicado aviso propio sobre Plex2Shell, y no hay un recuento específico de NAS de QNAP con Plex expuesto, ni en España ni en el resto del mundo. Los 6.867 de Censys mezclan NAS, PC domésticos, contenedores y servidores dedicados, y una parte ya está en la 1.43.3.10861.

Qué hacer hoy si tu NAS QNAP ejecuta Plex

El orden lo marca la exposición: primero saber si el servidor se podía alcanzar desde internet, después actualizar y, si estuvo expuesto, rehacerlo.

1. Comprueba la versión en Plex Web, en Settings y General, o en el App Center de QTS. Todo lo anterior a 1.43.3.10861 es vulnerable, incluida la 1.43.3.10828.
2. Averigua si Plex estuvo expuesto mientras corría una versión vulnerable: Remote Access activado en Plex, puerto 32400 redirigido en el router, UPnP activo o la configuración automática de router de myQNAPcloud.
3. Actualiza a 1.43.3.10861 o posterior desde App Center, My Apps, Plex Media Server y Update. En Docker, Linux y otros NAS la actualización es manual.
4. Si estuvo expuesto, no te quedes en la actualización. Copia la carpeta Logs de Plex si quieres que QNAP confirme el compromiso, desinstala Plex Media Server, no reutilices la carpeta Plex Media Server que quede en PlexData, vacía Codecs, revisa Preferences.xml en busca de opciones de transcodificación que no pusiste y reinstala limpio.
5. Cierra sesión en todos los dispositivos desde la cuenta de Plex y cambia la contraseña. En el NAS, cambia las contraseñas de administrador y de usuarios, activa la verificación en dos pasos y rota las credenciales guardadas en trabajos de copia, conexiones a la nube y otros servicios del equipo.
6. Desactiva Remote Access si no lo necesitas, elimina la redirección del 32400 y desactiva UPnP. Si necesitas acceso desde fuera, hazlo a través de una conexión VPN como QVPN Service, y activa los análisis de Malware Remover y QuFirewall.
7. Si encuentras un indicador, abre un caso con el soporte de QNAP con la versión de Plex, si era alcanzable desde internet y lo que hayas visto. Las empresas pueden notificar el incidente a INCIBE-CERT y las entidades del sector público, al CCN-CERT.

Para la comprobación rápida en cualquier Plex sobre Linux, incluido el de un contenedor o un NAS con acceso SSH, estos comandos devuelven la build instalada, los objetos compartidos de Codecs y los procesos hijos del servidor.

# Build instalada (la API local no necesita token para /identity)
curl -s http://127.0.0.1:32400/identity | grep -o 'version="[^"]*"'

# Objetos compartidos presentes en Codecs, con fecha de modificación
find / -path '*Plex Media Server/Codecs/*' -name '*.so' -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort

# Procesos descendientes de Plex Media Server
pgrep -f 'Plex Media Server' | xargs -r -I{} pstree -ap {}

En los logs del servidor, de un proxy inverso o de Zeek, la petición de la primera etapa se distingue porque el parámetro protocol lleva una URL completa en lugar de http o https. Esta expresión la localiza en un fichero de acceso.

grep -E '/player/timeline/subscribe\?[^ ]*protocol=https?(%3A|:)' access.log

Quien publique Plex detrás de Nginx puede cortar la primera etapa mientras actualiza, bloqueando ese parámetro cuando contiene una URL.

location /player/timeline {
    if ($arg_protocol ~* "^https?(%3A|:)") { return 403; }
    proxy_pass http://127.0.0.1:32400;
}

SonicWall publicó el 29 de octubre tres firmas de IPS para la cadena, la 22567 para el SSRF con X-Plex-Token, la 22568 para la escritura de ficheros y la 22569 para la inyección de URI, según el análisis de Dhiren Vaghela en Capture Labs. Main publicó reglas de detección en el mismo repositorio de la PoC. El bloqueo en el perímetro no sustituye a la actualización, porque la cadena sigue disponible desde la red local.

Un parche de agosto, un aviso sin detalles y tres meses de ventana

La cronología de Plex2Shell tiene un hueco de mes y medio que explica por qué QNAP está atendiendo compromisos en noviembre. El parche existe desde el 4 de agosto. El aviso de Plex del 1 de septiembre pedía actualizar, pero no decía qué se corregía ni daba un CVE, y Shadowserver recordaba el 9 de septiembre que sin CVE las vulnerabilidades son invisibles para la comunidad de seguridad. Los CVE llegaron el 23 de septiembre con puntuaciones medias que no alarmaron a nadie, y la cadena completa, con PoC, el 16 de octubre. La curva de Censys demuestra que la publicación del exploit no movió a los rezagados, y el aviso de CISA del 20 de octubre, con plazos de tres días para dos de los CVE bajo la directiva BOD 26-04, tampoco llega a los servidores domésticos que forman la mayor parte de los 324.000.

En el catálogo KEV, Plex Media Server acumula ya cinco entradas, las cuatro de octubre y CVE-2020-5741, incluida en marzo de 2023. Los plazos cortos de la BOD 26-04 se diseñaron para agencias federales, y a un NAS con Plex en un salón o en una pyme no lo alcanza ninguna directiva. El caso de la build 1.43.3.10828 recuerda al parche de Zyxel que no cerraba el fallo: el número de versión parece correcto y el servidor sigue abierto.

Plex2Shell comparte sufijo con PHP2Shell, la pareja de fallos de PHP que Mirai empezó a probar en octubre, y comparte también el destino de las víctimas: criptominería y tráfico ajeno saliendo por la conexión de casa. Lo que QNAP reconoce el 6 de noviembre es la fase en la que las intrusiones de octubre empiezan a notarse como un NAS lento o una factura de luz distinta. Un servidor multimedia expuesto en el 32400 es, para quien lo ataca, un Linux con disco grande, conexión residencial y un usuario que rara vez mira los procesos, y ese perfil no cambia con el parche. Si Plex tiene que verse desde fuera, lo razonable hoy es que se vea solo a través de la VPN del propio NAS.