El paquete npm indexed-btree mueve su carga al runtime para esquivar los bloqueos
Imitaba a sorted-btree y no usaba scripts de instalación: el código malicioso se disparaba desde la propia librería. Checkmarx le atribuye millones de descargas y 109 ETH en beneficios.
Un paquete npm malicioso llamado indexed-btree se ejecutaba desde el código de la propia aplicación en lugar de usar scripts de ciclo de vida, según el análisis de Checkmarx. Es una de las primeras campañas de cadena de suministro documentadas que se adapta al cambio de npm 12, que bloquea la ejecución automática de preinstall y postinstall durante la instalación.
El paquete imitaba a sorted-btree, una utilidad legítima de indexación B-tree. La carga iba escondida dentro del método BTree.prototype.set(), que disparaba sharedLoad.min.js, un payload JavaScript con la primera etapa ofuscada. Desde ahí el malware hacía fingerprint del host, mandaba los datos a un canal de Slack y a un bot de Telegram hardcodeados, y usaba la técnica EtherHiding para traerse blobs cifrados desde un contrato inteligente desplegado en la testnet Sepolia. Esos blobs se fusionaban para formar la segunda etapa. El último paso borraba los artefactos y quitaba el disparador del código del paquete para no dejar rastro.
Millones de descargas antes de la retirada
Los números del registro dan la medida del problema. indexed-btree se subió el 18 de junio de 2026 desde la cuenta charlessadler25 y acumuló millones de descargas en poco tiempo, según las estadísticas de npm-stat. La operación pudo reportar al atacante unos 230.933,57 euros en criptomoneda, equivalentes a 109 ETH, según la cifra que maneja la compañía de seguridad. Esa estimación es suya, no de un tercero independiente.
El paquete y su repositorio ya no están disponibles en npm, pero no iba solo. Checkmarx lo vincula a toda una familia retirada de la plataforma: ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map, sliding-score-window y mutex-forge. Todos siguen el mismo patrón de nombres alrededor del mundo B-tree.
El CISO de SOCRadar, Ensar Seker, lo resume así: "npm ha mejorado la seguridad en tiempo de instalación restringiendo los scripts de ciclo de vida de las dependencias, pero esta campaña demuestra que los atacantes pueden simplemente mover la ejecución maliciosa a funcionalidad de runtime que parece legítima". Su recomendación es no quedarse en el escaneo durante la instalación y añadir análisis de comportamiento en ejecución.
PolinRider reaparece en Packagist
En paralelo, Socket ha eliminado código malicioso de la versión dev-main de visanduma/nova-two-factor, un paquete de Packagist con más de 700.000 descargas acumuladas. Forma parte de la campaña PolinRider, asociada a Corea del Norte, que compromete cuentas de desarrollador para inyectar código en repositorios Git y usa gestos cotidianos, como clonar un repositorio o abrirlo en el IDE, como disparador de la infección.
La organización Visanduma arrastra el compromiso desde mediados de junio de 2026 y los cambios entraron por la cuenta LaHiRu, según el investigador de Socket Karlo Zanki. En esta iteración han metido JavaScript muy ofuscado dentro de index.php y lo ejecutan con shell_exec() de PHP: el punto de entrada depende del proyecto comprometido, no de una ruta fija.
Para quien mantiene dependencias, el mensaje es incómodo. Bloquear scripts de instalación elimina un camino, no la amenaza, y el escaneo previo a la instalación ya no basta cuando el disparador vive dentro del código que tu aplicación llama en producción.
