ovirt-engine-sdk-python before 3.4.0.7 and 3.5.0.4 does not verify that the hostname of the remote endpoint matches the Common Name (CN) or subjectAltName as specified by its x.509 certificate in a TLS/SSL session. This could allow man-in-the-middle attackers to spoof remote endpoints via an arbitrary valid certificate.

oVirt users with MANIPULATE_STORAGE_DOMAIN permissions can attach a storage domain to any data-center

ovirt-engine 3.2 running on Linux kernel 3.1 and newer creates certain files world-writeable due to an upstream kernel change which impacted how python's os.chmod() works when passed a mode of '-1'.

Sensitive passwords used in deployment and configuration of oVirt Metrics, all versions. were found to be insufficiently protected. Passwords could be disclosed in log files (if playbooks are run with -v) or in playbooks stored on Metrics or Bastion hosts.

During HE deployment via cockpit-ovirt, cockpit-ovirt generates an ansible variable file `/var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileXXXXXX.var` which contains the admin and the appliance passwords as plain-text. At the of the deployment procedure, these files are deleted.

It was discovered that in the ovirt's REST API before version 4.3.2.1, RemoveDiskCommand is triggered as an internal command, meaning the permission validation that should be performed against the calling user is skipped. A user with low privileges (eg Basic Operations) could exploit this flaw to delete disks attached to guests.

In ovirt-engine 4.1, if a host was provisioned with cloud-init, the root password could be revealed through the REST interface.

ovirt-engine before version 4.1.7.6 with log level set to DEBUG includes passwords in the log file without masking. Only administrators can change the log level and only administrators can access the logs. This presents a risk when debug-level logs are shared with vendors or other parties to troubleshoot issues.

ovirt-engine before version ovirt 4.2.2 is vulnerable to an information exposure through log files. When engine-backup was run with one of the options "--provision*db", the database username and password were logged in cleartext. Sharing the provisioning log might inadvertently leak database passwords.

ovirt-ansible-roles before version 1.0.6 has a vulnerability due to a missing no_log directive, resulting in the 'Add oVirt Provider to ManageIQ/CloudForms' playbook inadvertently disclosing admin passwords in the provisioning log. In an environment where logs are shared with other parties, this could lead to privilege escalation.