Welcome back, aspiring cyberwarriors!
Recently, a high-severity vulnerability has been publicly disclosed that affects multiple Linux distributions in their default installations. This vulnerability, known as Pack2TheRoot, can be exploited by any local unprivileged user to gain root access on a vulnerable system.
In this article, we will explore how this vulnerability appears, how it can be exploited, and how you can defend against it. Let’s get rolling!
What is Pack2TheRoot?
Pack2TheRoot is a security flaw that allows unprivileged users to gain full root access on Linux systems via the PackageKit service. PackageKit is a package management tool that helps install and remove software across different Linux distributions using backends like apt or dnf. The problem affects all versions of PackageKit from 1.0.2 to 1.3.4. It has been confirmed to work on default Ubuntu setups from 18.04 to 26.04 beta, as well as Debian Trixie, Rocky Linux 10.1, and Fedora 43. Other distributions that include PackageKit, especially those using Cockpit, might also be at risk. The root cause of the problem is a race condition in PackageKit’s transaction handling, particularly during the InstallFiles method. The service checks whether a user is authorized, but it fails to maintain consistency between the initial check and the actual installation. This allows attackers to switch a harmless dummy package used in the check with a malicious package right after gaining authorization.
For an attacker, exploiting this vulnerability is fairly easy and does not require passwords or special permissions apart from local user access. They start by creating a world-writable directory, such as/tmp or their home directory. Next, they determine the system’s package format to create either a deb or rpm package. They make two packages in that directory: a harmless dummy package for authorization and a malicious package containing scripts that run with root privileges. The attacker then initiates a D-Bus call, creating a new transaction with PackageKit. They make two InstallFiles requests in quick succession: the first one uses the dummy package with a simulate flag to pass the permission check, and the second uses the malicious package without flags. Due to the race condition, PackageKit authorizes the first request but installs the second package with root privileges. The malicious script then establishes a setuid root copy of bash in a location under the attacker’s control.
Once successful, the attacker can gain root privileges by running the newly created setuid bash binary. This entire process typically takes seconds to complete. After the exploit, PackageKit may crash due to an internal error, but systemd automatically restarts the service, causing no permanent downtime. However, this crash can be seen in logs and can alert administrators about a potential compromise.
Exploiting the Vulnerability
Before we start any activities, we need to confirm that our target system is running a vulnerable version of PackageKit. To do this, we can use the following command:
> dpkg -l | grep -i packagekit
In this case, we see that the system is running version 1.2.8, indicating it is vulnerable. Therefore, we can proceed to escalate privileges. There are several public proofs of concept (PoCs) for this vulnerability. For this demonstration, I will use a Python script published by baph00met. Our preparation is straightforward: simply download the script from the repository and run it on the target system.
> python3 cve-2026-41651-purpleteam.py
Be prepared to run the script multiple times before it provides you with a root shell. To monitor PackageKit activity in real time from the terminal, you can simply enter the following command:
> pkmon
This command will display ongoing package transactions, such as installations or removals, along with any errors that may occur.
To address the vulnerabilities, the primary fix is updating PackageKit. The issue is resolved in the PackageKit release 1.3.5, and its backports.
Summary
There are noteworthy problems with how transaction flags are handled. Specifically, there isn’t sufficient validation when these flags are changed, and transactions aren’t managed properly. This eventually leads to harmful scripts being run from RPM files.
If you are interested in this topic and want to learn how to create your own exploits, check out our Exploit Development Part I course or join the live Part 2 from May 5-7. This course is part of the Subscriber Pro training package.
Source: HackersArise
Source Link: https://hackers-arise.com/privilege-escalation-getting-started-with-the-pack2theroot-cve-2026-41651-vulnerability-to-escalate-privileges/