This bug was initially created as a copy of Bug #2456366 I am copying this bug because the original bug contains non-disclosable information. Sanitized description from the original report by @maik.schaefer: This report explains a vulnerability within the PackageKit + Polkit component, that allows running code as root and thus leads to a local privilege escalation. The exploitability of the vulnerability has been tested and confirmed on up-to-date Fedora 43 Workstation and Server instances in default installations. I'd be glad if you can help coordinate fixing the issue in the upstream PackageKit project and may other affected distributions. Disclaimer: This is AI-assisted vulnerability research, where Claude by Anthropic has been used for. However, the findings are verified. The following is Claude's summary on the technical details, I also attach a functional exploit to this bug report and a screenshot that proofs the concept. ---------- Exploit Summary: PackageKit Local Privilege Escalation A local unprivileged user can install arbitrary RPM packages as root — including executing RPM scriptlets — without authentication. The vulnerability is a TOCTOU race condition on transaction->cached_transaction_flags combined with a silent state-machine guard that discards illegal backward transitions while leaving corrupted flags in place. Affected Component PackageKit — the D-Bus system service (org.freedesktop.PackageKit) that runs as root on most Linux desktops/servers (Fedora, RHEL, Ubuntu, etc.) to provide a uniform package management interface. Confirmed on PackageKit 1.3.x with DNF backend on Fedora 43. Root Cause — TOCTOU Race on Transaction Flags Three bugs chain together in src/pk-transaction.c (The line numbers refer to commit 04057883189efa225a7c785591aa87cb299782f8 from https://github.com/PackageKit/PackageKit): 1. Unconditional flag overwrite (line 4036): InstallFiles() writes caller-supplied flags to transaction->cached_transaction_flags without checking whether the transaction has already been authorized/started. A second call blindly overwrites the flags even while the transaction is RUNNING. 2. Silent state-transition rejection (lines 873–882): pk_transaction_set_state() silently discards backward state transitions (e.g. RUNNING → WAITING_FOR_AUTH) but the flag overwrite at step 1 already happened. The transaction continues running with corrupted flags. 3. Late flag read at execution time (lines 2273–2277): The scheduler's idle callback reads cached_transaction_flags at dispatch time, not at authorization time. If flags were overwritten between authorization and execution, the backend sees the attacker's flags. Exploitation 1. Attacker registers a rogue polkit authentication agent for their logind session that receives BeginAuthentication challenges but never responds, holding the polkit check open indefinitely. 2. Attacker creates a transaction, then pipelines two async InstallFiles D-Bus calls: - Call 1: flags=ONLY_DOWNLOAD (8) — bypasses polkit (considered safe), transitions to RUNNING, queues idle callback via g_idle_add() - Call 2: flags=0 — overwrites cached_transaction_flags to 0, then attempts polkit auth which is held open by the rogue agent 3. GLib dispatches D-Bus messages (G_PRIORITY_DEFAULT=0) before idle callbacks (G_PRIORITY_DEFAULT_IDLE=200), so both calls are processed before the idle callback fires. 4. The idle callback reads flags=0, ONLY_DOWNLOAD is absent, DNF_TRANSACTION_FLAG_TEST is never set, and dnf_transaction_commit performs a real install. RPM %post scriptlets execute as root. Impact - Arbitrary code execution as root via RPM scriptlet - No password or authentication required - Any local user with a D-Bus session can exploit this - The exploit succeeds within 1–3 attempts; on failure the daemon crashes (assertion in pk_transaction_finished_emit) and is restarted by systemd via D-Bus activation Reproduction Steps 1. Build an unsigned RPM with a %post scriptlet (e.g. writes to /etc/sudoers.d/) 2. As an unprivileged user: a. Register a polkit auth agent that holds BeginAuthentication without responding b. Call CreateTransaction() on the PackageKit D-Bus interface c. Call SetHints(["interactive=true"]) on the transaction d. Send InstallFiles(flags=8, ["/path/to/payload.rpm"]) — async, don't wait e. Send InstallFiles(flags=0, ["/path/to/payload.rpm"]) — async, don't wait f. Wait for the Finished signal — exit_code=1 means real install occurred 3. Verify: sudo -n id returns uid=0 Observable Artifacts (journald) PackageKit: uid 1000 is trying to obtain ...package-install-untrusted auth (only_trusted:0) PackageKit: uid 1000 failed to obtain auth PackageKit: install-files transaction finished with success ← committed before auth denied packagekitd: assertion failed: (!transaction->emitted_finished) ← daemon crashes polkitd: Operator of unix-session FAILED to authenticate ← too late Reproducible: Always Reported upstream as: https://github.com/PackageKit/PackageKit/security/advisories/GHSA-f55j-vvr9-69xv Expected Results: Package installation attempt should be denied.
Proposed as a Blocker for 44-final by Fedora user ngompa using the blocker tracking app because: This is a security issue at critical level due to the trivial nature of compromise.
FEDORA-2026-6c121b3d4c (PackageKit-1.3.4-3.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-6c121b3d4c
FEDORA-2026-7463cd3c32 (PackageKit-1.3.4-3.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-7463cd3c32
FEDORA-2026-41926fe792 (PackageKit-1.3.4-3.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-41926fe792
*** Bug 2456366 has been marked as a duplicate of this bug. ***
*** Bug 2460761 has been marked as a duplicate of this bug. ***
FEDORA-2026-6c121b3d4c has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-6c121b3d4c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-6c121b3d4c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-7463cd3c32 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-7463cd3c32` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-7463cd3c32 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-41926fe792 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-41926fe792` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-41926fe792 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Discussed at 2026-04-23 Fedora 44 Go/No-Go Meeting #2, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-04-23/f44-final-go-no-go-meeting-2.2026-04-23-18.00.html . Accepted as a Final blocker as a violation of Final criterion "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)".
FEDORA-2026-6c121b3d4c (PackageKit-1.3.4-3.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-7463cd3c32 (PackageKit-1.3.4-3.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-41926fe792 (PackageKit-1.3.4-3.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.