IBM i CVE-2026-4942

Exploitation requires the attacker to achieve a man-in-the-middle position on the network path between a client and a TLS-enabled IBM i service - reflected in the CVSS AC:H metric. The attacker must be able to intercept and modify the TLS handshake before session establishment. No attacker authentication is required (PR:N), and no victim user interaction is needed (UI:N). Exploitation is limited by the MitM positioning requirement: opportunistic remote internet exploitation is impractical. IBM i must be running at least one TLS-enabled service (e.g., HTTP server, DDM/DRDA, FTP-over-TLS, or similar) for the attack surface to exist. Environments with network segmentation, encrypted internal links, or IBM i services restricted to trusted subnets significantly reduce realistic risk.

The NVD-assigned CVSS 3.1 base score of 5.9 (Medium) reflects a genuine tension between high potential confidentiality impact (C:H) and the elevated exploitation barrier (AC:H). AC:H is the critical limiting factor here: it implies the attacker cannot exploit this opportunistically from the internet but must occupy a network position capable of intercepting and manipulating TLS handshake traffic - a man-in-the-middle scenario. This substantially reduces the real-world exploitability compared to simpler network vulnerabilities. No EPSS score was provided, and the vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation. No public proof-of-concept has been identified. The practical risk is highest in environments with untrusted internal network segments or where IBM i services are exposed through shared infrastructure. CVSS here accurately reflects medium priority - meaningful risk if MitM conditions can be met, but not a top-tier emergency without additional threat intelligence.

An attacker positioned between a legitimate client and an IBM i server - for example, on a shared network segment or via ARP poisoning - intercepts the TLS handshake and injects a crafted message that causes both sides to negotiate a TLS version the server operator has disabled (e.g., TLS 1.0). With the weaker protocol in use, the attacker can then decrypt session traffic to access sensitive data such as credentials or application payloads transmitted over the connection. No public proof-of-concept is known, but the attack class (TLS downgrade via crafted handshake messages) is well-documented in security research.