¿Amas Arch Linux, pero las noticias sobre malware en AUR te ponen nervioso? Es normal. En julio de 2025 ocurrieron dos incidentes notables. El 16 de julio se detectó un troyano remoto CHAOS RAT en los paquetes de AUR librewolf-fix-bin, firefox-patch-bin y zen-browser-patched-bin. Y el 31 de julio apareció en AUR un reempaquetado google-chrome-stable cuyo script de compilación contenía una línea de Python que descargaba y ejecutaba un script remoto desde un servidor poco confiable. En ambos casos la comunidad detectó el problema rápidamente y, en aproximadamente 48 horas, se eliminaron los paquetes. Pero esto mostró una vez más: el modelo abierto de AUR exige disciplina a cada quien que lo usa.
¿Significa esto que AUR siempre es un riesgo? No. AUR sigue siendo una herramienta potente si se usa con conciencia: verificar qué se va a instalar, entender cómo se construye el paquete, minimizar la superficie de ataque y tener un plan rápido de respuesta.
Por qué AUR es vulnerable — y para qué sirve
AUR es una gran biblioteca de recetas de usuario (PKGBUILD) para Arch Linux. Cualquiera puede proponer un paquete nuevo y otro usuario puede compilarlo localmente. La fuerza de AUR es la velocidad y la amplitud: versiones recientes, utilidades raras, forks atrevidos. La debilidad es la misma: no hay una premoderación formal del código, las publicaciones aparecen casi al instante, y una receta "huérfana" puede ser adoptada por otro mantenedor que añada acciones no deseadas. Los atacantes o bien publican un "doble" o toman una receta abandonada e insertan código adicional.
Es importante recordar: el malware no se activará por sí solo. Solo funcionará si instalas el paquete o actualizas uno ya instalado. Por tanto, la tarea es reconocer lo sospechoso antes de instalar y no pulsar "Sí" en piloto automático.
Estrategia básica: usar AUR conscientemente
Si eres principiante o no quieres profundizar, la buena noticia es que la gran mayoría de aplicaciones necesarias están en los repositorios oficiales o en Flatpak. Deja AUR para casos raros. Cuando no puedas prescindir de AUR, actúa según el plan que sigue.
1) Copias de seguridad regulares — ante todo
Sin copia de seguridad cualquier experimento es un riesgo. Haz copias incrementales con rsync (o restic, borg) y guárdalas en un soporte separado que no esté siempre conectado al sistema. Puedes usar un SSD externo (por ejemplo, Crucial X10): lo importante es que esté físicamente separado y no siempre enchufado.
2) Mantente informado: notificaciones y comunidades
Configura Google Alerts para palabras clave como Arch y AUR — recibirás resúmenes diarios. Suscríbete a los subreddits r/archlinux y r/linux: allí suelen discutirse vulnerabilidades, paquetes retirados y campañas con malware — a veces antes que los grandes medios.
3) Octopi o terminal — elige dónde te resulta más cómodo verificar
A mí me resulta cómodo mirar primero los paquetes desde Octopi: escribo el nombre y veo todas las coincidencias y de qué repositorio viene cada variante. En la pestaña "Información" están los metadatos, el mantenedor y el enlace al proyecto. Confío más en paquetes cuyo mantenedor tiene un dominio corporativo (por ejemplo, vinculado con la distribución o archlinux.org). Si hay un correo genérico como xyz@gmail.com o no se indica contacto, abro la página del paquete en AUR y reviso más a fondo antes de pulsar "Instalar". Prefieres la terminal — perfecto: la lógica de comprobación es la misma, solo que manual.
Cómo "iluminar" un paquete desde AUR antes de instalar
Antes de instalar, descarga la receta y mira qué hace. El objetivo es abrir el archivo PKGBUILD y asegurarte de que no haya operaciones de red innecesarias, comandos en una sola línea que descarguen y ejecuten código remoto, ni otras "sorpresas".
Paso 0. Descargamos la receta sin instalar
git clone https://aur.archlinux.org/nombre-del-paquete.git
cd nombre-del-paquete
Si usas un helper, toma solo los archivos de la receta: yay -G nombre-del-paquete o el equivalente en paru.
Paso 1. Miramos al mantenedor, los comentarios y el historial
Verifica quién mantiene el paquete, cuánto tiempo lleva en el ecosistema y si una receta huérfana fue "adoptada" recientemente. Me gustan los paquetes cuyos mantenedores llevan tiempo en la comunidad y responden en los comentarios. La ausencia de actividad bajo una receta sospechosa es mala señal. Revisa el registro de cambios para estimar cuándo entró el paquete en AUR y quién lo mantuvo. Personalmente me siento más tranquilo cuando el mantenedor actual lleva al menos un mes, y mejor si son seis meses o más.
Paso 2. Auditoría rápida del PKGBUILD "por lista de verificación"
- Bloque
sourcey sumas: las fuentes deben ser dominios oficiales, existirsha256sumscorrectos y no debe descargarse nada "al vuelo" enprepare()/package(). - No a "curl | bash" ni a comandos en una sola línea que descarguen y ejecuten un script remoto.
- Sin
sudo— la receta no debe requerir privilegios de superusuario para compilarse. - Operaciones de red durante la compilación — prohibidas: todo debe descargarse previamente vía
sourcey comprobarse con hashes.
Paso 3. ¿No eres programador? La IA puede ayudar — pero con matices
Cuando dudo, copio el PKGBUILD completo y lo envío a Google AI Studio con la petición de comprobar los lugares sospechosos. Allí está disponible Gemini 2.5 Pro, que lee código razonablemente bien e indica acciones de riesgo. Pero esto es solo una comprobación adicional: los modelos pueden equivocarse. Si la IA marca algo, es mejor consultar a una persona con experiencia.
Paso 4. Compilamos de forma segura
Lo ideal es hacerlo en un chroot limpio con el conjunto devtools (por ejemplo, extra-x86_64-build): la receta se ejecuta en aislamiento, sin acceso a tu entorno home. Si compilas "en vivo", usa al menos makepkg -Crs para limpiar dependencias y residuos tras la compilación.
Helpers de AUR (yay/paru): comodidad sin piloto automático
Los helpers son útiles, pero inducen a pulsar Enter mecánicamente. No instales "directo desde la búsqueda". Como mínimo: descarga la receta, echa un vistazo al PKGBUILD, evalúa al mantenedor y los comentarios, y solo entonces compila. Desactiva la respuesta automática "sí a todo" y lee qué se va a ejecutar.
Minimizamos la superficie de ataque: limpieza e inventario
Eliminamos dependencias huérfanas
Los paquetes que en su momento fueron necesarios pero que ahora no son requeridos por ninguna aplicación son una superficie de riesgo innecesaria, especialmente si vienen de AUR. Para ver la lista:
pacman -Qdt
Eliminar un paquete concreto y sus restos:
sudo pacman -Rns nombre-del-paquete
Quitar todas las dependencias huérfanas de una vez:
sudo pacman -Rns $(pacman -Qdtq)
Comprobamos "foráneos" y buscamos lo sospechoso
Mostrar los paquetes instalados que no provienen de los repositorios oficiales (AUR/local):
pacman -Qm
Búsqueda por nombres y descripciones:
pacman -Qs palabra-clave
Limpiamos restos de compilación
Tras la instalación elimina las carpetas de fuentes y archivos temporales. Si usas un helper, activa la limpieza del caché. Cuantos menos "escombros de construcción", menos sorpresas en futuras actualizaciones.
Si ocurre lo peor: plan de acción ante una compromisión
Supongamos que lees que un paquete de AUR resultó ser malicioso. Comprueba si está instalado:
pacman -Qs nombre-del-paquete
Lista de todos los paquetes instalados procedentes de AUR:
pacman -Qm
- Desconecta Internet (Wi‑Fi/cable) para cortar descargas y exfiltración.
- Elimina el paquete con configuración y dependencias:
sudo pacman -Rns nombre-del-paquete. - Reinicia y arranca desde una live USB de Linux. Escanea el sistema instalado con un antivirus (por ejemplo, ClamAV) y con utilidades para buscar rootkits (chkrootkit o rkhunter).
- Evalúa el alcance. Si el paquete pudo proporcionar acceso remoto o ejecutó código arbitrario, es prudente considerar la máquina potencialmente comprometida en su totalidad. Lo más seguro es una reinstalación limpia desde una imagen confiable y restaurar los datos desde una copia de seguridad limpia.
- Cambia secretos: contraseñas (primero correo y banca), claves SSH, tokens de servicios. Revoca los antiguos y genera nuevos.
Preguntas frecuentes
¿Es verdad que "AUR es inseguro, punto"? No. Lo peligroso es la instalación a ciegas. Si lees el PKGBUILD, revisas al mantenedor y compilas en aislamiento, el riesgo disminuye mucho.
¿Cómo saber que un PKGBUILD "está mal" si no soy programador? Comprueba las fuentes y sumas, la ausencia de descargas de red en prepare()/package(), la ausencia de "curl | bash" y de sudo. En caso de duda, pregunta a la comunidad y pasa el archivo por Google AI Studio (Gemini 2.5 Pro) como filtro adicional.
¿Un antivirus en Linux ayuda? Es la última línea, no un sustituto de la higiene. Es útil para buscar "restos" tras eliminar un malware, pero la clave es no instalar paquetes dudosos y compilar en un entorno limpio.
¿Qué tan rápido responde la comunidad? En julio de 2025 las publicaciones maliciosas se retiraron en aproximadamente dos días. Pero eso no protege a quienes ya habían instalado el paquete. La prevención depende de ti.
Lista de verificación rápida
- Por defecto instala desde repositorios oficiales o Flatpak. Usa AUR solo de forma consciente.
- Antes de instalar desde AUR: descargar la receta, revisar el PKGBUILD, valorar al mantenedor/comentarios/historial.
- Compila en un chroot limpio (
devtools) o al menos conmakepkg -Crs. - Limpia paquetes huérfanos regularmente:
pacman -Qdt→sudo pacman -Rns. - Mantén copias de seguridad en un soporte separado.
- Sigue Google Alerts y los subreddits r/archlinux, r/linux.
- Si sospechas de una compromisión: desconectar → eliminar paquete → escaneo desde live → si es necesario, reinstalación limpia y cambio de secretos.
Conclusión
La apertura de AUR no es un error, es una característica. Ofrece rapidez y variedad, pero exige atención. Si aprendes a leer un PKGBUILD, compilar en aislamiento, limpiar después y mantener la vigilancia, AUR seguirá cumpliendo su intención: facilitar el acceso al software que necesitas cuando realmente lo necesitas, sin riesgos innecesarios.
