La comunidad de Arch Linux ha vivido uno de los mayores sustos de seguridad de su historia reciente. Entre el 11 y el 13 de junio de 2026, un ataque a la cadena de suministro —bautizado «Atomic Arch» por los investigadores de Sonatype— logró colar malware en cientos de paquetes del AUR (Arch User Repository). Lo que empezó con poco más de 400 paquetes comprometidos acabó escalando, en cuestión de horas, hasta más de 1.500.
La buena noticia, y conviene dejarla clara desde el principio: los repositorios oficiales de Arch no se vieron afectados. El problema se limitó al AUR, el repositorio comunitario donde cualquiera puede subir recetas de compilación y que —por diseño— no pasa la misma revisión que los paquetes oficiales. El equipo de Arch eliminó los commits maliciosos y dio el incidente por controlado: «creo que de momento hemos borrado todos los commits maliciosos que conocemos», señaló el empaquetador Jonathan Grotelüschen en la lista de correo del proyecto.
A continuación te contamos cómo se coló el malware, qué roba y, lo más importante, cómo comprobar si estás afectado y qué hacer si lo estás.
Cómo se coló el malware: paquetes huérfanos y PKGBUILD
El ataque no explotó ningún fallo técnico, sino el propio modelo de confianza del AUR. Los atacantes fueron a por paquetes huérfanos: proyectos legítimos que sus mantenedores originales habían abandonado. El AUR permite «adoptar» un paquete sin dueño mediante un proceso estándar, así que los atacantes simplemente reclamaron la propiedad de decenas de ellos.
Una vez al mando, modificaron el PKGBUILD, el script con las instrucciones de compilación que ayudantes como yay o paru ejecutan en tu equipo al instalar. Y ahí está la clave del peligro: un PKGBUILD se ejecuta con tus permisos durante la instalación. Los scripts manipulados descargaban en silencio dos paquetes maliciosos —atomic-lockfile (vía npm) y js-digest (vía bun)— que servían como puerta de entrada del malware.
Qué roba el malware: un infostealer con disfraz
El payload era un infostealer escrito en Rust, diseñado para vaciar de credenciales el equipo infectado. Entre lo que buscaba y exfiltraba:
- Credenciales de los navegadores: contraseñas guardadas, cookies de sesión y datos de autorrelleno de navegadores basados en Chromium y Firefox.
- Claves SSH privadas, con las que saltar a otros servidores y repositorios.
- Variables de entorno y secretos: tokens de API, credenciales de la nube, claves de acceso y tokens de HashiCorp Vault.
- Datos de aplicaciones de trabajo en equipo, del tipo de las que guardan sesión iniciada todo el día.
- Carteras de criptomonedas, incluidas sus frases semilla. Algunas variantes instalaban además mineros.
Lo más inquietante es su sigilo. En los equipos donde consiguió privilegios elevados, el malware desplegaba un rootkit basado en eBPF: disfrazaba sus procesos de hilos del kernel para pasar desapercibido ante herramientas habituales como ps o htop, y dejaba persistencia en servicios de systemd y en rincones como /var/lib/ o mapas BPF ocultos en /sys/fs/bpf/.
Que use eBPF no es un detalle menor: es un subsistema del propio kernel pensado para observar el sistema desde dentro, así que un rootkit montado ahí puede filtrar lo que ven las herramientas de diagnóstico en lugar de esconderse de ellas. Por eso limpiarlo a mano es tan poco fiable.
Cómo saber si estás afectado y qué hacer
1. Revisa tus paquetes del AUR
Lo primero es listar los paquetes «foráneos», es decir, los que no vienen de los repositorios oficiales (en la práctica, los del AUR). Abre una terminal y ejecuta:
pacman -Qm
Contrasta esa lista con los paquetes comprometidos que la comunidad ha ido publicando (entre los confirmados aparecían nombres como alvr o premake-git, y en oleadas posteriores boringssl-git, icloudpd o pgadmin4-server). Sospecha especialmente de cualquier paquete del AUR que instalaras o actualizaras a partir del 11 de junio de 2026.
Y si quieres acotar por fecha en lugar de ir nombre por nombre, el registro de pacman te dice exactamente qué tocaste y cuándo:
grep -E "installed|upgraded" /var/log/pacman.log | grep "2026-06-1"
2. Busca rastros del ataque
Revisa el historial de compilación en busca de líneas como npm install atomic-lockfile, bun install js-digest o rutas del tipo src/hooks/deps. Para cazar persistencia y procesos ocultos, pasa un escáner como rkhunter o chkrootkit y revisa los servicios de systemd.
3. Si tienes dudas, rota tus credenciales
Ante la mínima sospecha, da por comprometido todo lo que busca el infostealer y cámbialo desde otro equipo limpio:
- Contraseñas y sesiones del navegador.
- Claves SSH y tokens de GitHub, GitLab o npm.
- Tokens y claves de servicios en la nube, Docker y gestores de secretos.
- Cualquier cartera de criptomonedas que tuvieras en el equipo.
Tienes los detalles sobre cómo funciona el repositorio en la página del AUR en la Arch Wiki.
Lo que ha pasado desde entonces: tres oleadas y el AUR con la puerta cerrada
En junio parecía un incidente puntual y resuelto. No lo era: «Atomic Arch» fue solo la primera de tres oleadas.
- La primera, la de este artículo, arrancó el 11 de junio de 2026. Empezó con unos 400 paquetes y las cifras que se manejaron públicamente rondaron los 1.500; la lista consolidada que fue montando la comunidad acabó recogiendo cerca de 2.000 nombres de paquete afectados.
- La segunda llegó a mediados de junio, con más de 70 paquetes alterados por el mismo procedimiento.
- La tercera es la que ha colmado el vaso: al menos 27 paquetes más, con los investigadores avisando de que la lista podía seguir creciendo.
Ante eso, en agosto de 2026 Arch Linux ha tomado la medida que faltaba: desactivar la adopción de paquetes en el AUR. Lo anunció Robin Candau, del equipo de DevOps del proyecto: «debido a la afluencia actual de adopciones maliciosas de paquetes y de los commits que vienen detrás, la adopción de paquetes está deshabilitada mientras gestionamos la situación».
Es una medida temporal y volverá cuando haya una solución mejor, pero merece la pena entender lo que significa: han cerrado la puerta exacta por la que entraron los atacantes. Adoptar un paquete huérfano era un trámite pensado para que el software abandonado no se pudriera, y se convirtió en la vía de entrada más cómoda del AUR.
Qué te cambia esto a ti
- Si mantienes un paquete en el AUR, de momento no vas a poder adoptar ninguno más. Es lo que hay.
- Si solo instalas cosas, sigue como estaba: el AUR funciona, se puede instalar y actualizar con normalidad, y los repositorios oficiales nunca estuvieron en riesgo.
- Si instalaste algo del AUR entre junio y agosto de 2026 sin mirar el PKGBUILD, pásate por el apartado anterior. Que hayan cerrado la puerta no deshace lo que ya entró.
Fuentes
