Oracle Java SE CVE-2026-114820

The target must run an affected Oracle Java SE, GraalVM for JDK, or GraalVM Enterprise Edition build (e.g. Java SE 8u511-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2, 27.0.1.0.2; GraalVM for JDK 17.0.21.0.2 / 21.0.13.0.2; GraalVM EE 21.3.20.0.2) and must expose the JSSE component to attacker-influenced input - Oracle specifies exploitation 'by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs.' A second, distinct exploitation mode is Java deployments running sandboxed Java Web Start applications or sandboxed applets that load and run untrusted code and rely on the Java sandbox. Per the CVSS vector there are no limiting prerequisites for the server-side API path: AV:N/AC:L/PR:N/UI:N means remote, unauthenticated, no user interaction, against configurations that process untrusted secure-protocol data through JSSE. The practical limiting factor is reachability - the vulnerable JSSE code path must actually be invoked on attacker-supplied data; A:N means no denial-of-service impact.

All quantitative signals point the same direction and mark this as a genuine priority. The Oracle CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, base 9.1) describes a network-reachable, low-complexity flaw needing no privileges and no user interaction, with high confidentiality and integrity impact but no availability impact - consistent with a JSSE (TLS/SSL) trust or authentication-bypass defect rather than a crash. The vuln.today decision label is 'act_now', reinforcing high urgency. Against that, the exploitation-evidence signals are thin and should not be overstated: no CISA KEV listing, no EPSS probability supplied, and no public PoC or exploit reference beyond the Oracle advisory itself. So the picture is a high-severity, easily-exploitable flaw in an extremely widely deployed runtime with no confirmed in-the-wild exploitation at time of analysis. The 'Authentication Bypass' tag aligns with C:H/I:H and A:N (an attacker who defeats JSSE authentication can read and alter protected data but does not take the service down). One point to verify: Oracle lists the same version strings as both 'affected' and in EUVD's affected list, which is Oracle's convention - confirm the specific fixed build for each branch against the Oracle security alert before remediation planning.

An attacker with network access sends crafted data to a network service that uses the vulnerable JSSE component to handle a TLS/secure protocol - for example a web service that feeds attacker-supplied data into the affected APIs - and exploits the authentication/trust weakness to read or tamper with data the connection was meant to protect. A second affected class is sandboxed Java Web Start applications or applets that load untrusted code and rely on the Java sandbox. No public exploit code is identified in the provided data, but Oracle rates the flaw 'easily exploitable' with low attack complexity and no authentication.