PoeLLM malware había comprometido más de 3.400 servidores hasta el 7 de octubre de 2026, según Lumen Black Lotus Labs y fuentes independientes. La campaña activa Canto Incognito ataca servicios expuestos, incluidos LiteLLM, Ollama, Gotenberg y Gitea, y después instala mineros de criptomonedas y reutiliza los hosts infectados para buscar más víctimas. Los operadores deben restringir la exposición, aplicar parches a los servicios e investigar de inmediato cualquier uso anómalo de los recursos de cómputo.
¿Qué es el malware PoeLLM?
El malware PoeLLM es una familia de malware que convierte servidores comprometidos en mineros de criptomonedas, escáneres de red y plataformas para lanzar exploits. Lumen Black Lotus Labs reveló públicamente esta familia el 7 de octubre de 2026 como la carga útil utilizada por una campaña con motivación económica llamada Canto Incognito, que seguía activa en el momento de la publicación.
El nombre puede llevar a engaño. PoeLLM no es una inteligencia artificial maliciosa ni se sabe que ataque modelos de lenguaje mediante prompts. Su relación con la IA proviene de la infraestructura en riesgo: las pasarelas de modelos accesibles desde Internet y los servidores de modelos locales pueden proporcionar a los atacantes una valiosa capacidad de CPU o GPU.
Una vez dentro, el malware instala los mineros XMRig e Iron y conecta las cargas de minería al servicio Kryptex, según la información publicada por The Hacker News en 2026. La capacidad de procesamiento sustraída puede generar criptomonedas para los operadores, mientras deja a la víctima con mayores costes en la nube, inferencias más lentas y menos capacidad para el trabajo legítimo.
La minería solo es una parte del daño. BleepingComputer informó en 2026 de que las máquinas comprometidas también actuaban como escáneres HTTP y HTTPS y servidores de exploits. Por tanto, un endpoint de desarrollo desatendido puede convertirse en infraestructura para atacar a terceros, un patrón que también se observó cuando la botnet Carbonato abusó de hosts Docker expuestos.
¿Cómo llegó el malware PoeLLM a más de 3.400 servidores?
El malware PoeLLM se propagó incorporando servicios vulnerables accesibles desde Internet desde, al menos, abril hasta octubre de 2026. Lumen Black Lotus Labs e informes independientes situaron el recuento acumulado por encima de los 3.400 servidores el 7 de octubre de 2026, con infecciones concentradas principalmente en Estados Unidos y Europa occidental, en lugar de distribuirse de forma uniforme por todo el mundo.
El primer commit del repositorio de GitHub del atacante se registró el 13 de abril de 2026. Ese repositorio ayudaba a los sistemas infectados a localizar la infraestructura de mando y control, pero la fecha del commit no demuestra que todas las fases de la infección comenzaran ese día.
Las fechas publicadas ofrecen una referencia útil para valorar la escala. Dividir más de 3.400 servidores comprometidos entre los aproximadamente 177 días transcurridos del 13 de abril al 7 de octubre de 2026 da una media superior a 19 nuevas víctimas contabilizadas al día. La incorporación real no fue lineal: cerca de 800 sistemas infectados estaban activos cada día en el pico de la campaña, a mediados de junio de 2026.
Los totales publicados deben interpretarse con cautela. La información difundida en torno a la revelación del 7 de octubre de 2026 actualizó las estimaciones anteriores de aproximadamente 2.100 a 2.200 víctimas a más de 3.400, mientras que, según se informó, parte del material de Lumen conservaba la cifra inferior. La interpretación defendible es la de más de 3.400 compromisos acumulados, no 3.400 máquinas activas simultáneamente.
Black Lotus Labs descubrió la operación más amplia en junio de 2026 mientras investigaba un sistema Ivanti Sentry asociado a CVE-2026-10520, informó The Register. Ese hallazgo no establece que Ivanti Sentry fuera el punto de entrada de todas las víctimas. Tratar un único dispositivo investigado como vector de infección universal llevaría a los defensores en la dirección equivocada.
¿Qué servicios expuestos a Internet atacó la campaña?
El malware PoeLLM atacó servicios expuestos de LiteLLM, Ollama, Gotenberg y Gitea en 2026, mientras que los investigadores también encontraron indicios relacionados con Ivanti Sentry. El conjunto afectado abarca puertas de enlace de IA, servicios de modelos locales, conversión de documentos e infraestructura de desarrollo, lo que demuestra que la campaña busca recursos informáticos accesibles y servicios explotables, no una única categoría de producto definida de forma estricta.
| Servicio | Papel típico | Relación con la campaña de 2026 comunicada |
|---|---|---|
| LiteLLM | Puerta de enlace y proxy para API de modelos de lenguaje | Objetivo observado |
| Ollama | Servicio local de modelos de lenguaje de gran tamaño | Objetivo observado |
| Gotenberg | API de conversión de documentos en contenedores | Objetivo observado |
| Gitea | Servicio Git autoalojado | Objetivo observado |
| Ivanti Sentry | Componente de puerta de enlace móvil | Indicios de ataque dirigido; no se ha establecido como vector de infección de todas las víctimas |
La combinación es importante. Gotenberg y Gitea no son servidores de modelos de lenguaje de gran tamaño, pero ambos encajan en los criterios prácticos de un atacante: servicios de aplicaciones accesibles, capacidad informática o acceso útil y oportunidades para pasar de un sistema expuesto al siguiente. Calificar Canto Incognito únicamente como un «ataque a servidores de IA» oculta ese riesgo operativo más amplio.
Las herramientas de desarrollo merecen el mismo nivel de escrutinio que los endpoints de inferencia de producción. Incidentes recientes relacionados con una vulnerabilidad de JFrog Artifactory y puertas traseras persistentes y una vulnerabilidad crítica de GitLab explotada activamente ilustran por qué los repositorios y los sistemas de compilación no deben quedar fuera de las revisiones habituales de exposición.
¿Por qué utiliza el malware un poema en GitHub?
El malware PoeLLM lee cuatro palabras o frases de un poema alojado en GitHub y las asigna mediante un diccionario integrado para reconstruir su dirección IPv4 actual de mando y control. Esta técnica de 2026 permite al operador redirigir los servidores infectados editando texto público, sin tener que enviar un binario de malware de sustitución a cada host comprometido.
El poema no es un recurso literario añadido a un sistema ordinario de mando y control. Es un mecanismo compacto de indirección. La información publicada en 2026 documentó 11 cambios del poema y 12 direcciones identificadas, lo que demuestra que el operador podía rotar los destinos manteniendo la misma lógica de búsqueda en las máquinas infectadas.
No se acusa a GitHub de participar en el ataque; el contenido de su repositorio se utilizó indebidamente como canal de descubrimiento. Por tanto, los defensores que bloqueen únicamente un servidor de mando conocido pueden obtener un alivio temporal y pasar por alto el comportamiento estable: recuperar contenido público, descodificarlo localmente y conectarse después a una dirección IPv4 recién derivada.
Según se informó, tres direcciones de mando identificadas seguían activas el 7 de octubre de 2026, aunque Lumen había desviado a una ruta nula la infraestructura visible a través de su propia red. Sinceramente, una lista estática de bloqueo de IP es demasiado frágil como defensa principal en este caso. La política de salida y la detección basada en el comportamiento ofrecen un control más duradero.
¿Cómo deben detectar y detener el malware PoeLLM los operadores?
Los operadores deben contener el malware PoeLLM eliminando la exposición innecesaria a Internet, exigiendo autenticación, aplicando parches a los servicios afectados y aislando los contenedores con el mínimo privilegio. En 2026, los defensores también deben rotar las credenciales expuestas, restringir las conexiones salientes e investigar el consumo inexplicado de CPU o GPU, el tráfico hacia pools de minería, los escaneos amplios y el comportamiento de suministro de exploits.
Empiece por el servicio accesible, no por el nombre del malware. Un endpoint de modelos o una interfaz de administración sin autenticación puede volver a ser descubierto después de eliminar un minero. Coloque las cargas de trabajo privadas detrás de una VPN, un proxy con reconocimiento de identidad o una regla de cortafuegos estrictamente delimitada y, después, compruebe desde una red externa que el puerto original ya no sea público.
El siguiente orden de respuesta aborda tanto la exposición inicial como la capacidad del host comprometido para propagarse:
- Haga un inventario de los sistemas LiteLLM, Ollama, Gotenberg, Gitea e Ivanti Sentry expuestos a Internet, incluidas las implementaciones de prueba temporales y las instancias en la nube creadas fuera del aprovisionamiento estándar.
- Elimine el acceso público cuando no sea necesario; en caso contrario, aplique autenticación, restricciones de origen y límites de velocidad adecuados para el servicio.
- Aplique los parches del proveedor y revise las indicaciones de cada versión para todos los productos afectados, en lugar de asumir que una única vulnerabilidad explica la campaña de 2026.
- Ponga en cuarentena los hosts sospechosos, conserve los registros e inspeccione los contenedores, procesos, tareas programadas y mecanismos de persistencia antes de reconstruirlos a partir de una imagen de confianza.
- Rota las claves de API, los tokens de servicio, las credenciales SSH y los secretos accesibles desde el host, incluidas las credenciales montadas dentro de los contenedores.
- Restringe el acceso saliente y genera alertas ante conexiones a Kryptex o a pools de minería, saturación sostenida de la capacidad de procesamiento, escaneos a escala de Internet y tráfico de explotación inesperado.
Aquí, el principio de mínimo privilegio tiene dos capas. Ejecuta los contenedores sin permisos excesivos sobre el host y limita los destinos de red a los que pueden acceder esas cargas de trabajo. Los controles del entorno de ejecución forman cada vez más parte de la gobernanza práctica de la IA para sistemas en producción, porque los documentos de políticas no pueden impedir que un contenedor secuestrado mine o realice escaneos.
No consideres el bajo tráfico de inferencia como una prueba de seguridad. Un servidor comprometido puede mostrar poco uso legítimo del modelo mientras su procesador permanece ocupado al máximo por XMRig o Iron. Compara las líneas base de procesamiento, red y facturación con la misma carga de trabajo y ventana temporal; una utilización elevada y sostenida sin un volumen de solicitudes correspondiente requiere una investigación inmediata.
Black Lotus Labs atribuyó Canto Incognito a un actor italófono con una confianza moderada en 2026, basándose en artefactos en italiano e indicadores de flujo de red. Esa atribución no debería modificar las prioridades de contención. Los investigadores también observaron tráfico dirigido a SSH y otros portales de inicio de sesión que podría indicar experimentación con ataques de fuerza bruta, pero la madurez de la capacidad seguía siendo incierta en 2026.
Preguntas frecuentes sobre PoeLLM
¿Es PoeLLM un virus generado por IA?
No se ha informado de que PoeLLM sea un virus generado por IA. El nombre del malware refleja su descubrimiento del servidor de mando basado en poemas y su orientación hacia infraestructuras expuestas que incluyen servicios de IA.
¿PoeLLM infecta únicamente servidores Ollama?
PoeLLM afectó a más despliegues que los de Ollama en 2026. Entre los objetivos observados se encontraban LiteLLM, Gotenberg y Gitea, además de indicios adicionales relacionados con Ivanti Sentry.
¿Eliminar el criptominero elimina la infección?
Eliminar únicamente XMRig o Iron no demuestra que un host comprometido esté limpio. Los operadores deben aislar el servidor, investigar la persistencia y la actividad de escaneo, rotar los secretos accesibles, cerrar la exposición original y reconstruirlo a partir de una imagen de confianza cuando no pueda demostrarse su integridad.
¿Seguía activa la campaña en octubre de 2026?
Canto Incognito seguía incorporando sistemas vulnerables expuestos a Internet cuando los investigadores dieron a conocer la campaña el 7 de octubre de 2026. Los informes de seguimiento publicados hasta el 12 de octubre de 2026 continuaban citando más de 3.400 servidores afectados, sin que se hubiera identificado un total sustancialmente más reciente y fiable a 13 de octubre de 2026.