Leapp Ansible Collection EUVD-2026-51314

Exploitation requires that the attacker holds privileged write access to the managed node's Leapp report content - this is a high-privilege prerequisite, not unauthenticated access. The Leapp upgrade workflow must be active on that managed node (the target system must be in the process of an in-place RHEL major-version upgrade). An operator must actively execute a specific Leapp remediation Ansible task (UI:R) against the compromised managed node for the malicious report to be processed by the controller. Limiting factors: the attacker must already have significant privileged access to the managed node before the attack is possible; the attack window is narrow, existing only during active Leapp upgrade operations; and a human operator must trigger the task. The vulnerability does not apply to systems not running Leapp upgrade workflows, and cannot be triggered autonomously - both operator interaction and pre-existing managed node compromise are mandatory prerequisites.

The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N) captures an important nuance: despite a scope change (S:C) to the Ansible controller and high confidentiality impact (C:H) - meaning private keys and credentials can be exfiltrated - the attack requires PR:H (the attacker must already hold privileged write access to the managed node) and UI:R (an operator must actively run a specific remediation task). This substantially limits the realistic threat population. The vulnerability is not listed in the CISA KEV catalog, and no public exploit code has been identified, further reducing urgency. No EPSS data was provided in the input. The most realistic threat actor is an insider or a post-compromise scenario where an adversary has already achieved privileged code execution on a managed node and seeks to pivot to the Ansible controller's secrets for lateral movement. For organizations running Leapp-based RHEL upgrade campaigns, this is a meaningful risk during the upgrade window; outside of that context, the attack surface is dormant. CVSS AV:N may be slightly misleading here - the attacker's write access is to the managed node (a separate system), and the network path is between controller and managed node, not an external internet-facing attack.

An attacker who has compromised a RHEL 9 managed node with privileged (root or sudo) access modifies the Leapp report file on that node to include a crafted path reference pointing to a sensitive file on the Ansible controller (such as an SSH private key or Ansible Vault credentials file). When an operator subsequently runs the Leapp remediation Ansible task against that node - a routine step during an RHEL upgrade campaign - the Ansible controller follows the manipulated reference, reads the targeted local file, and copies its contents to the managed node, where the attacker retrieves them. No public proof-of-concept code has been identified, but the attack chain requires no special tooling beyond write access to the report file.