El 20 de agosto de 2026, el ecosistema de Rust sufrió uno de los ataques a su cadena de suministro más sofisticados hasta la fecha. La versión 0.3.10 del crate arrayref, una utilidad fundamental con alrededor de 245 millones de descargas históricas, fue publicada con una dependencia maliciosa que ejecuta código arbitrario en las máquinas de quienes simplemente compilan un proyecto. La ventana de exposición fue de apenas 86 minutos, pero el daño potencial es enorme: cualquier quien haya actualizado su lockfile en ese intervalo podría estar comprometido.
Según la reconstrucción de StepSecurity, el ataque comenzó a la 01:17 UTC con la creación de una cuenta de GitHub llamada "dtolney", suplantando a David Tolnay, autor del popular crate proc-macro2. Ocho minutos después se registró la cuenta equivalente en crates.io. A la 01:55 se publicó proc-macro1 1.0.106, una copia exacta e inofensiva del legítimo proc-macro2: una fase de staging para dar credibilidad al nombre suplantado. A las 07:11 llegó la versión 1.0.107, que incorporó build dependencies innecesarias (base64, rustls, ureq). Cuatro minutos más tarde, a las 07:15, la cuenta del mantenedor legítimo de arrayref, droundy, publicó la versión 0.3.10 añadiendo proc-macro1 ^1.0.107 como dependencia. En cuestión de segundos, las versiones 0.3.5 a 0.3.9 fueron yanked de forma masiva, empujando a los usuarios a actualizar hacia la trampa. La comunidad RustSec fue notificada a las 07:54 y crates.io eliminó los paquetes maliciosos alrededor de las 08:41.
El mecanismo del malware es especialmente insidioso. Tal como explican StepSecurity y SafeDep, el código malicioso vive en el build.rs de proc-macro1, lo que significa que basta con compilar para que se ejecute. El script ensambla a partir de fragmentos en base64 la dirección de un servidor (23.254.165.112:9089) y un endpoint de comando y control (23.254.165.112:443), descarga un binario específico para cada plataforma con la verificación de certificados deshabilitada, y lo ejecuta de forma detached: en Unix crea /tmp/rust-setup, mientras que en Windows deja un script PowerShell y un lanzador VBS oculto en %TEMP%. La librería en sí es una copia genuina de proc-macro2, por lo que las compilaciones finalizan con éxito y el malware pasa desapercibido en la salida estándar.
El radio de alcance es preocupante. arrayref es una dependencia transitiva presente en cadenas como tiny-skia → sctk-adwaita → winit, lo que coloca el release malicioso bajo la mayoría de las GUI en Rust, incluyendo egui/eframe e iced. StepSecurity amplía la lista a crates críticos como blake3, blake2b_simd, revm-precompile (en el ecosistema Ethereum) y solana-runtime/spl-token (en Solana). Cualquier pipeline de CI o desarrollador que resolviera arrayref ^0.3 durante la ventana de exposición ejecutó el payload con los privilegios de esa cuenta.
La cuenta droundy, perteneciente a un mantenedor con buena reputación desde 2009, se presume comprometida. Su repositorio en GitHub y el de append-only-vec devuelven 404, lo que impide inspeccionar el código original. SafeDep señala que la versión 0.1.9 de append-only-vec también parece marcada por el mismo actor. Por su parte, StepSecurity publica una lista detallada de indicadores de compromiso: direcciones IP, hashes SHA-256 de los crates maliciosos, archivos depositados, nombres de binarios y la cuenta de correo rchaitm@gmail.com utilizada para falsificar la metadata de autoría.
Para los afectados, la recomendación es rotar credenciales, tokens y claves de firma, y reconstruir artefactos desde fuentes limpias. Quienes no estén comprometidos deben fijar arrayref = "=0.3.9" y nunca responder a las advertencias de yanked con upgrades ciegos. Hasta que la situación del mantenedor se resuelva, Cargo resuelve arrayref ^0.3 a la versión 0.3.4, de 2017.
El incidente reaviva el debate sobre las vulnerabilidades estructurales de los registros de paquetes: la confianza depositada en cuentas de mantenedores históricos, la automatización de yanks masivos como vector de presión, y la ausencia de mecanismos de revisión para nuevas dependencias en builds. La corta ventana de exposición sugiere una operación bien coordinada que aprovecha la inercia de los usuarios ante avisos de seguridad.