Bug 2553683 (CVE-2026-111253)

Summary: CVE-2026-111253 dnf5daemon-server: dnf5: dnf5daemon-server: missing session-owner check allows foreign D-Bus callers to replace another client's resolved transaction
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in dnf5daemon-server. Session methods on dynamically exported D-Bus session objects do not verify that the caller is the unique sender that created the session. A local attacker can modify another user's live package-management session and replace its resolved transaction plan. If the legitimate session party later authorizes execution, the root daemon may apply the attacker-chosen package operations.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-15 18:49:23 UTC
A flaw was found in dnf5daemon-server. The service stores the unique system D-Bus sender that creates each package-management session and enforces that association for SessionManager.close_session(), but the generic dispatcher for methods on dynamically exported session objects does not compare the incoming caller with the stored session owner. A local user who can reach org.rpm.dnf.v0 can therefore invoke session methods such as Rpm.remove() and Goal.resolve() on another client's live session and replace a previously resolved transaction plan. Goal.do_transaction() later authorizes the caller of do_transaction() via PolicyKit against the stored transaction rather than binding authorization to the sender that supplied the package instructions. Cross-UID plan replacement was demonstrated; execution of a substituted plan still requires a later authorized do_transaction() call on that session.