Un ataque a la cadena de suministro de Rust cuela malware de compilación en arrayref

Unos atacantes publicaron el 20 de agosto de 2026 versiones maliciosas de tres crates de Rust muy utilizadas - arrayref 0.3.10, internment 0.8.7 y append-only-vec 0.1.9 - en crates.io, y cualquiera que compilara un proyecto que resolviera una de ellas ejecutó malware en su máquina. La carga se ejecutaba durante el propio cargo build, de modo que un desarrollador o un runner de CI nunca tenía que invocar el código envenenado para quedar comprometido.

La ventana de exposición fue corta; el radio de impacto, no. Según The Hacker News, arrayref acumula 245.385.500 descargas totales, 53.905.601 de ellas en los 90 días previos al ataque, y 403 crates la listan como dependencia directa. La firma de seguridad Wiz afirma que arrayref aparece en más del 35% de todos los entornos que observa, y en tres cuartas partes de los entornos donde Rust está presente.

Cómo funcionó el ataque

El Rust Security Response Team dice que recibió un aviso a las 7:15 UTC del 20 de agosto y verificó que la nueva versión de arrayref "tenía un script de compilación que descargaba una carga maliciosa". Las versiones maliciosas no alteraron el código de arrayref. En su lugar, añadieron una nueva dependencia llamada proc-macro1 - un typosquat del ecosistema legítimo proc-macro - cuyo script de compilación descarga y ejecuta un binario remoto al compilar.

El análisis de StepSecurity resume el mecanismo sin rodeos: "Bastaba con compilar cualquier proyecto cuyo lockfile resolviera arrayref 0.3.10 para detonar la carga. El código de la crate nunca necesita ser llamado." El mismo análisis halló que el atacante retiró (yank) todas las versiones limpias 0.3.x de arrayref en una ráfaga programada, "convirtiendo en mecanismo de entrega la propia advertencia de 'yanked version' de Cargo": los desarrolladores que reaccionaban a la advertencia actualizaban directamente a la versión maliciosa.

Según Wiz, la puerta trasera descargada reconstruía sus URL de comando y control a partir de fragmentos en Base64, desactivaba la validación de certificados TLS y traía cargas específicas por plataforma con persistencia para Windows, macOS y Linux, además de la enumeración de credenciales desde perfiles de navegador. Junto a proc-macro1, el Rust Security Response Team identificó otras cinco crates controladas por el atacante: proc-macro-en, aovine, arone, aronenao y tinymember.

crates.io retiró rápido las versiones maliciosas: arrayref 0.3.10 estuvo en línea 86 minutos, internment 0.8.7 durante 90 y append-only-vec 0.1.9 durante 107, según las marcas de tiempo publicadas por The Hacker News. StepSecurity observa que "la operación entera, desde la creación del personaje hasta la retirada del registro, cabe en una sola mañana de trabajo".

Quién está detrás

Lo comprometido fue la cuenta del mantenedor, no el mantenedor. "No creemos que el autor de arrayref actúe con malicia; lo probable es que su equipo o sus credenciales estén comprometidos", declaró el Rust Security Response Team en su comunicado.

Wiz informa de que la infraestructura de la campaña se solapa sustancialmente con operaciones norcoreanas recientes contra cadenas de suministro: comparte el mismo rango de direcciones de Hostwinds 23.254.164.0/23 usado en la campaña Mastra de npm, atribuida a Sapphire Sleet, grupo vinculado a la RPDC, y su tráfico de comando y control iba a una IP que aparece en el análisis de Google Cloud Threat Intelligence sobre los ataques a axios en npm, también atribuidos a Corea del Norte. El manual ya conocido en npm acaba de llegar a crates.io.

Qué significa esto para los desarrolladores

Si alguna de tus máquinas o runners de CI compiló un proyecto de Rust en la mañana del 20 de agosto (UTC), comprueba si el lockfile resolvió arrayref 0.3.10, internment 0.8.7 o append-only-vec 0.1.9, e inspecciona tu caché local del registro: el aviso del Rust Security Response Team pide revisar las dependencias en caché en busca de los nombres de crates maliciosas listados arriba. Trata una máquina que compiló una de ellas como comprometida, no solo expuesta: según Wiz, la carga instala persistencia y enumera credenciales del navegador, así que rota los secretos que esa máquina pudiera alcanzar.

La lección estructural es que los scripts de compilación son una superficie de ejecución remota de código, y los lockfiles son el control. Un Cargo.lock versionado fija versiones exactas, de modo que durante la ventana de 86 minutos la ruta vulnerable era un cargo install limpio o un job de CI sin fijar. Este ataque además convirtió una función de seguridad en cebo: tras el truco del yank, "una versión retirada significa actualizar ya" deja de ser un reflejo seguro. Verifica hacia qué actualizas y trata una dependencia nueva que aparezca en el diff de una crate estable desde hace años como una señal para detenerlo todo.