A veces pienso que la ciberseguridad es como jugar a las escondidas con alguien que te conoce demasiado bien. Justo cuando crees que estás a salvo, te meten una patada por la espalda. Este martes pasado — 20 de agosto de 2026, para que quede la fecha en la libreta — la comunidad de Rust despertó con una noticia que debería preocupar a cualquiera que compila código de terceros. Y hoy en día, eso somos todos.
Qué pasó exactamente
La historia empieza con un crate llamado arrayref, una librería modesta pero popular: más de 245 millones de descargas en su historia. Un crate que probablemente usas sin saberlo, porque está ahí, debajo del capó, en aplicaciones gráficas como egui, eframe, iced y un montón más.
El atacante hizo algo elegante y aterrador al mismo tiempo. Primero creó una cuenta falsa en crates.io llamada dtolney — una letra de diferencia con dtolnay, el autor real de la librería proc-macro2. Luego publicó un crate llamado proc-macro1, otro typosquat que debería sonar familiar si trabajas con Rust. La versión 1.0.106 era limpia, solo una copia del crate legítimo para ganar confianza. Pero la 1.0.107 incluyó un build.rs malicioso que descarga y ejecuta un binario desde un servidor remoto durante la compilación.
Aquí viene lo peor: no necesitas importar nada. No necesitas llamar a ninguna función del crate. Solo con hacer cargo build ya estás corriendo el payload. El malware se esconde en el script de compilación, invisible para cualquier auditoría de código superficial.
El truco de la yank
Pero el atacante no se quedó ahí. En el mismo minuto que publicó arrayref 0.3.10 — que agregaba como dependencia al proc-macro1 malicioso — también hizo yank de las versiones anteriores 0.3.5 a 0.3.9. Esto hace que Cargo avise al desarrollador: «actualiza, hay versiones viejas marcadas como inseguras». Y muchos, confiando en el ecosistema, simplemente ejecutan cargo update sin pensar. Así caen en la trampa.
La ventana de exposición fue de apenas 86 minutos. Parece poco, pero en el mundo de la compilación automática y los pipelines de CI/CD, eso es una eternidad. Cada job que corrió durante esas horas pudo haber ejecutado código malicioso con los privilegios del usuario de compilación.
Por qué esto me preocupa personalmente
Trabajo con Rust en proyectos de automatización industrial. No es changa, es la pega seria. Y la verdad es que hace tiempo que el ecosistema de crates.io me daba una sensación rara. No hay firmas robustas, no hay revisión previa obligatoria, y cualquiera con una cuenta puede publicar. Es práctico para el desarrollo, pero un desastre esperando a pasar.
Lo que me molesta no es tanto la técnica — que es brillante, hay que reconocerlo — sino la confianza ciega que le tenemos a los registries de paquetes. NPM, PyPI, crates.io, todos tienen el mismo problema fundamental: ejecutamos código de desconocidos sin sandboxing real, y eso es considerado normal.
Qué hacer
Si eres desarrollador Rust, revisa tus Cargo.lock ahora mismo. Busca arrayref 0.3.10 o cualquier mención de proc-macro1. Si aparece, asume que la máquina está comprometida y rota TODO: tokens, claves SSH, credenciales de CI/CD.
Y si eres limpio, aprende de esto: nunca actualices por un yank sin entender por qué. En Rust, una versión marcada como yanked no significa que está rota; significa que el autor no quiere que la uses. Puede ser por seguridad, pero también puede ser parte de un engaño como este.
La próxima vez que veas que un crate de 245 millones de descargas es comprometido en minutos, piensa en esto: el código abierto es una fortaleza, pero las fortalezas necesitan vigilancia. Y últimamente, estamos durmiendo en la guardia.
Fuente de inspiración: Rust Supply-Chain Attack: arrayref 0.3.10 and the proc-macro1 Typosquat Execute a Remote Payload at Build Time
