CVE-2026-87872: 
Ansible vulnerability analysis and mitigation

CVE-2026-87872 is an improper certificate validation vulnerability (CWE-295) affecting the OCAPI modules (ocapi_command, ocapi_info) within the community.general Ansible collection. The shared OCAPI request helper unconditionally disables TLS certificate validation and provides no parameter to re-enable it, while transmitting HTTP Basic-Auth credentials over HTTPS. This flaw was published on September 9, 2026, and affects the ansible-collection-community-general package. It carries a CVSS v3.1 base score of 6.8 (Medium/High) (Red Hat CVE, Github Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation): the shared OCAPI request helper in community.general hardcodes validate_certs=False on every HTTPS request and exposes no module parameter to override this behavior. Because TLS peer authentication is entirely bypassed, any attacker with an adjacent network position (e.g., on the same management LAN segment or network path between the Ansible controller and the OCAPI-managed storage/enclosure device) can present a self-signed or rogue certificate without triggering any error. The attack requires no privileges and no user interaction, but does require a high-complexity on-path network position (CAPEC-459: Creating a Rogue Certification Authority Certificate; CAPEC-475: Signature Spoofing by Improper Validation). No public proof-of-concept exploit code has been identified at this time (Red Hat CVE, Github Advisory).

A network-adjacent attacker who can intercept traffic between the Ansible controller and an OCAPI-managed storage or enclosure device can perform a man-in-the-middle (MITM) attack: capturing HTTP Basic-Auth credentials in transit (high confidentiality impact), tampering with OCAPI responses to manipulate storage/enclosure device behavior (high integrity impact), and potentially pivoting to further compromise infrastructure managed by those credentials. Availability is not directly impacted by this vulnerability. The affected component is community-maintained and not shipped in Red Hat-supported execution environments for Ansible Automation Platform or RHEL AppStream (Red Hat CVE).

No in-the-wild exploitation has been reported, and no proof-of-concept exploit code is publicly available as of the disclosure date. The EPSS score is 0.0, indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an adjacent network position with the ability to intercept traffic between the Ansible controller and the OCAPI device, which limits the practical attacker pool (Red Hat CVE, Github Advisory).

1. Reconnaissance: Identify environments running Ansible playbooks that use the community.general collection's ocapi_command or ocapi_info modules against OCAPI-managed storage or enclosure devices.
2. Gain adjacent network position: Position on the network path between the Ansible controller and the target OCAPI device (e.g., via ARP spoofing, rogue switch, or compromised network device on the management LAN).
3. Present a rogue TLS certificate: Stand up a TLS interception proxy (e.g., mitmproxy, Burp Suite) with a self-signed certificate. Because validate_certs=False is hardcoded, the Ansible modules will accept any certificate without error.
4. Intercept HTTP Basic-Auth credentials: Capture the HTTPS session; the Basic-Auth header containing the OCAPI device credentials is now visible in plaintext to the attacker.
5. Tamper with responses: Optionally modify OCAPI API responses relayed back to the Ansible controller to manipulate playbook logic or storage/enclosure device configuration (Red Hat CVE).

• Network: Unexpected ARP table changes or duplicate MAC entries on the management network segment connecting the Ansible controller to OCAPI devices; unusual TLS certificate fingerprints observed in network captures for OCAPI HTTPS sessions.
• Logs: Ansible task logs showing successful OCAPI module execution despite unexpected or changed device responses; authentication failures on OCAPI devices following suspected credential capture.
• Credentials: Unauthorized access attempts to OCAPI-managed storage or enclosure devices using valid credentials from unexpected source IPs.

No patched version of community.general with a specific fix has been identified in the advisory at this time (affected versions and patched versions are listed as "Unknown" in the GitHub Advisory). Red Hat's recommended interim mitigation is to run OCAPI modules exclusively over a fully trusted and isolated management network path with no untrusted on-path segments, since certificate validation cannot be enabled via module parameters. Additionally, treat OCAPI Basic-Auth credentials as potentially exposed and rotate them immediately if any MITM exposure is suspected. Monitor the community.general collection upstream and the GitHub Advisory (GHSA-72h7-pjj2-r4pr) for patch availability (Red Hat CVE, Github Advisory).

Red Hat acknowledged the issue and credited Jeong Woochang for reporting it. Red Hat noted that the affected community.general collection is community-maintained content not shipped in Red Hat-supported execution environments for Ansible Automation Platform or RHEL AppStream, limiting the direct impact on Red Hat customers. No significant broader media coverage or notable researcher commentary beyond the initial disclosure has been identified (Red Hat CVE).