El ataque a la cadena de suministro de arrayref, y por qué tu wallet no necesita un punto único de fallo

El 20 de agosto de 2026 llegó un informe de que un crate de Rust llamado proc-macro1 era malicioso. El Rust Security Response Team lo confirmó en minutos: el crate llevaba un guion de compilación que descargaba y ejecutaba una carga remota. Compilar cualquier proyecto que incorporaba el crate era suficiente para ejecutarla. Nadie tenía que llamar a ninguna función. La compilación en sí era el detonante.

El objetivo real era arrayref, un crate pequeño y conocido usado por un número enorme de otros proyectos. Su cuenta de propietario había sido comprometida. El atacante publicó una nueva versión de arrayref que dependía del crate falso, y retiró en silencio las versiones antiguas para que la herramienta de compilación dirigiera a los usuarios a la mala.

Nada de esto se trata específicamente de Rust. Se trata de cómo se construye el software: todos dependemos de miles de piezas escritas por otras personas, y cualquiera de ellas puede ser la que está envenenada en silencio. Cuando lo que guarda tu dinero es software, eso deja de ser un problema de desarrollador y se convierte en un problema de dinero.

El atacante no reescribió la biblioteca. Añadió una línea: una dependencia en proc-macro1, un error deliberado en la ortografía de proc-macro2, una de las crates más descargadas de todo el ecosistema. El crate falso es una copia genuina del real, así que la compilación funciona y el software sigue funcionando. Ese es exactamente el punto. Nada parece roto. La carga se ejecuta antes de que notes cualquier cosa.

El guion de compilación reconstruía en silencio la dirección del servidor del atacante a partir de trozos de texto codificado, desactivaba la comprobación de seguridad que verifica la identidad del servidor y descargaba un programa elegido para tu sistema operativo y procesador. En Mac y Linux escribía el archivo en una carpeta temporal y lo lanzaba en segundo plano. En Windows escribía un guion y lo iniciaba oculto. El atacante eligió todo esto para evitar ser notado durante la compilación.

La puerta trasera descargada es malware real, no una prueba. Los investigadores de seguridad que la analizaron encontraron que llama a casa, lee el nombre de tu equipo y usuario, lista tus programas instalados y busca en tu perfil del navegador logins guardados. Se instala para volver tras un reinicio. Puede descargar y ejecutar más código bajo demanda. Si el servidor principal cae, genera nombres de dominio frescos para encontrar uno nuevo.

Las versiones maliciosas se eliminaron rápido: arrayref 0.3.10 estuvo online unas 86 minutos, y los dos crates relacionados unas 90 y 107 minutos. El equipo de Rust bloqueó la cuenta del propietario como precaución y dijo que no cree que el autor actuara en mala fe. Es más probable que fuera comprometido su equipo o su inicio de sesión. El autor de arrayref ha mantenido el crate desde 2009.

Wiz, una empresa de seguridad, encontró que la infraestructura del atacante se superpone con operaciones recientes atribuidas a Corea del Norte, incluidas campañas contra otras bibliotecas populares. No fue un suceso aislado de un aficionado aleatorio. Fue una campaña organizada usando un patrón que ya habían usado antes.

• Objetivo: arrayref 0.3.10, internment 0.8.7 y append-only-vec 0.1.9, todos de una cuenta comprometida.
• Vehículo: una dependencia nueva, proc-macro1, un error ortográfico del omnipresente proc-macro2.
• Detonante: la compilación en sí. Ejecutar cargo build en un proyecto afectado ejecutaba la carga.
• Online: de 86 a 107 minutos antes de la eliminación el 2026-08-20.
• Escala: arrayref tiene 245 millones de descargas y aparece en la mayoría de entornos que usan Rust.

El ataque a arrayref parece impactante porque golpeó una biblioteca popular y de confianza. Pero los números dicen que no debería serlo. La misma clase de ataque lleva años operando contra cada registro de paquetes mayor, y la tasa sube.

Los proveedores que rastrean esto reportan más de un millón de paquetes maliciosos en npm, PyPI, Maven, NuGet y Hugging Face, con el conteo de paquetes maliciosos nuevos en 2025 subiendo unos 75 por ciento respecto al año anterior. El costo estimado de los ataques a la cadena de suministro alcanzó unos 60 mil millones de dólares en 2025, con proyecciones cercanas a 138 mil millones para 2030. Alrededor del 30 por ciento de las brechas de datos ahora involucra a un tercero, y la gran mayoría de las vulnerabilidades en software comercial se encuentran no en el código principal sino en las dependencias que incorpora.

Dos cosas lo empeoran a la vez. Primero, las herramientas que construyen y ejecutan software se han vuelto más complejas, así que hay más piezas móviles que un atacante puede tocar. Segundo, los atacantes usan IA para encontrar objetivos, escribir el código malicioso y escalar la campaña, mientras la gente responsable de revisar cada dependencia son en su mayoría voluntarios no remunerados.

La verdad incómoda en Hacker News, donde el hilo principal llegó a 400 puntos y cientos de comentarios, es que los desarrolladores ven esto venir. Una de las observaciones mejor puntuadas fue que las herramientas de compilación ejecutan código en tu máquina sin tu consentimiento, así que añadir una dependencia es suficiente para comprometerte antes de revisar el código. Otra señaló que lo mismo pasó con la brecha de la librería de compresión xz, y que nadie puede leer cada paquete pequeño del árbol profundo de dependencias para demostrar que está limpio.

La discusión de Hacker News fue inusualmente tranquila y específica, lo que suele ser la señal de una comunidad experimentada lidiando con un problema conocido. Esto es lo que volvió una y otra vez, en sus propias palabras, recortado ligeramente.

Sobre por qué sigue pasando: "¿Por qué, después de tantos ataques previos a la cadena de suministro, los mantenedores de los registros de paquetes siguen permitiendo a cualquiera subir paquetes y empujar actualizaciones sin auditoría de seguridad?" Esa pregunta no era retórica. La secuela era el problema real: "¿Quién financia esta auditoría de seguridad? ¿Deben la gente voluntariar su tiempo libre?"

Sobre las herramientas de compilación: "El problema es que los guiones de compilación se ejecutan automáticamente sin el consentimiento ni la intervención del usuario. Añadir una dependencia es suficiente para comprometerte, antes de que tengas la oportunidad de revisar el código." Varios señalaron que otros gestores de paquetes tienen controles que Cargo no tiene, como poner en lista blanca los guiones de instalación y aplicar una espera a las dependencias de última hora.

Sobre el objetivo: "Las máquinas de desarrollo son objetivos muy jugosos. Suelen tener todo tipo de credenciales tiradas, así que a menudo no es demasiado difícil escalar de ahí a comprometer tus cuentas de nube." Ese es el verdadero premio en la mayoría de estos ataques. No es la máquina. Es todo lo que esa máquina puede alcanzar.

Sobre si importa el lenguaje: "Rust apenas parece mejor que Node en esto." El contrargumento, también muy compartido, es que el ecosistema ya tiene herramientas de auditoría, y varias empresas grandes publican auditorías de las crates de las que dependen. La brecha es que auditar es la excepción, no la norma.

Un detalle destacó. Varios preguntaron qué hacía exactamente el código malicioso, y la respuesta era que nadie podía tenerlo seguro, porque la cuenta del autor fue eliminada y las publicaciones maliciosas fueron borradas del registro en lugar de solo retiradas. El atacante se limpió a sí mismo. Esas son las señas de una operación que ha hecho esto antes.

La mayoría de los ataques a la cadena de suministro apuntan a desarrolladores y empresas, y el daño son credenciales robadas, datos robados o una limpieza lenta y cara. El radio de impacto es un servidor de compilación o una cuenta corporativa.

Una wallet es distinta. El punto entero del software es poder mover tu dinero. Si el código en ese software, o los servidores de los que depende, puede ser comprometido, la brecha puede ir directo a los fondos. No hay ninguna capa de "oops, perdimos algunos logins" entre el atacante y tu saldo.

Por eso el problema de la cadena de suministro y el problema de la autocustodia son el mismo problema. Ambos se tratan de dónde vive realmente la clave que controla tu dinero, y si cualquier punto único de la cadena, una librería, una empresa, un servidor, un mantenedor, un proveedor, puede tomarla.

Un punto único de fallo es simple de definir y difícil de diseñar fuera. Es el único componente que, si es comprometido o deja de funcionar, hace que todo el sistema falle. Para un exchange de custodia, son sus servidores. Si esos son brechados, o simplemente congelan tu cuenta, tu dinero está a su merced. Para una wallet de software que deriva tu clave de un secreto en tu dispositivo, es ese único secreto. Si la app es comprometida a través de una actualización envenenada, o tu dispositivo es tomado, el secreto está expuesto.

La razón por la que estos diseños tienen un punto único de fallo es que son cómodos. Un lugar para poner la clave significa un lugar para firmar y un lugar para hacer copia de seguridad. La comodidad y la seguridad tiran en direcciones opuestas, y la mayoría de los productos eligen la comodidad.

Hay una mejor forma. Divide la autoridad para mover tu dinero en dos o más cosas que un atacante tendría que tomar juntas, y asegúrate de que ninguna de ellas mantiene la clave entera por sí sola. Entonces ninguna brecha sola, una librería mala, un servidor hackeado, un teléfono robado, una actualización maliciosa, gana por sí sola. El atacante tiene que tener éxito dos veces, en dos lugares distintos, al mismo tiempo. Esa es la diferencia entre un objetivo y una fortaleza.

Nuri está construido sobre un esquema de firma dividida llamado MuSig2, en la forma 2-de-2 que puede expandirse a 2-de-3. Se necesitan dos partes separadas para firmar y mover los fondos, y ninguna parte sola puede hacerlo.

En tu teléfono, solo una clave existe nunca: tu propia clave. Se deriva localmente de tu passkey, la credencial biométrica o de dispositivo que desbloquea tu teléfono, a través de una función que la convierte en una clave. Esa clave se genera en tu dispositivo y nunca lo abandona. No se sube, no se envía a un servidor para ser almacenada, y no está incrustada en la app como algo que podría ser extraído de un build comprometido.

La segunda parte está mantenida por el servicio de cofirma de Nuri. Aquí está la parte que importa para esta historia. Ese servicio está construido para ser sin estado. Mantiene la autoridad para cofirmar dentro de la política que has fijado para tu wallet, pero no almacena una copia de tu clave. No hay un almacén de claves de usuario en los servidores de Nuri que brechar. Si la app que ejecutas es comprometida a través de un bug de cadena de suministro, el atacante obtiene una app comprometida, no tu clave. Si los servidores de Nuri son hackeados, el atacante obtiene un servicio sin estado sin claves de usuario que tomar. Ninguno de los dos eventos, por sí solo, expone la clave privada.

El resultado es que el patrón de arrayref, una dependencia envenenada que ejecuta código en la compilación, no se traduce en una wallet robada. La clave que importa está en el teléfono, derivada de algo en el teléfono, y la segunda pieza de firma vive con un servicio que no tiene nada que entregar. Robar el dinero requiere dos partes completas, y están en dos lugares distintos que el atacante tendría que alcanzar a la vez.

El diseño también mantiene una salida. El acuerdo de cofirma tiene un límite de tiempo. Después de una ventana fija, el usuario tiene una ruta de recuperación independiente que no depende del cofirmante. Y si quieres aún más separación, se puede añadir una wallet de hardware como tercera parte, haciendo 2-de-3, de modo que ningún dispositivo o servicio solo, teléfono o servidor, mantiene suficiente para mover tus fondos.

Ataque a la cadena de suministro

Una brecha de un componente o dependencia en el que otros confían, para que el atacante alcance a todos los que lo usan.

Typosquat

Un nombre que parece uno conocido con un pequeño cambio de ortografía, para ser tomado por error. proc-macro1 por proc-macro2.

Guion de compilación

Código que se ejecuta automáticamente cuando se compila un proyecto. En Rust puede ejecutarse antes que tu propio código, por eso es un objetivo primario.

Punto único de fallo

El único componente cuya pérdida o brecha hace fallar todo el sistema.

Autocustodia

Tú mantienes la autoridad para mover tu propio dinero, en lugar de que una empresa lo mantenga por ti.

MuSig2

Un esquema de firma que puede dividir el derecho a firmar entre varias claves, para que ninguna sola clave pueda mover los fondos sola.

Sin estado

El servicio no mantiene una copia persistente de tu clave. No hay nada almacenado que una brecha pueda robar.

Passkey

La credencial biométrica o de dispositivo que desbloquea tu teléfono, usada aquí para derivar tu clave localmente.