IBM PowerVM EUVD-2026-86007

Requires the attacker to already hold ROOT within a guest partition (PR:H) on an IBM Power system running an affected PowerVM firmware level (FW1120.00-1120.01, FW1110.00-1110.31, or FW1060.00-1060.81); exploitation is via a local hypervisor call interface (AV:L), so there is no remote or unauthenticated path. Impact is limited to reading a small amount of uninitialized hypervisor memory with no attacker control over the returned contents, and the practical risk concentrates in multi-tenant deployments where untrusted parties run arbitrary guest OS images on shared hardware; single-tenant systems face little exposure.

This is a genuinely low-priority issue despite living in critical hypervisor firmware. The CVSS 3.1 base score is 3.2 (LOW) with vector AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N - exploitation requires ROOT (PR:H) inside a guest partition and yields only a limited, uncontrolled read of hypervisor memory (C:L, no integrity or availability impact). The CWE-457 (use of uninitialized variable) root cause is consistent with the description: the hypercall returns whatever residual bytes happen to be present, and the attacker cannot steer which memory is disclosed, which sharply reduces exploit value. No EPSS score, no CISA KEV listing, and no public exploit code are provided in the input, so there are no signals of active or imminent exploitation. The one real amplifier is the scope change (S:C) and the multi-tenant angle: a guest-root attacker can potentially glimpse data belonging to the hypervisor or co-resident guest partitions, so in cloud/shared-hosting environments running arbitrary tenant OS images this warrants patching, but it is not a remote or unauthenticated exposure. No signals conflict; all data points consistently indicate low real-world urgency.

In a multi-tenant IBM Power environment, an attacker who has already obtained root on one guest partition (e.g. a malicious tenant on their own leased LPAR) issues a crafted call to the affected hypervisor call interface. The hypercall returns a small quantity of uninitialized hypervisor memory that may contain fragments of hypervisor state or another guest's data, which the attacker harvests opportunistically over many calls. No public exploit code is identified; the read is limited and the attacker cannot control which contents are returned.