Researchers from Deutsche Telekom’s Red Team have identified a high-severity security flaw in PackageKit, the software that helps in managing packages across different Linux systems. The flaw, dubbed Pack2TheRoot and tracked as CVE-2026-41651 with CVSS 3.1: 8.8, is a serious issue as it allows an unprivileged user to gain root access on a computer.
Pack2TheRoot was discovered in 2025 after the team noticed the ‘pkcon install’ command on Fedora Workstation functioning without a password. By using Anthropic’s Claude Opus to identify a specific privilege escalation vector, they found that this flaw lies deep within the PackageKit daemon background service, which handles software installations, and could be triggered in seconds.
“The vulnerability enables an unprivileged attacker to install or remove system packages without authorization. This can be exploited to gain full root access or compromise the system in other ways,” the team explained in the blog post.
The technical exploit
According to the Red Team’s research, the problem is a Time-of-Check Time-of-Use (TOCTOU) race condition located in the src/pk-transaction.c file. It happens because of three main errors in the code of the PackageKit daemon. Firstly, the InstallFiles() function lets new instructions overwrite old ones even while a process is already running.
Then, the system fails to block the software from moving backwards into an insecure state once instructions are corrupted. And lastly, the system waits until the very last moment to read security flags instead of checking them at the start.
These errors, the researcher explained, can be exploited by a hacker to install their own RPM packages and run RPM scriptlets, allowing them to obtain Local Privilege Escalation (LPE). This means that an unprivileged local user can become a system administrator without authentication.
Although this attack occurs quickly, it can still leave a trace because the PackageKit tool usually crashes after the exploit is used, and this shows up as an assertion failure in the logs. A proof-of-concept has also been shared by the team.
Vulnerable versions
An interesting fact is that this bug has existed in the code for around 12+ years, and hence, has developed a broad impact. “Since PackageKit 1.0.2 was released over 12 years ago, this leaves a broad attack surface across Linux distributions,” researchers noted.
It, reportedly, affects all PackageKit versions 1.0.2 through 1.3.4, default installations of Ubuntu Desktop 24.04 and 26.04, Debian Trixie 13.4, RockyLinux 10.1, and Fedora 43, and servers using Cockpit or Red Hat Enterprise Linux (RHEL).
Red Hat and PackageKit were informed about Pack2TheRoot on 8 April 2026. Initially, a private fix was created by a developer named Matthias Klumpp on 15 April, which was shared with major vendors like Canonical and Red Hat, whereas the official fix was released in PackageKit version 1.3.5 on 22 April.
You can find out if your computer is at risk by typing dpkg -l | grep -i packagekit or rpm -qa | grep -i packagekit into the terminal to check your version number. However, according to researchers, “it is reasonable to assume that all distributions that ship PackageKit” are vulnerable. So, anyone running these systems should install the 1.3.5 update immediately to stay safe.
Experts Perspectives
Experts with Cobalt and RegScale have shared their perspectives with Hackread.com on the risks associated with this flaw.
Joe Brinkley, Head of Offensive Security Research and Community at Cobalt, noted: “The scary part isn’t the exploit itself; it’s how quietly it blends into the noise of normal admin behavior. No fancy malware, no noisy persistence, just a direct, clean path to root through a service most teams treat as background noise.” He added that for those overlooking these components, “you’re essentially leaving the keys under the mat and hoping nobody checks.”
Dale Hoak, CISO at RegScale, highlighted the impact on system trust, stating: “When a package management component like PackageKit can be exploited to gain root access, it undermines the integrity of the entire system and any compliance assertions built on top of it.” He warned that “systems appear compliant on paper but remain exploitable in practice” when organisations cannot definitively prove where the software is running or how it is exposed.
