Oracle Java SE CVE-2026-91385

Exploitation requires a client-side Java deployment running sandboxed Java Web Start applications or sandboxed Java applets that load and execute untrusted code from the internet and rely on the Java sandbox for security. The victim must actively load and run the attacker-supplied untrusted code (UI:R), so there is no automatic or server-side exploitation. The flaw explicitly does NOT apply to server deployments that run only trusted/administrator-installed code, which is the dominant modern Java usage pattern. Limiting factors: mandatory user interaction, the need for a Java client that still permits applet/Web Start execution (a deprecated and rarely-enabled configuration in current environments), and impact restricted to partial data read/modify with no availability effect.

This is a moderate-severity, low-real-world-priority issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N, base 5.4) describes network-reachable, low-complexity, unauthenticated exploitation but is gated by UI:R - the victim must actively load and run attacker-supplied untrusted code (a sandboxed Java Web Start app or applet). Impact is limited: partial confidentiality and integrity (C:L/I:L), no availability impact, and no scope change. No EPSS score, CISA KEV entry, or public POC was provided in the input, so exploitation signals are: no public exploit identified at time of analysis. The description explicitly scopes the flaw to legacy client-side sandbox deployments and states it does NOT apply to server deployments running only trusted code, which dramatically narrows the realistic attack surface. Net assessment: despite a network vector and no authentication requirement, the combination of mandatory user interaction, partial impact, and the deprecated applet/Web Start-only exploitation mode makes this a low operational priority for most modern environments. Conflicting signal to note: the input Tag 'Authentication Bypass' is inconsistent with the description, which describes a sandbox/untrusted-code weakness, not an authentication bypass - verify tagging with the source.

An attacker hosts a malicious Java Web Start application or applet on a website and lures a victim into loading it in a Java-enabled client. When the victim runs the untrusted code, it exploits the JavaFX flaw to escape sandbox restrictions and gain partial read and write access to data accessible to the Java deployment. No public exploit code was identified at the time of analysis, and the attack cannot succeed without the victim actively running the hostile code.