Los equipos comprometidos se convierten en mineros e infraestructura de ataque
Una operación de minería de criptomonedas que utiliza el malware PoeLLM ha comprometido más de 2.100 servidores, según Black Lotus Labs, de Lumen. En el punto álgido de la actividad, los investigadores observaron hasta 800 sistemas infectados activos en un solo día.
Los hallazgos fueron publicados por BleepingComputer el 7 de octubre de 2026 a las 11:04. Black Lotus Labs indicó que la actividad de PoeLLM se remonta al menos a abril, pero no especificó el año en que comenzó.
La campaña ha apuntado a sistemas de Estados Unidos y Europa occidental. Muchas de las víctimas identificadas utilizaban LiteLLM, Ollama, el software de conversión de PDF Gotenberg o el kit de herramientas de desarrollo Gitea, todos ellos accesibles desde internet. Los investigadores también encontraron indicios de que Ivanti Sentry estaba siendo objeto de ataques.
La minería es solo una parte de la operación. PoeLLM proporciona al operador acceso remoto mediante shell y puede convertir un equipo infectado en una plataforma para escanear servicios HTTP/S e intentar explotar otras vulnerabilidades. El malware también incorpora los mineros de criptomonedas XMRig e Iron.
Black Lotus Labs observó que los sistemas comprometidos se comunicaban con Kryptex, un servicio ruso de minería de criptomonedas, según la descripción de los investigadores. Estos consideran que las implementaciones de IA y de modelos de lenguaje grandes resultan atractivas para los atacantes porque algunas están expuestas o mal configuradas y pueden tener acceso a recursos de GPU adecuados para la minería.
Esto no significa que todas las víctimas fueran servidores de IA. El conjunto de víctimas descrito también incluye software de desarrollo y de conversión de documentos.
Un poema alojado en GitHub determina la dirección C2
PoeLLM es una muestra de malware ELF llamada libgcrypt. El proceso que utiliza para descubrir su servidor de mando y control depende de un texto obtenido de un repositorio de GitHub que parece ser una bifurcación de Node.js.
El malware lee cuatro palabras o frases de «Sobre la naturaleza de la conexión», un poema almacenado en un archivo llamado dash.css. Luego procesa esos términos mediante un diccionario codificado, los convierte en números y utiliza el resultado para generar una dirección IPv4 con la que comunicarse con el servidor de mando y control.
Si se modifica el poema, cambia la dirección generada por este proceso. Black Lotus Labs indicó que el operador había modificado el poema 11 veces y sospechaba que podría haberse producido al menos otra actualización. Los investigadores también observaron que se pusieron en marcha al menos 11 servidores C2.
El análisis de esa infraestructura reveló interfaces vulnerables de administración de routers en varios sistemas C2. Black Lotus Labs planteó que el operador podría haber reutilizado routers comprometidos, pero la información disponible no confirma esa hipótesis.
PoeLLM es el nombre del malware, no la identidad de un grupo de amenazas. Black Lotus Labs no pudo atribuir la operación con suficiente certeza a un actor conocido. Los investigadores consideran, con un nivel de confianza moderado, que el operador es italiano, basándose en comentarios encontrados en el malware y en que la interfaz de administración estaba alojada en un servidor ubicado en Italia.
La actividad de escaneo se centra en los puertos 3000 y 4000
Tras comprometer un servidor, la operación puede utilizarlo para buscar otros servicios en los puertos 3000 y 4000. La información disponible relaciona esos puertos con implementaciones de Gotenberg y LiteLLM.
A continuación, PoeLLM puede intentar explotar CVE-2026-42271, una vulnerabilidad de ejecución de comandos que afecta a la función de prueba del servidor MCP de LiteLLM. La actividad de escaneo observada y la capacidad de explotación no demuestran que esta vulnerabilidad haya sido el vector inicial de acceso a todos los equipos infectados.
La vulnerabilidad afecta a dos endpoints que se utilizan para probar la conexión con un servidor MCP antes de guardar su configuración:
POST /mcp-rest/test/connectionPOST /mcp-rest/test/tools/list
Desde LiteLLM 1.74.2 hasta las versiones anteriores a la 1.83.7, ambos endpoints aceptaban en el cuerpo de la solicitud la configuración completa de un servidor MCP. Esta podía incluir los campos command, args y env, utilizados por el transporte stdio.
Cuando un endpoint recibía una configuración stdio, el proxy intentaba establecer la conexión solicitada. Para ello, ejecutaba en el host el comando proporcionado como subproceso, con los privilegios asignados al proceso del proxy de LiteLLM.
Para acceder se necesitaba una clave de API válida para el proxy, pero los endpoints no comprobaban el rol del usuario. Por tanto, un usuario autenticado podía ejecutar comandos arbitrarios incluso con una clave de usuario interno de pocos privilegios. La vulnerabilidad se corrigió en LiteLLM 1.83.7.
CVE-2026-42271 tiene una puntuación CVSS v3 de 8.8 y el vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Las clasificaciones registradas son CWE-77, CWE-78 y una entrada duplicada de CWE-78.
Los productos y versiones afectados son:
- LiteLLM anterior a 1.83.7; la descripción de la vulnerabilidad especifica las versiones desde la 1.74.2 hasta las anteriores a la 1.83.7
- Red Hat OpenShift AI anterior a 2.25.8
Una cadena de explotación documentada elimina el requisito de autenticación
BleepingComputer informó de que investigadores de Horizon.ai confirmaron que CVE-2026-42271 podía encadenarse con CVE-2026-48710 para lograr la ejecución remota de código sin autenticación.
Esta descripción de ejecución remota de código se refiere a la cadena de explotación documentada. La descripción de CVE-2026-48710 en la NVD documenta por separado una deficiencia en la validación de la cabecera Host y la posibilidad de eludir controles de seguridad; no califica la vulnerabilidad por sí sola como una vulnerabilidad de ejecución remota de código.
CVE-2026-48710 afecta a Starlette en las versiones anteriores a la 1.0.1. En las versiones vulnerables, la cabecera HTTP Host de la solicitud no se validaba antes de que Starlette la utilizara para reconstruir request.url.
El enrutamiento se basa en la ruta HTTP sin procesar, mientras que la URL reconstruida incorporaba el valor de Host proporcionado. Como resultado, una cabecera malformada podía hacer que request.url.path no coincidiera con la ruta solicitada realmente por el cliente.
Esta discrepancia podía debilitar el middleware o los endpoints que aplicaban restricciones de seguridad mediante request.url en lugar de utilizar la ruta sin procesar de scope. Starlette 1.0.1 valida la cabecera conforme a RFC 9112 §3.2 y RFC 3986 §3.2.2, y recurre a scope["server"] si encuentra un valor malformado.
La vulnerabilidad tiene una puntuación CVSS v3 de 6.5 y el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. Sus clasificaciones son CWE-444 y CWE-1289.
Entre los productos afectados se encuentran:
- Encode Starlette anterior a 1.0.1
- Red Hat AI Inference Server hasta la versión 3.3.5, inclusive
- Red Hat Ansible Automation Platform 2.6
- Red Hat Migration Toolkit for Applications anterior a 8.2.0
- Red Hat OpenShift AI anterior a 3.3.5
- Red Hat OpenShift Lightspeed, sin versión especificada en los datos proporcionados
- Red Hat Satellite 6.17
- Red Hat Enterprise Linux AI 3.0
CISA incluye ambas vulnerabilidades entre las explotadas activamente
CISA añadió CVE-2026-42271 a su catálogo de vulnerabilidades explotadas conocidas (KEV) el 8 de junio de 2026. Las agencias federales estadounidenses afectadas tenían como fecha límite para corregirla el 22 de junio de 2026.
CISA exige aplicar las medidas de mitigación indicadas por el proveedor, seguir las directrices aplicables de BOD 22-01 para los servicios en la nube o dejar de utilizar el producto si no hay medidas de mitigación disponibles.
CVE-2026-48710 se incorporó al catálogo KEV el 2 de septiembre de 2026. Las agencias federales estadounidenses tenían como fecha límite para corregirla el 16 de septiembre de 2026. CISA pide aplicar las medidas de mitigación indicadas por el proveedor, de acuerdo con BOD 26-04, Prioritizing Security Updates Based on Risk y sus Forensics Triage Requirements.
La instrucción también exige seguir las directrices aplicables de BOD 26-04 para los servicios en la nube o dejar de utilizar el producto si no hay medidas de mitigación disponibles. Las partes interesadas deben evaluar la exposición a internet de cada activo y seguir las pautas de aplicación de parches de BOD 26-04.
Esas fechas son plazos de corrección para las agencias federales, no fechas límite generales para todas las organizaciones.
Otras vulnerabilidades relacionadas con los mismos proveedores —Red Hat, LiteLLM o Encode— también se incorporaron al catálogo KEV en los últimos 90 días: CVE-2026-59822 el 2 de septiembre de 2026, CVE-2015-5287 y CVE-2015-3246 el 26 de agosto de 2026, y CVE-2026-34486 el 4 de agosto de 2026.
Las comprobaciones defensivas deben combinar exposición, procesos y actividad de red
Los administradores deben identificar los servicios de LiteLLM, Ollama, Gotenberg, Gitea e Ivanti Sentry accesibles desde internet, cuando corresponda. Conviene reducir la exposición a internet de los sistemas críticos y restringir el acceso externo a direcciones IP de confianza.
Para corregir CVE-2026-42271, las implementaciones de LiteLLM deben actualizarse a la versión 1.83.7 o posterior. Los usuarios de Starlette deben pasar a la versión 1.0.1 o posterior, y quienes utilicen productos de Red Hat afectados deben seguir las instrucciones correspondientes del proveedor.
Entre los aspectos que conviene investigar se encuentran el escaneo de los puertos 3000 y 4000, la ejecución inesperada de comandos con los privilegios del proceso del proxy de LiteLLM, la recuperación de dash.css y la presencia de un archivo ELF llamado libgcrypt. Estos detalles son indicios de comportamiento o contexto y no deben considerarse, por sí solos, pruebas concluyentes de una intrusión.
Black Lotus Labs compartió indicadores de compromiso para revisar los registros de red. Este artículo no reproduce sus valores, por lo que los equipos de defensa deben consultar el material publicado por los investigadores antes de realizar búsquedas basadas en indicadores.
La atribución debe mantenerse separada de la detección. Las pruebas respaldan, con un nivel de confianza moderado, la hipótesis de que el operador podría ser de origen italiano, pero no confirman su identidad ni permiten asignarlo a un grupo de amenazas conocido.
