CVE-2026-87872 in Ansible
Summary
by MITRE • 09/09/2026
A flaw was found in the OCAPI modules (ocapi_command, ocapi_info) of the community.general Ansible collection. The shared OCAPI request helper disables TLS certificate validation on every request and the modules expose no parameter to re-enable it, while sending HTTP Basic-Auth credentials to an https endpoint. An attacker positioned on the network path between the Ansible controller and the OCAPI-managed storage/enclosure device can present any certificate, intercept the session, capture the credentials, and tamper with responses.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in the Open Compute API modules within the community.general Ansible collection represents a critical failure in transport layer security implementation. Specifically, the flaw resides in the shared request helper functions used by both ocapi_command and ocapi_info modules. These internal components are hardcoded to disable TLS certificate validation for every outgoing HTTP request initiated against an OCAPI-managed storage or enclosure device. This design choice effectively strips away one of the primary mechanisms for verifying server identity, leaving the communication channel vulnerable to interception despite being encrypted via HTTPS. The absence of any configurable parameter within these modules allows users to re-enable strict certificate verification, meaning that even administrators who are aware of best practices cannot mitigate this risk through standard configuration changes without modifying the underlying source code or switching to alternative automation tools.
From a technical perspective, this flaw creates an ideal environment for Man-in-the-Middle attacks. Because TLS validation is disabled, any intermediate device on the network path between the Ansible controller and the target appliance can present a self-signed or otherwise invalid certificate during the handshake process without triggering an error that would abort the connection. An attacker positioned in this network segment can successfully establish encrypted sessions with both ends of the communication while decrypting and re-encrypting traffic as needed. This capability allows for complete visibility into the plaintext data transmitted over the secure channel, including sensitive operational commands and authentication credentials.
The impact of this vulnerability is severe due to the nature of OCAPI operations and the method of authentication employed. The modules utilize HTTP Basic Authentication to transmit user credentials with every request sent to the storage device. Since certificate validation is bypassed, an attacker can intercept these sessions and capture the Base64-encoded username and password strings in plaintext. Possession of these credentials grants the attacker full administrative access to the managed infrastructure components. Furthermore, because the connection integrity cannot be verified by the client side, the attacker can also actively tamper with responses returned from the storage device. This could involve altering configuration data, injecting malicious commands into automation playbooks that are executed based on those results, or disrupting service availability through response manipulation.
This vulnerability aligns closely with CWE-295 Improper Certificate Validation and CWE-319 Cleartext Transmission of Credentials. In terms of the MITRE ATT&CK framework, it facilitates techniques associated with Credential Access via Network Sniffing (T1040) and potentially Interception of Application Layer Protocol Traffic if active manipulation is performed. The lack of client-side verification means that even though encryption provides confidentiality against passive eavesdroppers who cannot decrypt without keys, the absence of authentication prevents protection against active attackers capable of certificate forgery or interception in untrusted network environments such as public Wi-Fi, compromised internal networks, or during transit between data centers with weak perimeter security.
Mitigation strategies for this issue must focus on isolating the Ansible controller from potential interceptors and ensuring that automation workflows do not rely solely on HTTPS without proper validation. Ideally, users should upgrade to a version of the community.general collection where this flaw has been patched by defaulting TLS verification to enabled or introducing a configurable option to enforce it. In environments where upgrading is not immediately feasible, network segmentation becomes critical; Ansible controllers must be placed in trusted zones with strict access control lists that prevent unauthorized devices from sitting between the controller and the OCAPI endpoints. Additionally, organizations should consider implementing mutual TLS authentication if supported by their storage infrastructure, which would require valid client certificates to establish a session, thereby neutralizing the ability of an attacker to impersonate either side without possessing the corresponding private keys. Regular auditing of automation scripts for hardcoded credentials or insecure transport configurations is also recommended as part of a broader DevSecOps pipeline to prevent similar issues in future developments.