La comunidad de Arch Linux ha sufrido 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 —denominado «Atomic Arch» por los investigadores de Sonatype— consiguió introducir malware en cientos de paquetes del AUR (Arch User Repository). Lo que comenzó con poco más de 400 paquetes comprometidos acabó escalando, en cuestión de horas, hasta más de 1.500.
Hay una buena noticia que conviene dejar clara desde el principio: los repositorios oficiales de Arch no se vieron afectados. El problema se limitó al AUR, el repositorio comunitario donde cualquier usuario 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.
Cuando tomaron el control, modificaron el PKGBUILD, que es el script con las instrucciones de compilación que ejecutan en tu equipo ayudantes como yay o paru al momento de instalar. Aquí reside la clave del peligro: un PKGBUILD se ejecuta con tus permisos durante la instalación. Los scripts manipulados descargaban discretamente dos paquetes maliciosos —atomic-lockfile (vía npm) y js-digest (vía bun)— que funcionaban 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 las credenciales del 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 como hilos del kernel para pasar desapercibido ante herramientas habituales como ps o htop, y establecía la persistencia en servicios de systemd y en rutas como /var/lib/ o mapas BPF ocultos en /sys/fs/bpf/.
El hecho de que utilice eBPF no es un detalle menor: se trata de un subsistema del propio kernel diseñado para observar el sistema desde dentro, por lo que un rootkit instalado ahí puede filtrar lo que ven las herramientas de diagnóstico en lugar de limitarse a esconderse de ellas. Por este motivo, limpiarlo a mano es tan poco fiable.
Cómo saber si estás afectado y qué hacer
1. Revisa tus paquetes del AUR
El primer paso es listar los paquetes «foráneos», es decir, aquellos que no provienen de los repositorios oficiales (que, en la práctica, son los del AUR). Abre una terminal y ejecuta:
pacman -Qm
Compara esa lista con los paquetes comprometidos que la comunidad ha ido publicando (entre los confirmados estaban 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.
Si prefieres acotar la búsqueda por fecha en vez de revisar nombre por nombre, el registro de pacman te indica exactamente qué modificaste y en qué momento:
grep -E "installed|upgraded" /var/log/pacman.log | grep "2026-06-1"
2. Busca rastros del ataque
Revisa el historial de compilación buscando líneas como npm install atomic-lockfile, bun install js-digest o rutas del tipo src/hooks/deps. Para detectar procesos ocultos y persistencia, utiliza 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 (buen momento para pasarlas a un gestor de contraseñas).
- 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.
Encuentras los detalles sobre el funcionamiento del 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
Parecía que en junio se trataba de un incidente puntual y resuelto. No fue así: «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.
Como respuesta, en agosto de 2026 Arch Linux ha tomado la medida que faltaba: desactivar la adopción de paquetes en el AUR. Así 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».
Se trata de una medida temporal que se revertirá cuando exista una solución mejor, pero es importante comprender su significado: han cerrado la puerta exacta por la que entraron los atacantes. La adopción de un paquete huérfano era un trámite diseñado para evitar que el software abandonado quedara obsoleto, y acabó convirtiéndose 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
