Hace pocos dias se dio a conocer informacion sobre una nueva vulnerabilidad crítica que afecta a los entornos Linux denominada «Pack2TheRoot». Catalogada bajo CVE-2026-41651, este fallo afecta a PackageKit (una herramienta, que actúa como una capa de abstracción D-Bus para unificar la gestión de paquetes en múltiples distribuciones)

Se menciona que el fallo permite a cualquier usuario local sin privilegios instalar o eliminar paquetes de forma arbitraria. Al explotar esta falla, un atacante puede obtener acceso total como administrador (root) en el sistema comprometido. El impacto es considerable dado que el problema ha estado latente desde la versión 1.0.2, lanzada hace más de doce años (en 2014), y afecta a configuraciones predeterminadas de distribuciones populares como Ubuntu, Debian, Rocky Linux y Fedora.

Pack2TheRoot: Vulnerabilidad en PackageKit otorga acceso de administrador en Linux

El descubrimiento de Pack2TheRoot fue el resultado de una investigación dirigida por el equipo Red Team de Deutsche Telekom, quienes utilizaron el modelo de inteligencia artificial Claude Opus para guiar su análisis sobre vectores de escalada de privilegios locales.

Los investigadores observaron inicialmente que el comando pkcon install podía ejecutarse sin requerir contraseña en ciertas configuraciones de Fedora, lo que levantó sospechas sobre la autorización subyacente. Tras confirmar y reportar responsablemente el fallo a los mantenedores de PackageKit, se ha desarrollado un exploit funcional, aunque su publicación detallada se ha retrasado estratégicamente para permitir que los usuarios y administradores apliquen las actualizaciones necesarias.

La mecánica del ataque

La raíz de la vulnerabilidad reside en una condición de carrera (del tipo TOCTOU: Time-of-Check to Time-of-Use) dentro de la gestión de transacciones del proceso en segundo plano (daemon) de PackageKit. PackageKit, que opera como usuario root, delega la autorización al sistema polkit. Cuando un cliente solicita instalar un paquete, por ejemplo mediante el método InstallFiles, transmite un conjunto de indicadores (flags) que dictan el comportamiento de la transacción.

Indicadores específicos, como SIMULATE o ONLY_DOWNLOAD, instruyen a PackageKit a omitir la autorización de polkit, ya que representan operaciones seguras que, en teoría, no modifican el estado del sistema. El fallo se desencadena porque el manejador de transacciones sobrescribe incondicionalmente estos indicadores almacenados en caché con cada nueva llamada, sin verificar si la transacción ya ha sido autorizada o está en proceso de ejecución.

Un atacante puede iniciar una transacción con indicadores «seguros» (eludiendo así la autorización de polkit) y, milisegundos después, enviar una segunda solicitud D-Bus para la misma transacción, pero esta vez con indicadores maliciosos que ordenen una instalación real. Debido a la arquitectura de prioridades del bucle de eventos de GLib (donde los mensajes D-Bus se procesan antes que las tareas programadas en espera (idle callbacks)), la segunda solicitud sobrescribe los parámetros justo antes de que el planificador (scheduler) inicie la operación.

Como resultado, la transacción previamente autorizada como «segura» se ejecuta con los parámetros sustituidos, instalando el paquete con privilegios de administrador.

Soluciones y mitigacion

Cabe señalar que la vulnerabilidad ha sido parchada en la versión 1.3.5 de PackageKit, por lo que los desarrolladores instan a los administradores de sistemas a verificar si sus equipos son vulnerables revisando el estado del servicio mediante comandos como systemctl status packagekit o monitoreando la actividad con pkmon.

Las principales distribuciones, incluyendo Debian, Ubuntu y Fedora, ya han comenzado a distribuir paquetes actualizados a través de sus canales oficiales. Para aquellos sistemas donde un parche no esté disponible de inmediato, los investigadores han propuesto una solución alternativa (workaround) que consiste en desplegar una regla de polkit personalizada.

Esta regla deniega de forma inmediata y silenciosa las acciones de instalación de PackageKit para cualquier usuario que no sea root, impidiendo que la ventana de la condición de carrera se abra. Es importante destacar que, aunque el exploit es rápido y silencioso, deja un rastro claro en los registros del sistema (logs): tras una explotación exitosa, el daemon de PackageKit colapsa debido a un error de aserción (assertion failed: (!transaction->priv->emitted_finished)). Aunque systemd reinicia el servicio previniendo una denegación de servicio, la presencia de este mensaje en journalctl es un fuerte indicador de que el sistema ha sido comprometido.

Finalmente, si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.