HCL iControl EUVD-2026-52261

Exploitation requires the attacker to achieve a man-in-the-middle position on the network path between the client and HCL iControl v3.2.0 - this is the primary limiting factor reflected in the AC:H CVSS metric. HCL iControl must be actively accepting TLS 1.0 or TLS 1.1 connections, which is the default behavior of the affected version per the vendor report. No authentication is required (PR:N), and no user interaction is needed (UI:N). Exploitation is constrained by network topology: on properly segmented internal networks with no MITM footing, exploitation is significantly harder than on Internet-facing or flat network deployments. There is no indication of a specific feature flag or non-default configuration required - the vulnerability exists in the default TLS negotiation behavior of the product.

The CVSS 4.8 Medium rating is broadly consistent with the actual risk profile. The AC:H metric is the critical signal here: successful exploitation requires the attacker to first achieve a man-in-the-middle position on the network path between the client and HCL iControl, which is a non-trivial prerequisite on segmented or enterprise networks. EPSS data is not provided in the source intelligence, but the absence of a KEV entry and any public POC further supports a low probability of opportunistic mass exploitation. The C:L/I:L impact ratings reflect realistic bounded damage - partial disclosure of session data and limited integrity risk rather than full compromise. For organizations running HCL iControl on Internet-facing or multi-tenant segments, the practical risk is elevated compared to internal-only deployments. The reported tags of 'Information Disclosure' align with the C:L impact. There are no conflicting signals in the available data, though the CPE wildcard introduces minor uncertainty about whether versions prior to 3.2.0 are also affected.

An attacker positioned on the network path between a user's browser or API client and the HCL iControl server - for example, on a shared Wi-Fi segment, a compromised network appliance, or via ARP spoofing - intercepts the TLS handshake and negotiates a TLS 1.0 session. The attacker then leverages known protocol weaknesses such as BEAST to recover session tokens or sensitive data exchanged during the session. No public POC is known at time of analysis, but the technique is well-documented in the security community.