Cómo 18 paquetes acabaron con puerta trasera

A las 20:24 UTC del 8 de julio de 2026, una cartera que cargó la última versión de @injectivelabs/sdk-ts entregó en silencio su frase semilla a un atacante. El primer commit malicioso acababa de llegar y estuvo activo unos 49 minutos antes de que alguien lo notara.

Los atacantes no entraron a la fuerza. Usaron la cuenta de GitHub de un colaborador de confianza y ya establecido para empujar tres commits que pusieron una puerta trasera en el SDK en la versión 1.20.21, más 17 paquetes dependientes fijados a esa versión exacta. Dieciocho paquetes en total llevaban el mismo veneno. La puerta trasera enganchó PrivateKey.fromMnemonic() y PrivateKey.fromHex(), de modo que exfiltraba frases semilla BIP-39 y claves privadas en el instante en que una cartera se iniciaba.

Se produjeron unas 310 descargas antes de que el mantenedor lo detectara, lo revirtiera y publicara una versión limpia 1.20.23. Injective Labs dice que no se perdieron fondos de usuarios. La versión maliciosa se marcó como obsoleta en npm en lugar de eliminarse, así que sigue en el registro como señal de advertencia.

La canalización de confianza era el punto débil

La salvaguarda era el mecanismo de entrega. La versión maliciosa viajó por la propia canalización de publicación de confianza de Injective Labs en npm, la vía OIDC construida precisamente para eliminar el riesgo de un token de publicación robado.

Esa es la parte incómoda. La publicación de confianza OIDC significa que un paquete puede lanzarse sin ningún token npm de larga duración que robar, lo cual es una mejora real de seguridad. Pero también significa que una cuenta humana comprometida más una compilación automatizada convierten esa confianza en la vía de ataque. No había token que filtrar porque la propia canalización hacía la firma, y la canalización confiaba en la cuenta que GitHub decía que era legítima.

Qué revisar en tus propias dependencias

La lección aquí es general, no específica de las criptomonedas. Cualquier responsable que publique software hereda esta misma exposición a través de dependencias transitivas, los paquetes de los que dependen tus paquetes y que nunca elegiste instalar directamente.

Fija tus dependencias transitivas a versiones de confianza conocida y escanéalas, para que un cambio a mitad de camino en una versión fijada aparezca como una modificación en lugar de colarse. Trata la automatización del publicador de confianza como la reducción de un riesgo, no como la eliminación de todos, porque la vía de la cuenta humana comprometida sigue abierta. Y rota cualquier secreto, clave o credencial que pasara por una compilación que ahora sospechas, dando por hecho que fue vista.

Leer a continuación: Progress ordena apagar a los clientes de ShareFile  |  Un fallo de Defender da a un usuario el control total