Rust alerta de ataques a mantenedores: checklist para proteger crates y CI

El proyecto Rust publicó el 17 de septiembre una alerta sobre una campaña de cadena de suministro. El equipo de crates.io y el Security Response Working Group creen que intenta comprometer dispositivos y cuentas de miembros de Rust y propietarios de crates populares para publicar malware. La alerta oficial está firmada por Adam Harvey.

La alerta no afirma que todos los proyectos Rust estén comprometidos ni identifica al autor. Documenta el método: una videollamada de empleo, proyecto o contrato termina pidiendo un supuesto códec o un comando del portapapeles. Los atacantes crean perfiles corporativos plausibles. Rust relaciona el patrón con un ataque de junio y con arrayref, pero no sabe si forman parte de la misma campaña.

Qué está confirmado y qué no

Conviene separar estos hechos:

• Confirmado por Rust: existe una campaña que el proyecto considera activa; el vector incluye ingeniería social, software solicitado durante la llamada y comandos copiados; la recomendación inmediata es desconfiar de contactos inesperados, usar una plataforma de llamadas controlada por el propio equipo y revisar MFA e inicios de sesión.
• Confirmado como incidente anterior: el 20 de agosto, Rust verificó que proc-macro1 incluía un build script que descargaba una carga maliciosa. Versiones republicadas de arrayref, append-only-vec e internment llegaron a depender de él. Rust eliminó las versiones maliciosas y bloqueó preventivamente la cuenta del autor; no consideró que el autor actuara de forma maliciosa, sino que su equipo o sus credenciales probablemente habían sido comprometidos. La respuesta sobre arrayref indica que las versiones estuvieron disponibles entre 86 y 107 minutos, una duración de aquel caso, no una ventana típica.
• No confirmado: que cada mantenedor de Rust sea un objetivo, que todos los crates estén afectados o que la campaña actual sea obra de un actor concreto. La alerta menciona que este estilo se ha observado fuera de Rust y se ha asociado públicamente con actores de Corea del Norte; eso es contexto del patrón, no una atribución de este incidente.

Checklist de 30 minutos para un mantenedor

Si mantienes un crate o administras su pipeline, empieza por lo que puede cambiar el alcance del incidente.

1. Persona y cuenta

1. Activa MFA resistente al phishing donde esté disponible y revisa sesiones, dispositivos y accesos recientes en GitHub, GitLab y crates.io.
2. Confirma los propietarios actuales de cada crate. Retira cuentas que ya no necesiten publicar y exige una segunda revisión para cambios de propietario.
3. Revisa correo de recuperación, aplicaciones OAuth, claves SSH y tokens de publicación. Un token de crates.io es un secreto: si pudo quedar expuesto, revócalo de inmediato; cargo logout solo elimina el token local, no revoca uno ya filtrado.
4. No instales códecs, clientes ni binarios porque lo pida un contacto nuevo. Crea tú la llamada en una plataforma conocida y verifica la identidad por un canal independiente.
5. No ejecutes a ciegas una orden pegada en el portapapeles. Léela en un editor, comprueba el origen y, si hay dudas, consulta al equipo de seguridad.

MFA ayuda, pero no basta: la alerta habla de compromiso de dispositivos y cuentas. Si la estación de trabajo está controlada, una sesión autenticada o un runner también puede convertirse en el punto de publicación.

2. Dependencias y artefactos

El equipo de Rust publicó una lista concreta para el incidente de agosto: 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. Busca esos nombres en el lockfile y en el árbol resuelto, sin asumir que el caché local es la única fuente:

cargo tree --locked | grep -E 'append-only-vec|arrayref|internment|proc-macro1|proc-macro-en|aovine|arone|aronenao|tinymember'

En PowerShell:

cargo tree --locked | Select-String -Pattern 'append-only-vec|arrayref|internment|proc-macro1|proc-macro-en|aovine|arone|aronenao|tinymember'

Repite la comprobación en los caches de CI, mirrors, imágenes de contenedor y artefactos descargados. La respuesta de Rust muestra una búsqueda en ~/.cargo/registry/cache, pero esa ruta no cubre todas las instalaciones. Si aparece una versión afectada, congela la promoción del artefacto, aísla el runner que la procesó y conserva logs, hashes y la imagen antes de limpiar.

Para cada cambio inesperado, compara Cargo.lock, Cargo.toml, propietario, fecha de publicación y contenido del paquete. cargo publish --dry-run verifica empaquetado y compilación inicial, pero no la confianza del workflow, equipo o identidad que publica.

Publicar sin depender de un token permanente

La actualización de crates.io del 21 de enero documenta Trusted Publishing para GitHub Actions y GitLab CI/CD mediante OIDC. El flujo entrega un token de corta duración al job autorizado, en vez de guardar un token API de larga duración en los secretos del pipeline. El mismo sistema permite activar Trusted Publishing only, que deshabilita la publicación tradicional con tokens API para ese crate. También bloquea los triggers pull_request_target y workflow_run, que han participado en incidentes del ecosistema de GitHub Actions.

La actualización de crates.io confirma los controles del registro: OIDC para GitHub Actions y GitLab.com, modo Trusted Publishing only y bloqueo de pull_request_target y workflow_run. Las restricciones concretas de repositorio, workflow, rama o etiqueta, entorno y permisos deben imponerse en la configuración del proveedor de CI. La guía de Rust Forge muestra cómo hacer coincidir publish-environment con el evento y exige en GitHub environment: <publish-environment> y permissions: id-token: write; no presenta esas reglas como una garantía universal de crates.io.

Trusted Publishing reduce el valor de una filtración, pero no cura un runner comprometido. Usa permisos mínimos, una referencia revisada y una ruta de release separada de pull requests no confiables; inspecciona el .crate y su digest antes del publish.

Qué hacer ante una sospecha

1. Detén temporalmente las publicaciones y bloquea el workflow de release; no intentes “arreglar” el incidente publicando otra versión desde el mismo equipo.
2. Aísla la estación o runner y conserva imagen, procesos, logs de CI, eventos de identidad, hashes y Cargo.lock. Evita borrar evidencias antes de que las revise seguridad.
3. Revoca tokens de crates.io, sesiones y claves que hayan podido quedar expuestos; rota secretos derivados y revisa permisos de los propietarios.
4. Comprueba qué versiones llegaron al registro, qué jobs las generaron y qué consumidores descargaron el artefacto. Marca como afectadas las imágenes y builds que dependan de una versión sospechosa.
5. Contacta con help@crates.io si la duda es sobre la cuenta de crates.io o con security@rust-lang.org para el resto de incidentes. No publiques credenciales en un issue público.

El Cargo Book recuerda que una publicación es normalmente permanente: un yank impide nuevas dependencias, pero no borra el código ni rompe los locks existentes. La respuesta debe combinar contención, comunicación y una nueva versión limpia.

Fuentes primarias

• Rust: Be alert: targeted attacks on prominent Rustaceans — alerta del 17 de septiembre de 2026.
• Rust: Supply chain attack on arrayref — incidente, versiones y lista de crates afectados.
• crates.io: development update — Trusted Publishing, modo obligatorio, triggers bloqueados, Security y pubtime.
• Rust Forge: Trusted publishing — requisitos de OIDC, entornos y workflows.
• Cargo Book: Publishing on crates.io — tokens, cargo publish --dry-run, permanencia y yank.
• Rust release announcements — índice oficial revisado el 21 de septiembre de 2026.