HCL MyCloud CVE-2026-56582

Exploitation requires the attacker to hold a man-in-the-middle network position capable of intercepting and injecting into active TLS sessions between a client and HCL MyCloud. The server must be using a CBC-mode cipher suite (e.g., TLS_RSA_WITH_AES_128_CBC_SHA or similar); if the server has already been configured to use only AEAD cipher suites or TLS 1.3, this vulnerability is not exploitable. The CVSS vector assigns AC:H, reflecting that the attack requires precise network-layer access and hundreds to thousands of oracle queries without session disruption. PR:L in the vendor assessment implies at minimum some authenticated context is expected, though the attack fundamentally operates at the TLS transport layer. Exploitation does not require access to server configuration or privileged OS accounts, but it does require sustained, undetected network access to the communications channel.

The vendor-assigned CVSS 3.1 score of 3.1 (Low) reflects realistic attack difficulty: AV:N confirms network exposure, but AC:H captures the significant operational burden - LUCKY13 requires the attacker to occupy a man-in-the-middle network position, issue thousands of precisely timed TLS queries, and perform statistical analysis of timing deltas, all without detection. PR:L in the vendor vector suggests some authenticated context is assumed, though classic LUCKY13 operates at the TLS layer before application-layer authentication. Confidentiality impact is limited (C:L), with no integrity or availability impact. No CISA KEV listing and no identified public exploit code further reduce real-world urgency. EPSS data was not provided; however, the attack's high complexity and the 13-year-old nature of the underlying research suggest exploitation remains specialist-level, not commodity. The primary risk exists in environments where TLS traffic traversal by adversaries is plausible (e.g., shared networks, cloud multi-tenancy scenarios) and where legacy CBC cipher suites remain enabled.

An attacker with a man-in-the-middle position on the network path between a legitimate user and HCL MyCloud - achievable via ARP spoofing on a shared LAN, a rogue access point, or a compromised network node in a cloud environment - intercepts TLS sessions and submits thousands of modified ciphertext blocks to the server, measuring response timing differences to identify valid padding. Over many iterations, the attacker accumulates enough timing data to reconstruct plaintext blocks, potentially recovering session tokens, credentials, or sensitive API responses. No public proof-of-concept targeting HCL MyCloud specifically has been identified, though generic LUCKY13 tooling has existed since 2013.