Rust sufre un ataque a su cadena de suministro: una versión maliciosa de la popular biblioteca arrayref llega a crates.io

El ecosistema Rust acaba de enfrentar uno de los incidentes de cadena de suministro más delicados de los últimos años. Una versión maliciosa de la popular biblioteca arrayref fue publicada en crates.io, el repositorio central de paquetes de Rust, y llegó a incluir una dependencia fraudulenta capaz de descargar una carga maliciosa durante el proceso de compilación.

El equipo de respuesta de seguridad de Rust confirmó que el crate proc-macro1 era malicioso porque contenía un build script que descargaba un payload. También informó que arrayref fue republicado recientemente para depender de ese crate, y que otros paquetes del mismo autor, como internment y append-only-vec, también se vieron afectados.

1. Qué ocurrió con arrayref

El incidente comenzó el 20 de agosto de 2026. Según el blog oficial de Rust, a las 07:15 UTC se recibió un reporte sobre el crate malicioso proc-macro1. El equipo de seguridad verificó que el paquete contenía un script de compilación que descargaba una carga maliciosa, por lo que eliminó proc-macro1 y otros paquetes similares de crates.io.

La versión comprometida de arrayref fue 0.3.10. Estuvo disponible en crates.io durante 86 minutos, desde las 07:15:00 UTC hasta las 08:41:40 UTC, antes de ser eliminada. El equipo de Rust también eliminó internment 0.8.7 y append-only-vec 0.1.9, que estuvieron en línea durante 90 y 107 minutos respectivamente.

2. Por qué este ataque es tan grave

arrayref no es una biblioteca desconocida. JFrog identificó el compromiso de tres crates ampliamente utilizados: arrayref 0.3.10, con aproximadamente 245 millones de descargas; internment 0.8.7, con cerca de 14,4 millones; y append-only-vec 0.1.9, con alrededor de 4,5 millones. Los tres incorporaban silenciosamente una dependencia llamada proc-macro1, un nombre diseñado para parecerse al crate legítimo proc-macro2.

La gravedad está en el momento de ejecución. En Rust, los scripts build.rs pueden ejecutarse durante la compilación. Eso significa que el malware podía ejecutarse en estaciones de desarrollo, servidores de integración continua, runners de CI/CD o entornos de build, incluso si el código de la biblioteca nunca era usado directamente por la aplicación. Wiz resumió el riesgo: construir un proyecto afectado era suficiente para ejecutar el payload.

3. El truco: proc-macro1, un typosquat peligroso

El paquete malicioso usado como intermediario fue proc-macro1, un nombre que intenta parecerse al crate legítimo proc-macro2. Este tipo de ataque se conoce como typosquatting: el atacante publica un paquete con un nombre similar al de un paquete real, esperando que usuarios o sistemas lo acepten por error.

StepSecurity informó que arrayref 0.3.10 añadió por primera vez una dependencia normal llamada proc-macro1 1.0.107. Ese crate contenía un build.rs que descargaba un binario remoto, lo escribía en una ubicación temporal y lo ejecutaba de forma separada del proceso de compilación.

Proyecto Rust
  ↓
Cargo resuelve arrayref 0.3.10
  ↓
arrayref 0.3.10 depende de proc-macro1
  ↓
proc-macro1 ejecuta build.rs durante la compilación
  ↓
build.rs descarga y ejecuta una carga maliciosa
  ↓
La máquina de desarrollo o CI puede quedar comprometida

4. El ataque fue breve, pero no necesariamente inofensivo

Una lectura superficial podría minimizar el incidente porque las versiones maliciosas fueron eliminadas rápidamente. Pero en seguridad de cadena de suministro, una ventana de menos de dos horas puede ser suficiente para comprometer pipelines automáticos, runners efímeros, cachés locales o máquinas de desarrolladores que ejecutaron builds justo en ese periodo.

JFrog advirtió que el hecho de que la URL del payload ya no esté activa no significa que el ataque haya fallado. Por la popularidad de arrayref, incluso una exposición breve podía permitir robo de secretos, implantación de malware posterior o contaminación de entornos de build.

StepSecurity fue aún más directo: si un proyecto resolvió arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9, proc-macro1 o proc-macro-en durante la ventana de exposición, la máquina que compiló debe tratarse como potencialmente comprometida.

5. ¿Fue culpa del mantenedor?

El equipo de seguridad de Rust señaló que no cree que el autor de arrayref haya actuado de forma maliciosa. La evaluación pública indica que probablemente su equipo o sus credenciales fueron comprometidos. Como precaución, el equipo bloqueó la cuenta asociada mientras intentaba contactar al mantenedor.

Socket también reportó que los tres crates afectados eran mantenidos por la misma cuenta y que la hipótesis principal era compromiso del equipo del mantenedor o de sus credenciales de publicación en crates.io, no una acción maliciosa del autor legítimo.

6. La maniobra de yanking: empujar a los usuarios hacia la versión mala

Uno de los detalles más preocupantes fue el uso del mecanismo de yanking. Según el análisis de StepSecurity, después de publicar arrayref 0.3.10, la misma cuenta marcó como yanked varias versiones anteriores legítimas, lo que podía empujar a desarrolladores y sistemas CI a ejecutar cargo update y resolver hacia la versión maliciosa disponible.

El yanking en crates.io no elimina una versión ni rompe builds existentes con lockfiles ya resueltos. Pero sí puede generar advertencias que llevan a equipos a actualizar “por higiene”, justo lo que el atacante pudo haber intentado explotar. El resultado es inquietante: una característica pensada para seguridad y mantenimiento pudo convertirse en una herramienta de presión para instalar la versión contaminada.

7. Qué paquetes deben buscar los equipos

El equipo de Rust recomendó revisar dependencias locales para confirmar que los paquetes maliciosos no hayan sido descargados. La lista oficial incluye append-only-vec 0.1.9, arrayref 0.3.10, internment 0.8.7 y cualquier versión de proc-macro1, proc-macro-en, aovine, arone, aronenao o tinymember.

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

Además, los equipos deben revisar Cargo.lock, porque el lockfile es la evidencia clave de qué versión fue realmente resuelta. Un Cargo.toml con una restricción amplia como arrayref = "0.3" no basta para saber si se usó la versión comprometida; hay que mirar la versión exacta registrada en el lockfile.

8. Qué hacer si tu proyecto usó una versión afectada

Si un equipo detecta que una máquina de desarrollo, servidor CI/CD o runner de compilación descargó o compiló una versión afectada, debe actuar como si esa máquina hubiera estado expuesta a ejecución de código malicioso. No basta con borrar la dependencia y seguir trabajando.

9. Versiones seguras recomendadas

StepSecurity identificó como últimas versiones limpias arrayref 0.3.9, internment 0.8.6 y append-only-vec 0.1.8. Las versiones maliciosas fueron eliminadas de crates.io y las versiones legítimas previamente yankeadas fueron restauradas.

# En Cargo.toml, si necesitas fijar temporalmente:
arrayref = "=0.3.9"
internment = "=0.8.6"
append-only-vec = "=0.1.8"

# Luego verificar Cargo.lock:

grep -E "name = "(arrayref|internment|append-only-vec|proc-macro1|proc-macro-en)"" Cargo.lock -A 2

10. Por qué cargo audit puede no ser suficiente

En un ataque de este tipo, depender únicamente de herramientas de auditoría puede ser peligroso. Si una versión fue eliminada del registro, o si la máquina ya conserva una copia en caché o en un directorio vendor, el problema puede sobrevivir fuera de crates.io. StepSecurity advierte que la eliminación del registro no limpia automáticamente cachés locales, runners CI ni artefactos ya descargados.

La revisión debe ser doble: dependencias resueltas y evidencia local. Es decir, buscar en Cargo.lock, pero también en ~/.cargo/registry/cache, imágenes de CI, caches de runners, directorios vendor/ y artefactos de build almacenados.

11. Qué revela este incidente sobre la seguridad de Rust

Rust sigue siendo un lenguaje muy fuerte para seguridad de memoria, concurrencia y confiabilidad. Pero este caso recuerda que la seguridad de un lenguaje no elimina el riesgo de su ecosistema. Una aplicación puede estar escrita en Rust seguro y aun así ser comprometida mediante una dependencia maliciosa, un token robado, un maintainer account comprometido o un build script peligroso.

El incidente también muestra que crates.io es una pieza crítica de infraestructura. Su disponibilidad, sus controles de publicación, su gestión de yanking, su monitoreo de anomalías y sus mecanismos de respuesta son tan importantes como el compilador o el gestor de paquetes.

12. Medidas preventivas para empresas que usan Rust

Las organizaciones que usan Rust en producción deben tratar este incidente como una oportunidad para reforzar su cadena de suministro. No basta con confiar en que crates.io eliminará paquetes maliciosos. El control debe estar también en el repositorio interno, el pipeline, el lockfile, las políticas de actualización y la observabilidad de CI/CD.

13. Errores comunes después de un incidente de dependencias

14. Preguntas clave

Recomendamos

En resumen

El ataque contra arrayref demuestra que incluso ecosistemas modernos y seguros como Rust pueden sufrir incidentes graves de cadena de suministro. La versión maliciosa arrayref 0.3.10 llegó a crates.io, incorporó una dependencia fraudulenta llamada proc-macro1 y ejecutaba código durante la compilación.

La rápida reacción del equipo de Rust redujo la ventana de exposición, pero no elimina el riesgo para quienes compilaron durante ese periodo. Las empresas deben revisar lockfiles, caches, runners CI/CD, artefactos, tráfico saliente y secretos. La seguridad de Rust no termina en el lenguaje: también depende de la confianza en crates.io, los mantenedores, los tokens de publicación y los pipelines de construcción.