El 12 de junio de 2026, el equipo de Arch Linux publicó un aviso oficial de seguridad: en el Arch User Repository (AUR), se produjo una serie de incidentes relacionados con la aceptación y actualización de paquetes dañinos.
Atacantes desconocidos tuvieron como objetivo los paquetes almacenados en AUR e intentaron introducir código malicioso en los scripts PKGBUILD.
El mensaje era escueto, pero inequívoco:
We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository.
El equipo de Arch participó activamente en la detección de los cambios dañinos y en la prevención de nuevos ataques. Al mismo tiempo, se restringieron temporalmente algunas funciones de AUR, como la creación de nuevas cuentas, el envío de actualizaciones de paquetes y la gestión de dichos paquetes.
Mi primera reacción: Respirar hondo durante un momento y luego revisar todo de manera sistemática.
¿Por qué mi flujo de trabajo es más seguro desde el principio?#
No utilizo ningún ayudante para la generación de archivos AUR (como yay,
paru u similares); todo se hace de forma manual. Esto implica un poco más de
trabajo, pero precisamente en situaciones como esta, el esfuerzo vale la pena.
Mi procedimiento habitual es el siguiente: dispongo de un directorio llamado
~/builds, en el cual descargo paquetes AUR utilizando el archivo git clone.
cd ~/builds
git clone https://aur.archlinux.org/brave-bin.git
cd brave-binAntes de construir o descargar cualquier cosa, leo el contenido del archivo PKGBUILD.
less PKGBUILDAl hacerlo, presto especial atención a las líneas que contienen el código
source=: ¿De dónde proviene este código? ¿Existen llamadas sospechosas a los
códigos curl o bash que podrían cargar código dañino de forma posterior?
Solo cuando todo parece lógico y coherente procedo a la compilación e
instalación del software.
makepkg
sudo pacman -U brave-bin-1:1.79.123-1-x86_64.pkg.tar.zstLas actualizaciones se realizan a través de git pull; posteriormente, es
necesario compilar e instalar el software nuevamente de forma manual. No existe
ningún mecanismo automático, ni se debe confiar ciegamente en estos procesos.
Este procedimiento manual es precisamente lo que el equipo de Arch recomienda en su aviso de seguridad; constituye la primera línea de defensa contra códigos dañinos que se introducen de forma inadvertida.
Además, en general utilizo muy pocos paquetes AUR. Cuanto menor es la superficie de ataque, más sencillo es realizar las comprobaciones en caso de necesidad.
Reconstruir la propia historia en el repositorio AUR#
Aunque uno esté seguro de que no ha instalado ningún paquete sospechoso, es
reconfortante verlo confirmado de forma oficial y escrita en papel. Para ello,
pacman proporciona algunos comandos muy útiles.
¿Qué paquetes externos están instalados en realidad?
pacman -QmEsta orden enumera todos los paquetes que no provienen de los repositorios oficiales, es decir, los paquetes AUR y aquellos instalados manualmente.
¿Cuándo se tocó por última vez cada paquete?
pacman -Qi $(pacman -Qm | awk '{print $1}') | grep -E '^(Name|Install Date)'Esto muestra el último estado conocido del sistema: ya sea la fecha de instalación o la última actualización.
La historia completa extraída del registro de pacman:
pacman -Qi Solo conoce el estado actual. Quien desee ver toda la línea
temporal (es decir, tanto la primera instalación como todas las actualizaciones
posteriores) debe acceder directamente al registro de actividad (log).
grep -E "(installed|upgraded) ($(pacman -Qm | awk '{print $1}' | paste -sd '|' -))" /var/log/pacman.log¿Y qué pasa si uno solo quiere ver el último registro de cada paquete, sin necesidad de conocer todo el historial de cambios que ha ocurrido entre ellos?
grep -E "(installed|upgraded) ($(pacman -Qm | awk '{print $1}' | paste -sd '|' -))" /var/log/pacman.log \
| awk '{cron[$4]=$0} END {for (p in cron) print cron[p]}' | sortMi análisis: Ningún paquete está afectado#
Aquí se muestra la salida del registro de actividad de mi sistema, filtrada (fecha: 13 de junio de 2026):
[2025-06-17T19:39:58-0300] [ALPM] installed xautolock (2.2-8)
[2025-06-20T22:19:16-0300] [ALPM] installed python-pywal16 (1:3.8.9-1)
[2025-06-23T17:15:30-0300] [ALPM] installed catppuccin-gtk-theme-git (r62.c961826d0-1)
[2025-06-25T19:06:48-0300] [ALPM] installed mpdris2 (0.9.1-2)
[2025-12-23T11:20:07-0300] [ALPM] upgraded gcc14 (14.3.1+r25+... -> 14.3.1+r416+...)
[2025-12-23T11:20:07-0300] [ALPM] upgraded gcc14-libs (14.3.1+r25+... -> 14.3.1+r416+...)
[2026-01-16T10:08:36-0300] [ALPM] installed lgx2userspace-git (0.3.0.r22.g0547560-1)
[2026-04-02T16:11:50-0300] [ALPM] installed sunshine (2025.924.154138-3)
[2026-04-04T16:55:42-0300] [ALPM] installed mqttx-git (1.13.0.r0.g9c413d9-1)
[2026-05-12T17:35:35-0300] [ALPM] installed llama.cpp-cuda (b9124-1)
[2026-05-12T18:30:43-0300] [ALPM] installed llama-swap (v211-1)
[2026-05-20T17:25:54-0300] [ALPM] upgraded brave-bin (1:1.89.141-1 -> 1:1.90.124-1)
[2026-05-25T12:29:49-0300] [ALPM] upgraded miniconda3 (25.5.1.1-2 -> 26.3.2.2-1)
[2026-06-02T16:13:09-0300] [ALPM] upgraded darkly (0.5.21.r0.gc26d5e6-1 -> 0.5.37-1)
[2026-06-02T17:21:25-0300] [ALPM] installed papirus-folders-catppuccin-git (r30.f83671d1-2)
[2026-06-02T17:37:36-0300] [ALPM] installed catppuccin-cursors-mocha (2.0.0-1)El resultado del análisis:
No hay paquetes dañados o comprometidos. Al comparar la lista de paquetes con los nombres de los paquetes dañados reportados oficialmente, resulta que ninguno de ellos se encuentra en mi sistema.
Un intervalo de tiempo de actualización claro y sin errores. Todas mis últimas actividades relacionadas con los paquetes tuvieron lugar el 2 de junio de 2026; es decir, antes del conocimiento del incidente (el 12 de junio) y fuera del período crítico. Las versiones y los tiempos de actualización coinciden con los lanzamientos oficiales (upstream) conocidos. No hay actualizaciones “fantasmales” ni ruidos inexplicables en la línea temporal.
Control manual como medida de protección: Dado que leo cada archivo PKGBUILD antes de su compilación, el riesgo de introducir código dañino sin darme cuenta es considerablemente menor en comparación con las herramientas automáticas de gestión de paquetes (como AUR).
El registro (log) confirma que mi sistema no se ha visto afectado por este incidente.
¿Qué debería hacer la gente ahora?#
Si también utilizas Arch Linux con paquetes de AUR, te recomiendo seguir los siguientes pasos:
- Comprueba la lista de paquetes con
pacman -Qmy compárala con la herramienta de la comunidad en GitHub, donde se mantiene actualizada la lista de más de 1.500 paquetes afectados. - Lee el historial de registros (log-history) utilizando los comandos mencionados anteriormente para ver cuáles paquetes se instalaron o se actualizaron, y en qué momento.
- Comprueba manualmente los archivos PKGBUILDs: ahora y en el futuro.
Este es el comando correspondiente. El comando
less PKGBUILDsolo tarda dos minutos y puede ahorrar muchísimos problemas. - Usa el AUR-Helper con precaución. Quien use
yayoparudebe asegurarse de que la opción de visualización de las diferencias esté activada durante las actualizaciones, de modo que los cambios realizados en el archivo PKGBUILD sean visibles antes de que se ejecuten.
Quienes hayan instalado muchos paquetes AUR o prefieran automatizar el proceso de comparación pueden utilizar la herramienta de Python disponible en el repositorio de la comunidad; esta herramienta realizará automáticamente la comprobación contra la lista de los más de 1.600 paquetes afectados.
# Check if you have any infected packages
python -m aur_check
# Full scan with all optional checks (systemd, eBPF, npm + bun cache)
python -m aur_check --full
# Refresh the package list from the official Arch Linux HedgeDoc, then scan
python -m aur_check --refresh --fullLa herramienta requiere Python 3.14+ y no depende de ningún otro componente adicional.
¿Cambiar a Windows? De ninguna manera. Incidentes como este son parte de la vida cuando se utiliza un repositorio comunitario; quien controla adecuadamente su flujo de trabajo puede seguir durmiendo tranquilo después de ello. Arch Linux se queda ❤️
Un cordial saludo,
Sebastian
