El paquete malicioso imgdecode utiliza una biblioteca nativa para descargar código cifrado e inyectarlo en otro proceso. SafeDep vincula la amenaza a una campaña que roba credenciales, datos de navegadores y carteras de criptomonedas.
Una herramienta que aparenta servir para procesar imágenes puede esconder una amenaza capaz de comprometer el ordenador de un desarrollador. Ese es el riesgo detectado en imgdecode, un paquete malicioso publicado en npm que forma parte de la campaña MALFEX, una operación de distribución de malware dirigida a sistemas Windows.
La investigación de la empresa de seguridad SafeDep, publicada el 13 de octubre de 2026, documenta cómo el paquete carga una biblioteca nativa compilada para Windows, descarga una carga cifrada desde GitHub e intenta ejecutarla dentro de un proceso del sistema. Según The Hacker News, el paquete había registrado 979 descargas cuando se publicó su análisis el 17 de octubre. Esa cifra no demuestra que todos los usuarios que lo descargaron hayan ejecutado el malware ni que todos sus equipos estén infectados.
El caso pone de relieve una debilidad de la cadena de suministro del software: las dependencias de código abierto pueden convertirse en una vía de entrada para los atacantes cuando un paquete aparentemente legítimo incorpora componentes maliciosos.
Qué es imgdecode y por qué preocupa a los investigadores
imgdecode se publicó en el registro npm el 30 de septiembre de 2026, bajo la cuenta malfexteste8. El paquete se presenta como una herramienta relacionada con la decodificación de imágenes y contiene un pequeño archivo JavaScript que carga un complemento nativo para Windows.
El problema está en ese complemento. SafeDep identificó una biblioteca compilada de 64 bits que ejecuta la lógica maliciosa cuando Node.js carga el módulo en determinadas condiciones.
En las versiones analizadas, el código comprueba si se está ejecutando en una consola interactiva de Windows. Si se cumplen esas condiciones, intenta recuperar contenido cifrado alojado en un repositorio de GitHub y ejecutarlo en memoria.
La técnica resulta especialmente preocupante porque no necesita un script de instalación convencional para activar la carga maliciosa. Bloquear los scripts de instalación de npm, por sí solo, no impide que se ejecute código peligroso cuando una aplicación importa una dependencia.
SafeDep señala además que la biblioteca intenta inyectar la carga en un nuevo proceso dllhost.exe, un componente legítimo de Windows. Utilizar un proceso del sistema no convierte la actividad en legítima: es una técnica que puede dificultar la detección si los sistemas de seguridad no analizan el comportamiento completo.
Cómo funciona el ataque de MALFEX
La cadena de infección combina código JavaScript, una biblioteca nativa de Windows y una carga adicional que puede recuperar otros componentes maliciosos.
El proceso documentado por SafeDep se puede resumir en cuatro fases:
- Carga del paquete. Una aplicación Node.js importa
imgdecodey carga su complemento nativo. - Comprobación del entorno. La biblioteca verifica si se ejecuta en una consola interactiva de Windows, una condición que puede reducir la probabilidad de activación en determinados entornos automatizados.
- Descarga y descifrado. El complemento intenta recuperar desde GitHub un archivo que contiene datos cifrados y los procesa en memoria.
- Ejecución de la carga. El código descifrado se inyecta en
dllhost.exe; si esa vía falla, el análisis de SafeDep describe una alternativa de ejecución dentro del proceso de Node.js.
El objetivo es ocultar el comportamiento malicioso tras una apariencia de normalidad. En lugar de presentar un ejecutable sospechoso y evidente, el paquete utiliza una biblioteca compilada y una infraestructura externa para obtener la carga en el momento de la ejecución.
La ausencia de un script de instalación no garantiza que un paquete npm sea seguro. En este caso, el comportamiento peligroso está ligado a la carga del módulo nativo, no únicamente a las tareas que se ejecutan durante la instalación.
MALFEX: una campaña que sustituye los paquetes retirados
imgdecode no aparece como un incidente aislado. Forma parte de MALFEX, una campaña que investigadores de Checkmarx y CloudSEK habían relacionado con paquetes npm maliciosos dirigidos a equipos Windows.
Los investigadores han documentado distintas vías de infección, incluidas cargas vinculadas a Overlord RAT, una herramienta de acceso remoto, y una cadena destinada a desplegar un programa que roba información.
En una de esas cadenas, los paquetes desempeñaban funciones separadas: uno descargaba datos cifrados, otro los descifraba y otro ejecutaba el programa resultante. Entre los nombres identificados se encuentran cdn-img-fetch, img-to-native y native-runner.
Tras la retirada de algunos de esos paquetes, el operador publicó sustitutos. La secuencia incluyó imgbundle y runhelper, antes de la aparición de imgdecode.
La cronología documentada por SafeDep muestra la evolución de la campaña:
- 26 de septiembre de 2026: publicación de
cdn-img-fetch,img-to-nativeynative-runner. - 28 de septiembre: npm retira
native-runnereimg-to-native. - 30 de septiembre: aparecen
imgbundle,runhelpery las primeras versiones deimgdecode. - 7 y 8 de octubre: npm retira
imgbundleycdn-img-fetch. - 11 de octubre: se publica la versión 1.0.3 de
imgdecode, que elimina la dependencia anterior deimgbundle.
Esta sucesión es relevante porque muestra cómo una campaña puede adaptarse después de que se hagan públicos sus componentes. Retirar un paquete malicioso no garantiza que la amenaza desaparezca si el responsable publica otro que desempeña la misma función.
La versión 1.0.3 elimina dependencias anteriores
Las diferencias entre versiones ayudan a entender la evolución técnica de imgdecode.
La versión 1.0.0 dependía de otros componentes de la cadena y esperaba que estuviera disponible un archivo con la carga cifrada. Las versiones posteriores trasladaron más funciones al complemento nativo.
Según SafeDep, las versiones 1.0.1 y 1.0.2 todavía llamaban a imgbundle antes de cargar la biblioteca. La versión 1.0.3 eliminó esa dependencia y pudo funcionar sin necesitar otros paquetes de MALFEX.
Este cambio reduce los elementos externos que necesita el ataque para iniciar su actividad. También complica la detección basada exclusivamente en buscar una combinación concreta de dependencias.
Por ese motivo, los investigadores recomiendan revisar no solo los nombres de los paquetes, sino también los archivos de bloqueo de dependencias, el historial de instalaciones y el comportamiento observado en los equipos.
Qué información puede robar el malware
La campaña MALFEX está vinculada a cargas capaces de recopilar información sensible de los equipos comprometidos. El análisis del programa relacionado con el robo de datos describe objetivos que abarcan desde archivos de configuración hasta información almacenada por aplicaciones de uso habitual.
Entre los datos que puede buscar el malware asociado a la campaña figuran:
- Credenciales y archivos sensibles, incluidos archivos
.env, certificados y claves privadas con extensiones como.pemy.ppk. - Bases de datos de contraseñas, incluidas las que utilizan el formato
.kdbx. - Información de navegadores basados en Chromium, que puede contener datos de sesión y otros elementos sensibles.
- Datos de Discord y Telegram, aplicaciones utilizadas tanto para comunicaciones personales como profesionales.
- Información de carteras de criptomonedas, incluidas frases semilla que permiten recuperar el acceso a los fondos.
- Datos de plataformas de videojuegos, entre ellas Steam, Epic Games, Riot, Battle.net, Minecraft y Ubisoft.
La importancia de estos objetivos va más allá de la pérdida de archivos. Una clave privada expuesta puede facilitar el acceso no autorizado a sistemas; una contraseña reutilizada puede abrir la puerta a otros servicios; y una frase semilla comprometida puede permitir que un tercero controle los activos digitales asociados.
El análisis de SafeDep también describe capacidades de acceso remoto en la carga relacionada con MALFEX, como ejecución de comandos, transferencia de archivos, control de procesos, acceso al portapapeles y capturas de pantalla. Sin embargo, la relación entre la cadena anterior de robo de información y la carga concreta descargada por imgdecodeno está completamente demostrada: SafeDep indica que no logró recuperar el archivo banner.jpg utilizado por el nuevo cargador.
El malware intenta dificultar el análisis de seguridad
Otro aspecto de la campaña son las comprobaciones destinadas a detectar entornos de análisis.
El malware relacionado con MALFEX puede buscar indicios de máquinas virtuales, entornos aislados y herramientas de investigación, como Process Monitor o Wireshark. Este comportamiento puede ayudar a los atacantes a evitar que la carga se ejecute cuando sospechan que el programa está siendo examinado.
El componente analizado también puede establecer comunicaciones con un servidor de mando y control, conocido como C2, desde el que recibir órdenes. Entre las capacidades descritas figuran la ejecución de comandos, la transferencia de archivos y el control de determinadas funciones del equipo.
Para intentar mantenerse activo, el malware relacionado con la campaña puede crear una entrada de ejecución automática en el Registro de Windows y una tarea programada con el nombre MicrosoftEdgeUpdateService.
Ese nombre recuerda a un servicio legítimo, pero su presencia debe investigarse en contexto. Un nombre parecido al de un componente de Windows no demuestra por sí solo que un archivo sea malicioso; lo importante es comprobar su ubicación, firma, proceso de origen y comportamiento.
Qué deben hacer los desarrolladores que hayan instalado imgdecode
SafeDep recomienda considerar potencialmente comprometido cualquier equipo Windows en el que se haya cargado el paquete. La prioridad es evitar que una posible infección siga propagándose y proteger las credenciales que pudieran haberse expuesto.
Las medidas de respuesta incluyen:
- Aislar el equipo afectado de la red para limitar nuevas comunicaciones con la infraestructura del atacante.
- Revisar los archivos
package.jsony los archivos de bloqueo, comopackage-lock.json, para comprobar si apareceimgdecodey qué versión se utilizó. - Conservar registros y evidencias antes de realizar cambios que puedan dificultar el análisis forense.
- Investigar procesos, tareas programadas, entradas del Registro y conexiones de red sospechosas, con ayuda del equipo de seguridad si se trata de un entorno profesional.
- Cambiar las contraseñas y revocar los tokens o claves de acceso expuestos, utilizando un dispositivo que se considere limpio.
- Si las frases semilla de una cartera de criptomonedas pudieron quedar expuestas, crear una cartera nueva en un entorno seguro y trasladar los fondos a ella. Cambiar únicamente la contraseña de la aplicación no protege una frase semilla comprometida.
No es suficiente con desinstalar el paquete si el código ya se ha ejecutado y ha podido instalar componentes adicionales. La recuperación debe basarse en una evaluación del equipo, la revocación de credenciales y, cuando proceda, una reinstalación desde una fuente confiable.
Un aviso para toda la cadena de suministro del software
El caso de imgdecode demuestra que la revisión de dependencias debe ir más allá de comprobar el nombre y la descripción de una biblioteca. También es necesario analizar el código incluido, los complementos compilados, el historial de versiones y las conexiones que se producen cuando una aplicación carga un módulo.
Para las empresas, esto significa reforzar los controles sobre las dependencias de código abierto, mantener inventarios de componentes y monitorizar comportamientos anómalos en los equipos de desarrollo. Para los desarrolladores individuales, supone desconfiar de paquetes inesperados y revisar cuidadosamente las dependencias antes de incorporarlas a un proyecto.
MALFEX ilustra cómo un paquete pequeño puede servir de puerta de entrada a una cadena de malware mucho más compleja. La cifra de descargas refleja el alcance potencial de la exposición, pero no permite calcular cuántos equipos han sido comprometidos. Esa distinción es esencial para dimensionar el incidente sin minimizar el riesgo ni exagerar sus consecuencias.
La recomendación final es clara: si un equipo Windows ha cargado imgdecode, debe tratarse como potencialmente comprometido hasta que una investigación técnica determine lo contrario.


