La primera dependencia nueva en diez años
El 20 de agosto de 2026, un atacante que había comprometido una cuenta de mantenedor en crates.io, el registro oficial de paquetes de Rust, usó ese acceso para publicar versiones envenenadas de tres crates muy utilizados: arrayref, internment y append-only-vec. Arrayref por sí solo está presente en más del 35 por ciento de todos los entornos de Rust y en aproximadamente tres de cada cuatro entornos donde Rust aparece, lo que lo convierte en una de las bibliotecas pequeñas más omnipresentes de todo el ecosistema, aunque pase casi desapercibida.
La versión maliciosa arrayref 0.3.10 llevaba un detalle que por sí solo debería haber sido una señal de alarma: era la primera dependencia nueva que arrayref había añadido en toda su historia de diez años. Que un crate que ha publicado actualizaciones sin dependencias durante una década adquiera de pronto una es exactamente el tipo de cambio que una revisión cuidadosa de dependencias debería señalar, si es que alguien la estaba revisando.
Un script de compilación se ejecutó antes que ningún código
Cada versión envenenada añadía una dependencia a un nuevo crate llamado proc-macro1, que también era malicioso. Proc-macro1 incluía un script de compilación, un pequeño programa que Cargo, la herramienta de compilación de Rust, ejecuta automáticamente como parte de la compilación de un proyecto, antes de que el propio código del proyecto haya terminado de construirse o se haya ejecutado siquiera.
Esa ejecución automática es lo que hizo que el ataque pasara tan desapercibido: un desarrollador o una canalización de CI no necesitaba ejecutar el binario final, hacer clic en nada ni importar una función sospechosa para verse comprometido. Bastaba con ejecutar cargo build en un proyecto que dependiera del crate envenenado para activar el script de compilación y descargar la carga útil del atacante.
Retirar y empujar: un truco tomado de npm
El atacante también retiró las versiones antiguas y limpias de arrayref, de la 0.3.5 a la 0.3.9, del registro. Retirar una versión no la elimina por completo, pero sí hace que Cargo muestre su advertencia habitual de que un proyecto debería considerar actualizar a una versión que no esté retirada.
Con todas las versiones limpias marcadas como retiradas, la única versión no retirada que le quedaba a Cargo para recomendar era la maliciosa 0.3.10, lo que empujaba a los desarrolladores hacia la versión envenenada a través de las propias herramientas del registro. Los investigadores de seguridad ya habían señalado este mismo patrón de retirar y empujar en ataques previos a la cadena de suministro de npm, por lo que su aparición en crates.io sugiere el mismo manual de ingeniería social a través de herramientas, no una invención nueva.
Tres crates, tres ventanas breves
Las tres versiones maliciosas se publicaron dentro de una ventana de 22 minutos en la mañana del 20 de agosto de 2026, y las tres fueron retiradas entre aproximadamente 90 y 107 minutos después de publicarse, una vez que el Rust Security Response Team bloqueó la cuenta comprometida y retiró los paquetes.
| Crate | Versión maliciosa | Publicado (UTC) | Retirado (UTC) | Minutos en línea |
|---|---|---|---|---|
| arrayref | 0.3.10 | 07:15 | 08:41 | 86 |
| internment | 0.8.7 | 07:34 | 09:04 | 90 |
| append-only-vec | 0.1.9 | 07:37 | 09:25 | 107 |
Una ventana de menos de dos horas suena breve, pero crates.io no tiene ningún retraso incorporado entre publicar una versión nueva y que cualquier proyecto dependiente pueda descargarla automáticamente en su siguiente compilación, así que incluso una ventana corta basta para que un script de compilación alcance a cualquier proyecto que se recompile durante ese tiempo.
Robo de credenciales, un interruptor de apagado y un vínculo con Corea del Norte
Wiz Research analizó la carga útil y encontró una puerta trasera que se comunica con un servidor remoto por HTTPS, enumera las credenciales guardadas en Chrome, Brave y Edge, instala persistencia multiplataforma y puede ejecutar cuatro comandos remotos distintos, entre ellos un interruptor de apagado y una orden para ejecutar scripts arbitrarios.
Wiz también descubrió que el punto de conexión de la puerta trasera comparte infraestructura con la campaña Mastra, que Microsoft atribuyó a Sapphire Sleet, un grupo vinculado a Corea del Norte, y con un ataque previo al paquete npm axios que Google Cloud Threat Intelligence y Mandiant vincularon por separado también a Corea del Norte, lo que sugiere que el mismo tipo de actor que ya comprometió npm ha demostrado ahora la misma capacidad contra crates.io. El descubrimiento se atribuye a Nextron Systems GmbH, una firma alemana de seguridad; el Rust Security Response Team bloqueó la cuenta y retiró las tres versiones, y hasta ahora no ha surgido ninguna evidencia confirmada de explotación real.
Rust resuelve errores de memoria, no quién controla la cuenta
La Ley de Ciberresiliencia de la UE y la directiva NIS2 llevan tiempo empujando a los fabricantes de productos críticos para la seguridad y conectados hacia lenguajes seguros en memoria, y Rust ha sido uno de los principales beneficiados de ese empuje. Este incidente es un recordatorio de que migrar a Rust por motivos de cumplimiento resuelve un problema, los errores de seguridad de memoria como los desbordamientos de búfer, sin tocar otro completamente distinto: quién controla la cuenta que publica las dependencias de un proyecto, y qué puede ejecutar un script de compilación antes de que el propio código del proyecto termine siquiera de compilarse.
Los propietarios que ordenaron una migración a Rust por motivos de cumplimiento deberían preguntar a sus equipos de ingeniería tres cosas concretas: si las actualizaciones de dependencias se revisan antes de fusionarse, si la canalización de CI puede aislar o restringir lo que un script de compilación tiene permitido hacer, y si alguien notaría siquiera una retirada y republicación el mismo día en un paquete en el que el equipo ha confiado durante años. Vale la pena señalar que el propio descubrimiento vino de Nextron Systems GmbH, una firma alemana, lo que desmiente cualquier suposición de que este riesgo de cadena de suministro es solo problema de otros.
Leer a continuación: Nadie puede verificar el chip de su llave de seguridad | Su dinero de recompensas compra basura de IA
