Oracle Java SE CVE-2026-91380

Exploitation requires the attacker to first have local logon access to the infrastructure where the affected JDK/GraalVM runs (AV:L), and the vulnerability is explicitly 'difficult to exploit' (AC:H), implying narrow timing, configuration, or data-state preconditions that Oracle does not fully enumerate. The vulnerable surface is reached by supplying data to APIs in the Utility component, e.g. through a web service that forwards attacker-controlled input to those APIs. A second applicable deployment is sandboxed Java Web Start applications or Java applets that load and run untrusted code and rely on the Java sandbox - a largely deprecated and uncommon configuration today. Limiting factors: no availability impact, only partial (subset) confidentiality and integrity impact, local vector rather than network, and high attack complexity; there is no user-interaction requirement (UI:N) and no privilege requirement (PR:N) once local access is obtained.

This is a low-to-moderate priority issue despite the CRITICAL importance of the affected platform. The CVSS 3.1 base score is only 4.0, and the vector (AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) is the limiting factor: exploitation requires local logon access to the infrastructure (AV:L), is explicitly rated high attack complexity / 'difficult to exploit' (AC:H), and yields only partial confidentiality and integrity impact with no availability impact (C:L/I:L/A:N). While PR:N indicates no authentication is needed once the attacker can reach the component, the local attack vector and high complexity substantially constrain real-world risk. No EPSS score, CISA KEV listing, POC, or SSVC decision data was provided in the input; absence of KEV/POC is consistent with a freshly disclosed Oracle Critical Patch Update item rather than evidence of active exploitation. There are no conflicting severity signals - the CVSS vector and the prose description agree that this is local-access, difficult-to-exploit, and limited-impact. Oracle additionally notes the classic sandbox-escape relevance (Java Web Start / applets loading untrusted code), but that deployment model is largely deprecated and rare in modern environments. Net: a real but low-urgency patch item, not an emergency, despite Java's enormous footprint.

An attacker who already has logon access to a host running the affected JDK/GraalVM supplies crafted data to an API exposed by the vulnerable Utility component - for example via a web service that feeds input into the API - and, under difficult-to-meet conditions, gains unauthorized read of a subset of data and the ability to update, insert, or delete some accessible data. In the sandbox variant, a malicious Java Web Start app or applet loading untrusted code could abuse the flaw to partially escape sandbox data restrictions. No public exploit identified at time of analysis, so any real attack would currently require original exploit development against a high-complexity condition.