Bug 2466035 (CVE-2026-68562) - CVE-2026-68562 ansible-collection-redhat-leapp: ansible-collection-redhat-leapp: Information disclosure via Leapp report tampering
Summary: CVE-2026-68562 ansible-collection-redhat-leapp: ansible-collection-redhat-lea...
Keywords:
Status: NEW
Alias: CVE-2026-68562
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-05-04 17:02 UTC by OSIDB Bzimport
Modified: 2026-07-30 20:46 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-05-04 17:02:28 UTC
AI_ONLY_REPORT
package: ansible-collection-redhat-leapp-1.7.4-1.el10_2
------
Summary: Controller-to-Node Information Disclosure via Leapp Report  
Tampering: attacker-controlled Leapp report content on a managed node can  
cause controller-local files to be read during remediation and copied back  
to that managed node.
Requirements to exploit: An attacker needs privileged write access to the  
managed node's Leapp report content, or equivalent control over the  
remediation hint data consumed from that report, and an operator must run  
remediation that includes `leapp_corrupted_grubenv_file`.
Component affected: `ansible-collection-redhat-leapp`, specifically the  
remediation flow in  
`roles/remediate/tasks/leapp_corrupted_grubenv_file.yml` reached from  
`roles/remediate/tasks/main.yml`
Version affected: `ansible-collection-redhat-leapp-1.7.4-1.el10_2` when the  
remediation role is executed against a managed node whose Leapp report  
content can be modified by an attacker
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N - 6.2 (MEDIUM)
AV:N - exploitation uses the normal network path between the Ansible  
controller and managed node.
AC:L - once the report content is attacker-controlled, exploitation only  
requires supplying a chosen path in the remediation context.
PR:H - modifying the expected Leapp report on the managed node appears  
to require high privileges there, or equivalent control over that report  
content.
UI:R - an operator must run the remediation workflow after the malicious  
report content is in place.
S:C - managed-node-controlled input causes the controller to read a  
controller-local file and send it back to the node, crossing a trust  
boundary.
C:H - sensitive controller files such as private keys or credentials may  
be disclosed.
I:N - the established issue is file disclosure rather than unauthorized  
modification.
A:N - the available evidence does not show a direct availability impact.
Impact: Moderate. Based on Red Hat's severity guidance, this issue can  
expose confidential controller-side data, but exploitation depends on a  
compromised or equivalently privileged managed node and operator-triggered  
remediation. Those preconditions make the issue materially harder to  
exploit than an Important issue, even though the resulting disclosure can  
be high value.
Embargo: no
Reason: the issue is Moderate severity, requires prior compromise or  
equivalent privileged access on the managed node, and has straightforward  
mitigations in deployment and code.
Acknowledgement: Aisle Research
Vulnerability Details: The remediation logic extracts file paths from  
report-controlled remediation context and then passes those paths to  
`ansible.builtin.copy` as `src` without `remote_src: true`. In Ansible,  
`copy.src` is controller-side by default. Because the Leapp report is first  
read from the managed node and parsed into remediation data, a malicious  
managed node can influence which controller-local file is read.
```yaml
files_grub: >-
{{ (leapp_inhibitor_remediation_hint.context |  
regex_findall(leapp_inhibitor_hint_pattern, '
1') | first).split(',')
map('trim')
list }}
name: leapp_corrupted_grubenv_file | Backup file(s)
   ansible.builtin.copy:
     src: "{{ item }}"
     dest: "{{ item }}.backup"
     mode: "0644"
   with_items: "{{ files_grub }}"
```


The report data consumed by this task comes from the managed node:
```yaml
name: Read leapp report
   ansible.builtin.slurp:
     src: "{{ leapp_report_location }}"
...

name: Parse leapp report
   ansible.builtin.set_fact:
     leapp_report_data: "{{ leapp_report_content.content | b64decode |  
from_json }}"
```


This remediation is reachable through the inhibitor mappings below:
```yaml
"Detected a corrupted grubenv file": leapp_corrupted_grubenv_file
f32345b6140b5a318c1c01e1cbc6ef1c0321e04a: leapp_corrupted_grubenv_file
```
In practical terms, if the remediation hint context is changed to reference  
a controller-local path such as `/root/.ssh/id_rsa`, the backup task may  
attempt to read that file from the controller and write it to the managed  
node as `{{ item }}.backup`. Based on the available evidence, this is an  
information disclosure issue across the controller-to-node trust boundary.  
The evidence does not establish direct code execution.
Steps to reproduce:
1. On a test managed node, create or modify  
`/var/log/leapp/leapp-report.json` so it contains an entry with key  
`f32345b6140b5a318c1c01e1cbc6ef1c0321e04a` and remediation hint context  
`Delete /root/.ssh/id_rsa file`.
2. Run remediation with `leapp_remediation_todo` including  
`leapp_corrupted_grubenv_file`.
3. Execute the remediation role or playbook from the controller.
4. Observe that `leapp_corrupted_grubenv_file | Backup file(s)` attempts to  
use `/root/.ssh/id_rsa` as `src` on the controller and writes  
`/root/.ssh/id_rsa.backup` on the managed node.
Mitigation: Until fixed, avoid running this remediation against hosts whose  
Leapp report content cannot be trusted. As a local hardening measure, treat  
the backup source as remote by setting `remote_src: true` and constrain  
accepted paths to the expected `/boot` subtree before using them.
Proposed Fix: The remediation should both restrict accepted paths to the  
expected boot-related locations and force the copy source to be resolved on  
the managed node.
```diff
diff --git a/roles/remediate/tasks/leapp_corrupted_grubenv_file.yml  
b/roles/remediate/tasks/leapp_corrupted_grubenv_file.yml
@@
files_grub: >-
{{ (leapp_inhibitor_remediation_hint.context |  
regex_findall(leapp_inhibitor_hint_pattern, '
1') | first).split(',')
map('trim')
+            
select('match', '^/boot(/
$)')
list }}
@@
name: leapp_corrupted_grubenv_file 


Backup file(s)
ansible.builtin.copy:
src: "{{ item }}"
dest: "{{ item }}.backup"
mode: "0644"
+            remote_src: true
with_items: "{{ files_grub }}"
@@
name: leapp_corrupted_grubenv_file 


Backup grub.cfg file
ansible.builtin.copy:
src: "{{ grub_cfg_path.stdout }}"
dest: "{{ grub_cfg_path.stdout }}.backup"
mode: "0644"
+            remote_src: true
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use


Note You need to log in before you can comment on or make changes to this bug.