Oracle Java SE CVE-2026-83374

Two distinct exploitation paths are described. (1) Server-side: the application must expose the vulnerable Security-component APIs to attacker-supplied data - e.g. a web service that passes untrusted input into those APIs; no authentication or user interaction is required (PR:N/UI:N) but exploitation is rated difficult (AC:H). (2) Client-side sandbox path: applies to deployments that load and run untrusted code from the internet via sandboxed Java Web Start applications or sandboxed Java applets and rely on the Java sandbox for security - modern server/standalone JDK usage that does not run untrusted sandboxed code is largely outside this path. Limiting factors: high attack complexity, integrity-only impact (no data disclosure or DoS), and, for the client path, the increasingly rare use of Web Start/applets. Affected versions include Oracle Java SE 8u503, 8u503-perf, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 27; GraalVM for JDK 17.0.20.1 and 21.0.12.1; and GraalVM Enterprise Edition 21.3.19.1.1.

This is a moderate-severity, high-complexity integrity flaw in the Security component of Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition, rated CVSS 3.1 5.9 with vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N. The signals point to a real but hard-to-exploit issue rather than an urgent one: the attack is network-reachable and unauthenticated (AV:N/PR:N), which raises exposure, but Oracle explicitly labels it 'difficult to exploit' (AC:H), which materially lowers the probability of reliable, widespread attacks. Impact is scoped to integrity only (I:H; C:N/A:N) - unauthorized creation, deletion, or modification of critical data - with no confidentiality or availability loss and no scope change (S:U). No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation; this is 'no public exploit identified at time of analysis.' Because the ubiquity of Java keeps the deployment footprint enormous, the issue warrants routine Critical Patch Update prioritization, but the high complexity and absence of exploitation intelligence argue against emergency treatment. Note a potential conflict: the input Tag 'Authentication Bypass' does not match the description, which describes a Security-component/sandbox integrity flaw, not an auth bypass - verify the underlying weakness against the Oracle advisory. CWE is N/A and no EPSS/KEV data was supplied, so the real-world exploitation probability cannot be quantified from the available signals.

An unauthenticated attacker supplies crafted data over the network to an application that passes it to the vulnerable Security-component APIs - for example, via a web service feeding the API - and, after overcoming significant exploitation difficulty, achieves unauthorized modification or deletion of critical data. Alternatively, in client-side sandboxed Java Web Start or applet deployments, untrusted code loaded from the internet bypasses sandbox restrictions to tamper with data. No public exploit code is identified at the time of analysis.