Pack2TheRoot (CVE-2026-41651): Local Root on Linux via a PackageKit Race Condition

Executive Summary

A high-severity vulnerability nicknamed Pack2TheRoot (CVE-2026-41651) was publicly disclosed and affects the default installation of many Linux distributions. The flaw lives in PackageKit, the cross-distribution package-management service that fronts back-ends such as apt and dnf. Because PackageKit ships and runs by default on so many systems — particularly anywhere Cockpit is installed — the blast radius is large: any local, unprivileged user can turn shell access into full root in a matter of seconds, with no password and no special permissions required.

The root cause is a classic time-of-check to time-of-use (TOCTOU) race condition in PackageKit’s transaction handling, specifically around the InstallFiles method. The service authorizes a harmless “dummy” package and then installs whatever package is present at use time — allowing an attacker to swap in a malicious package right after authorization. This article walks through what the vulnerability is, how it is exploited end to end, and the concrete steps defenders should take to close it.

What Is Pack2TheRoot?

Pack2TheRoot is a local privilege-escalation flaw that lets an unprivileged user obtain full root access through the PackageKit service. PackageKit is a package-management abstraction layer that installs and removes software across different Linux distributions using back-ends like apt or dnf. Every PackageKit release from 1.0.2 through 1.3.4 is affected.

The issue has been confirmed on default installs of Ubuntu 18.04 through 26.04 beta, as well as Debian Trixie, Rocky Linux 10.1, and Fedora 43. Other distributions that bundle PackageKit — especially those that ship Cockpit — are likely vulnerable too.

At its core, the bug is a race condition in how PackageKit handles a transaction, particularly during the InstallFiles method. The service performs an authorization check on the user, but it fails to keep that check consistent with the package that is ultimately installed. In other words, the package validated during the permission check is not guaranteed to be the package that gets installed — so an attacker can authorize a benign dummy package and then substitute a malicious one immediately after authorization succeeds.

How the Exploit Works

From an attacker’s point of view, exploitation is straightforward and needs nothing beyond local user access. The typical sequence looks like this:

1. Create a world-writable working directory, such as /tmp or the attacker’s home directory.
2. Determine the system’s package format so the right artifact can be built — a .deb on Debian/Ubuntu or an .rpm on RPM-based systems.
3. Build two packages in that directory: a harmless dummy package used to pass the authorization check, and a malicious package whose maintainer scripts run with root privileges.
4. Open a D-Bus call to create a new PackageKit transaction.
5. Fire two InstallFiles requests back to back: the first uses the dummy package with a simulate flag to clear the permission check, and the second uses the malicious package with no flags.
6. Thanks to the race condition, PackageKit authorizes the first request but installs the second package as root. The malicious maintainer script drops a setuid-root copy of bash at a location the attacker controls.

Once the setuid bash binary is in place, the attacker simply runs it to obtain a root shell. The whole process usually completes in seconds. After exploitation, PackageKit may crash with an internal error, but systemd automatically restarts the service so there is no lasting downtime — though that crash does leave a trace in the logs that can tip off administrators to a possible compromise.

Exploiting the Vulnerability

Before doing anything else, confirm that the target is running a vulnerable version of PackageKit. On a Debian/Ubuntu system you can check the installed version with:

dpkg -l | grep -i packagekit

In this example the system is running version 1.2.8, which falls within the vulnerable range, so we can proceed to escalate privileges. Several public proofs of concept exist for this CVE. The walkthrough below uses a Python PoC published by baph00met. Preparation is minimal — download the script from the repository and run it on the target:

python3 cve-2026-41651-purpleteam.py

Because the exploit depends on winning a race, be prepared to run the script several times before it hands you a root shell. To watch PackageKit activity in real time from another terminal, use:

pkmon

The pkmon command displays ongoing package transactions — installations, removals, and any errors that occur along the way — which makes it a useful lens for both attackers timing the race and defenders looking for anomalies.

The primary fix is to update PackageKit. The vulnerability is resolved in PackageKit 1.3.5 and its backports.

Summary of the Root Cause

The underlying problems are in how transaction flags are handled. There is insufficient validation when those flags change, and transactions are not managed consistently between the authorization check and the actual install. The end result is that attacker-controlled maintainer scripts — from a .deb or .rpm file — get executed as root.

Key Takeaways

• Pack2TheRoot (CVE-2026-41651) is a local privilege-escalation bug in PackageKit, affecting versions 1.0.2 to 1.3.4.
• It is a TOCTOU race condition in the InstallFiles transaction path: the package that is authorized is not the package that is installed.
• Exploitation needs only local, unprivileged access — no password, no special capabilities.
• The payload installs a setuid-root bash, giving instant root on demand; the full attack typically takes seconds.
• Default installs of Ubuntu, Debian, Rocky Linux, and Fedora are confirmed affected; systems shipping Cockpit are especially exposed.
• The exploit may crash PackageKit (auto-restarted by systemd), leaving a detectable artifact in the logs.
• The fix is PackageKit 1.3.5 (and backports).

Defensive Recommendations

• Patch immediately. Upgrade PackageKit to 1.3.5 or the patched backport for your distribution; this is the authoritative fix.
• Inventory exposure. Enumerate hosts running PackageKit (e.g. dpkg -l | grep -i packagekit or rpm -q PackageKit) and prioritize multi-user and internet-facing systems.
• Remove what you don’t use. On servers that do not need PackageKit or Cockpit, disable or uninstall the service to shrink the attack surface.
• Monitor PolicyKit/PackageKit authorization. Alert on unexpected InstallFiles transactions, especially those originating from unprivileged users or referencing packages under /tmp or home directories.
• Watch for PackageKit crashes. Repeated service crashes followed by systemd restarts can indicate someone hammering the race — treat clusters of these as a detection signal.
• Hunt for new setuid binaries. Baseline and continuously check for unexpected setuid-root files (for example find / -perm -4000 -type f), since the payload drops a setuid bash.
• Constrain world-writable paths. Mount /tmp with noexec,nosuid,nodev where feasible to blunt payload staging.

Conclusion

Pack2TheRoot is a reminder that privileged system daemons are only as safe as the consistency of their authorization logic. A single race window between checking permissions and acting on them is enough to turn a routine package-management service into a reliable local-to-root primitive across most mainstream Linux distributions. The good news is that remediation is simple: update PackageKit to 1.3.5, remove it where it isn’t needed, and watch for the noisy crash-and-restart and setuid-binary artifacts the exploit leaves behind.

Original text: “Privilege Escalation: Getting Started with the Pack2TheRoot (CVE-2026-41651) Vulnerability to Escalate Privileges” by aircorridor at Hackers Arise.