CVE-2026-41012 in bosh-vsphere-cpi-release
Summary
by MITRE • 08/29/2026
Traffic interception vulnerability in BOSH Director vCenter CPI allows attackers positioned between BOSH Director and vCenter to impersonate vCenter REST API and capture administrator credentials via HTTP Basic auth, leading to complete virtualization infrastructure takeover.
An attacker who can intercept traffic between the BOSH Director and vCenter can establish a malicious server impersonating the vCenter REST API. When the BOSH Director makes CPI calls to perform routine cloud infrastructure operations, the attacker captures the vCenter administrator username and password transmitted via HTTP Basic authentication.
The vulnerability stems from insufficient authentication security in the communication protocol between BOSH Director and vCenter. While HTTPS may be used, the lack of proper certificate validation and pinning allows attackers to successfully impersonate vCenter endpoints. Because vCenter credentials typically grant full administrative control over the entire virtualization estate, successful credential capture yields complete takeover of every VM, datastore, and network the CPI manages.
This exposure exists on every CPI call (including routine deployment operations, not just when tags are configured) and cannot be mitigated by supplying a CA certificate alone. The attack impacts all infrastructure managed by the compromised vCenter instance, potentially affecting hundreds or thousands of VMs across multiple deployments and environments.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/29/2026
The vulnerability identified in BOSH Director's VMware vCenter Cloud Provider Interface represents a critical failure in transport layer security that enables man-in-the-middle attacks against cloud orchestration infrastructure. This flaw allows an attacker positioned between the BOSH Director and the vCenter Server to intercept, modify, or impersonate API traffic without detection. The core of the issue lies in the insufficient validation of server certificates during HTTPS connections. While the communication channel is encrypted using TLS, the client side fails to rigorously verify that the presented certificate was issued by a trusted Certificate Authority or matches expected pinning criteria. This omission permits an attacker with network-level access to present a self-signed or maliciously generated certificate for the vCenter domain. Because BOSH Director does not enforce strict certificate validation policies such as certificate pinning, it accepts this fraudulent identity and proceeds to authenticate against the impersonated endpoint.
The operational impact of this vulnerability is severe due to the authentication mechanism employed by the CPI component. The interface relies on HTTP Basic Authentication for transmitting credentials from the Bosh Director to vCenter. In a standard HTTPS session with proper validation, these credentials would be protected within an encrypted tunnel that only the legitimate server can decrypt. However, under attack conditions where certificate validation is bypassed, the attacker establishes their own malicious server acting as a proxy or direct endpoint. When routine operations are triggered by Bosh Director, such as deploying new virtual machines, resizing instances, or managing networks, the CPI component sends its administrative credentials to this impersonated service. The attacker captures these plaintext username and password pairs directly from the network traffic before they reach any legitimate backend logic that might otherwise sanitize or hash them.
The consequences of credential capture extend far beyond simple account compromise. vCenter administrator accounts typically possess unrestricted access across the entire virtualization estate managed by the CPI plugin. This includes full control over all virtual machines, datastores, networks, and host configurations associated with that specific vCenter instance. An attacker possessing these credentials can execute arbitrary commands, deploy malicious workloads for cryptomining or command-and-control infrastructure, exfiltrate sensitive data stored on attached volumes, or disrupt critical business operations by shutting down essential services. The scope of impact is not limited to a single deployment but encompasses every resource managed through the compromised CPI connection, potentially affecting hundreds or thousands of systems across multiple environments simultaneously.
This exposure persists during all types of CPI calls and cannot be mitigated simply by configuring a custom Certificate Authority certificate within Bosh Director settings. Standard CA configuration assumes that any certificate signed by that CA is trustworthy, which does not address the risk if an attacker obtains a valid-looking certificate from a compromised or rogue internal CA authority. The fundamental requirement for mitigation involves implementing strict TLS validation mechanisms including certificate pinning and ensuring that only explicitly trusted certificates are accepted for communication with vCenter endpoints. Organizations must also enforce network segmentation to restrict direct access between Bosh Director hosts and vCenter management interfaces, thereby reducing the attack surface available for interception attempts.
From a classification perspective, this vulnerability aligns with CWE-295 Improper Certificate Validation as it describes the failure to properly validate X.509 certificates during TLS handshakes. It also maps directly to MITRE ATT&CK technique T1078 Valid Accounts because the attacker leverages captured legitimate credentials to gain unauthorized access and maintain persistence within the environment. Furthermore, the interception aspect relates to T1043 Shared Vehicle as it exploits a trusted communication channel between infrastructure components. Remediation strategies should prioritize upgrading Bosh Director versions that include fixes for this CPI security flaw, implementing mutual TLS authentication where possible, and deploying network-level controls such as firewalls or intrusion detection systems to monitor and restrict unauthorized API traffic flows between orchestration tools and virtualization managers.