CVE-2026-41651

What it actually does

PackageKit 1.0.2 through 1.3.4 contains a local time-of-check/time-of-use race in transaction flag handling. An unprivileged local user can start an authorized PackageKit transaction, then issue a second InstallFiles() call that overwrites transaction->cached_transaction_flags while the transaction is already running. Because invalid backward state transitions are silently rejected but the overwritten flags remain in place, the backend later reads attacker-controlled flags at execution time. On RPM-based systems, this can allow installation of arbitrary local RPM files as root, including execution of RPM scriptlets with root privileges, resulting in local privilege escalation and potential full host compromise.

Why it matters to the business

An attacker who already has a low-privileged local account or code execution on an affected Linux system can potentially become root without user interaction. This can turn a limited foothold into full control of servers or workstations, allowing data theft, service disruption, persistence, tampering with security tooling, and lateral movement. The issue is not currently listed in CISA KEV, is not known to be ransomware-used, and has a low EPSS score, but it has been public for 112 days and affects a core package-management component that may be widely installed on desktop and server distributions.

How an attack unfolds

Exploitation begins with local access as an unprivileged user. The attacker creates or obtains a malicious RPM package containing payloads in RPM scriptlets such as %pre, %post, %preun, or %postun. They interact with PackageKit over D-Bus and initiate an InstallFiles() transaction using flags that pass the initial authorization and state checks. While the transaction is in progress but before the backend dispatches execution, they race a second InstallFiles() call against the same transaction and overwrite cached_transaction_flags. PackageKit rejects the illegal state rollback but keeps the corrupted flags. When the idle scheduler later dispatches the transaction, it reads the overwritten flags and passes them to the RPM backend. The backend installs the attacker-supplied RPM as root and executes its scriptlets as root, allowing the attacker to create a privileged account, install a setuid binary, modify sudoers, deploy persistence, or run arbitrary root commands.

How to fix it

Upgrade PackageKit to version 1.3.5 or a vendor-supplied package that explicitly backports the fix for this issue. Because distribution package versions may retain older upstream version numbers while carrying patches, verify the vendor changelog or security advisory rather than relying only on the displayed version. Where PackageKit is not required, especially on servers, remove or disable the PackageKit daemon. As interim mitigation, restrict local unprivileged access to PackageKit D-Bus methods through policy controls, harden polkit rules so package installation always requires appropriate administrative authentication, and monitor or block installation of local RPMs from user-writable directories such as /tmp, /var/tmp, /dev/shm, and home directories. These mitigations reduce exposure but should not replace applying the fixed package.

How to confirm the fix worked

Confirm installed PackageKit packages are fixed by checking the package manager inventory, for example with rpm -q PackageKit packagekit or the distribution equivalent, and verify the installed build includes the 1.3.5 fix or a vendor backport. Confirm the running packagekitd binary was restarted after update by checking service start time against package installation time. Validate that unprivileged users cannot install arbitrary local RPM files through PackageKit without proper authorization. Review polkit policy for PackageKit actions to ensure package installation is not broadly permitted. On systems where PackageKit is unnecessary, confirm the packagekit service/socket is disabled or removed. For fleet validation, scan for PackageKit versions in the affected 1.0.2 through 1.3.4 range unless the distribution advisory confirms a backport.

Typical attack path

1. Gain local access to an affected Linux host as an unprivileged user through a shell, compromised application account, or malware foothold.
2. Build or download a malicious RPM package containing root-executed scriptlets or files intended for privileged placement.
3. Use the PackageKit D-Bus API to create and start an InstallFiles() transaction that reaches an authorized/running state.
4. Race a second InstallFiles() request against the same transaction to overwrite cached transaction flags after authorization.
5. Allow PackageKit’s scheduler to dispatch the transaction using the corrupted flags.
6. Have the RPM backend install the attacker-controlled package and execute RPM scriptlets as root.
7. Use root privileges to establish persistence, disable controls, access sensitive data, or move laterally.

How to detect it

To determine whether exploitation already occurred, focus on evidence of local RPM installation through PackageKit by non-administrative users. Review systemd journal logs for packagekitd activity, D-Bus activation of org.freedesktop.PackageKit, and polkit decisions around package installation. Correlate PackageKit transactions with RPM database changes, /var/log/dnf.log, /var/log/yum.log, /var/log/messages, /var/log/secure, and auditd execve records. Suspicious patterns include packagekitd installing RPMs from user-writable locations, packagekitd spawning rpm followed by /bin/sh or another interpreter, RPM scriptlets launching network tools or writing privileged files, and package installs with no corresponding sudo, dnf, yum, rpm, or administrator session. If D-Bus auditing or EDR telemetry is available, search for repeated InstallFiles() calls against PackageKit in short time windows by the same unprivileged user, which may indicate racing behavior. For forensic review, inspect recently installed RPMs with rpm -qa --last, validate unknown package contents with rpm -ql and rpm -q --scripts, and examine newly created setuid files, sudoers entries, systemd units, cron jobs, SSH authorized_keys files, and modified PAM or shell profile files around the suspected installation time.

• org.freedesktop.PackageKit
• org.freedesktop.PackageKit.Modify
• InstallFiles
• packagekitd
• /usr/libexec/packagekitd
• /usr/lib/packagekit/packagekitd
• /var/lib/PackageKit/transactions.db
• /var/cache/PackageKit/
• /var/log/dnf.log
• /var/log/yum.log
• /tmp/*.rpm
• /var/tmp/*.rpm
• /dev/shm/*.rpm
• /home/*/*.rpm
• packagekitd.*rpm
• packagekitd.*InstallFiles
• packagekitd.*\/tmp\/.*\.rpm
• packagekitd.*\/var\/tmp\/.*\.rpm
• packagekitd.*\/dev\/shm\/.*\.rpm
• comm="packagekitd"
• exe="/usr/bin/rpm"
• /bin/sh.*RPM
• %pre
• %post
• %preun
• %postun

What your security team should do

• Prioritize patching multi-user Linux systems, developer workstations, VDI hosts, jump boxes, and servers where an application compromise could yield a local shell.
• Upgrade PackageKit to 1.3.5 or the fixed vendor build, then restart packagekitd or reboot to ensure the patched daemon is active.
• Temporarily disable or remove PackageKit on systems where interactive package management is not needed.
• Harden polkit and D-Bus policy so unprivileged users cannot install local packages without administrative approval.
• Hunt for suspicious RPM installs initiated by packagekitd, especially from /tmp, /var/tmp, /dev/shm, or user home directories.
• Investigate any package installations that lack a corresponding administrator action through dnf, yum, rpm, sudo, or a change-management workflow.
• Add audit or EDR detections for packagekitd spawning rpm, shell interpreters, or unusual child processes during package installation.
• Treat confirmed exploitation as root compromise: preserve evidence, rotate local secrets, check persistence mechanisms, and rebuild or reimage where integrity cannot be assured.