Pack2TheRoot Flaw Gives Local Linux Users a Path to Root Access

A newly disclosed Linux vulnerability called Pack2TheRoot can let a local unprivileged user gain root access through PackageKit, the system service used by many Linux distributions to manage software installation, updates, and removal. The flaw is tracked as CVE-2026-41651 and carries a high CVSS score of 8.8.

The bug affects PackageKit versions 1.0.2 through 1.3.4 and has existed for more than 12 years. PackageKit 1.3.5 fixes the issue, and Linux users should install distribution updates as soon as they become available.

Deutsche Telekom’s Red Team discovered the vulnerability during research into Linux local privilege escalation paths. The team said it first noticed unusual behavior when pkcon install could install a system package without requiring a password on a Fedora Workstation system.

What Pack2TheRoot does

Pack2TheRoot is a local privilege escalation flaw. That means an attacker already needs local access to the machine, but once they have it, they may be able to abuse PackageKit to install or remove packages with root privileges.

NVD describes the flaw as a time-of-check time-of-use race condition on transaction flags. In simpler terms, PackageKit can check whether an operation is allowed, but the conditions can change before the action completes. That gap can let an unprivileged user perform package operations as root.

This matters because package installation is a trusted system-level action. If an attacker can control what gets installed or removed, they may be able to add malicious software, replace components, break security controls, or create a direct route to root access.

At a glance

Item	Details
Vulnerability	CVE-2026-41651
Nickname	Pack2TheRoot
Affected component	PackageKit daemon
Affected versions	PackageKit 1.0.2 through 1.3.4
Fixed version	PackageKit 1.3.5
Severity	High
CVSS score	8.8
Vulnerability type	Local privilege escalation
Root cause	TOCTOU race condition on transaction flags
Main risk	Unprivileged local users can install or remove packages as root
Public exploit details	Withheld to give patches time to spread

Which Linux systems are affected

Deutsche Telekom’s Red Team said it is safe to assume that Linux distributions with PackageKit installed and enabled by default may be vulnerable if they use an affected version. The team confirmed exploitability on several distributions using apt and dnf package manager backends.

Tested systems included Ubuntu Desktop 18.04, 24.04.4, and 26.04 beta, Ubuntu Server 22.04 through 24.04, Debian Desktop Trixie 13.4, Rocky Linux Desktop 10.1, Fedora 43 Desktop, and Fedora 43 Server. The list is not exhaustive.

Ubuntu’s CVE page also rates the issue as high severity, with local attack vector, low attack complexity, low privileges required, and no user interaction required.

Why PackageKit creates a broad attack surface

PackageKit provides a D-Bus abstraction layer for package management across Linux distributions. It helps desktop tools, update managers, and management software interact with package systems in a consistent way.

That makes the flaw important beyond one distribution. PackageKit is common on desktop Linux systems and can also appear on servers where management tools depend on it.

The issue does not give a remote attacker instant access from the internet. However, it becomes serious once an attacker has a local foothold through a stolen account, malware, exposed service, container escape path, or compromised low-privilege user.

What has been fixed

PackageKit maintainers released version 1.3.5 to address CVE-2026-41651. The maintainer urged users and distributions to update quickly, noting that the vulnerability can allow arbitrary package installation or removal and can lead to a local root exploit on most systems.

Technical details and a full demo exploit were not released with the initial disclosure. Deutsche Telekom’s Red Team said this gives distributions and users time to apply patches before attackers can widely copy the technique.

Red Hat also confirmed the issue as a PackageKit flaw involving a TOCTOU race condition that lets unprivileged users install packages.

How to check if your system may be vulnerable

Linux users can check whether PackageKit is installed and which version is present. Debian and Ubuntu users can run:

dpkg -l | grep -i packagekit

Fedora, Rocky Linux, and other RPM-based users can run:

rpm -qa | grep -i packagekit

Users can also check whether the daemon is running with:

systemctl status packagekit

Another option is:

pkmon

If PackageKit is installed, enabled, and older than 1.3.5, the system should be treated as potentially vulnerable until distribution patches are applied.

What administrators should do now

• Install PackageKit security updates from your Linux distribution.
• Upgrade to PackageKit 1.3.5 or the patched package provided by your vendor.
• Check desktop and server systems, especially shared Linux machines.
• Review whether PackageKit needs to run on servers.
• Disable or remove PackageKit where it is not required.
• Watch system logs for PackageKit crashes or assertion failures.
• Prioritize multi-user systems, developer workstations, lab machines, and systems with untrusted local users.
• Review recent package installation and removal history for suspicious activity.

Why local privilege escalation still matters

Local privilege escalation flaws often get less attention than remote code execution bugs because they require local access first. That can create a false sense of safety.

In real attacks, local access is often the middle stage. Attackers may first enter through phishing, stolen SSH credentials, a vulnerable web app, or malware. Once inside, a flaw like Pack2TheRoot can help them turn a low-privilege account into full root control.

Root access changes the impact. An attacker can tamper with logs, install persistence, access other users’ files, dump secrets, disable security tools, or use the machine to move deeper into the network.

Signs defenders should review

Deutsche Telekom’s Red Team said exploitation can cause the PackageKit daemon to hit an assertion failure and crash. Even if systemd restarts the service, the crash can leave traces in system logs.

Administrators should review logs for unusual PackageKit failures, unexpected package changes, or suspicious pkcon activity. Package installation history may also help identify systems that require deeper investigation.

A patch closes the vulnerability going forward, but it does not automatically prove the system was never abused. Shared Linux environments and systems with multiple local users deserve extra review.

FAQ