GPU VulnDB

Database/Control plane, storage & DevOps

Ansible community.general OCAPI modules: TLS verification disabled, enclosure credentials exposed

CVSS 6.8CVE-2026-87872Control plane, storage & DevOpscurated

Impact

The shared OCAPI request helper turns off TLS certificate validation on every request and offers no parameter to turn it back on, while sending HTTP Basic-Auth credentials to the storage enclosure over https. Anyone who can sit on the path between the Ansible controller and the managed enclosure can present any certificate, capture the out-of-band management credentials in the clear, and alter the responses the playbook acts on. In a datacenter this path is normally the management VLAN, which is exactly where BMC and enclosure credentials tend to be shared across a whole rack. Captured enclosure credentials give an attacker firmware-level control of storage hardware serving the GPU fleet, and tampered responses can make automation take the wrong action on a healthy or a failing enclosure.

Who can reach it

An attacker in a machine-in-the-middle position on the network path between the Ansible controller and the OCAPI-managed storage or enclosure device - in practice the management VLAN. No credentials needed; the flaw is that the client accepts any certificate.

What to do

The record names no fixed collection version - track the Red Hat entry and the community.general advisory for one. Until then, stop running these modules across any segment you do not fully control, keep controller-to-enclosure traffic on a dedicated management path, and rotate the OCAPI credentials that have already been sent through these modules, since they may have been exposed on every prior run.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.