Oracle Java SE CVE-2026-87294

Two distinct conditions apply. (1) Server-side: an application must expose the affected Security-component APIs to attacker-influenced data - Oracle specifies exploitation 'by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs,' so the JVM must process untrusted input through that path. (2) Client-side: the target must be running a sandboxed Java Web Start application or sandboxed Java applet that loads and runs untrusted code and relies on the Java sandbox - a configuration that is effectively obsolete because Java Web Start and the browser applet plugin were removed from modern JDKs, sharply limiting this surface on current versions. Limiting factors: exploitation requires the JVM to actually receive untrusted/attacker-controlled data through the vulnerable APIs; impact is bounded to partial read and partial modification of a subset of accessible data (no availability impact, no stated code execution). No authentication (PR:N) or user interaction (UI:N) is required per the CVSS vector.

This is a medium-severity (CVSS 6.5) flaw in the Security component of Oracle Java SE and GraalVM, with vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N - network-reachable, low complexity, unauthenticated (PR:N), no user interaction, unchanged scope, with partial confidentiality and integrity impact and no availability impact. On raw exploitability signals it looks attractive (remote, unauthenticated, 'easily exploitable' per Oracle), but the real-world picture is more constrained. No EPSS score, CISA KEV entry, or public POC is present in the supplied data, so there is no evidence of active or imminent exploitation - exploitation status is 'no public exploit identified at time of analysis.' The impact is capped at partial read and partial update/insert/delete of 'some'/'a subset' of accessible data (no full compromise, no code execution stated, no availability loss). A key nuance: one of the two described attack surfaces - sandboxed Java Web Start applications and applets loading untrusted code - is largely obsolete, since Web Start and the browser applet plugin were removed in modern JDKs; the server-side API/web-service data-supply path is the more realistic surface today. Net: a legitimate patch-in-normal-cycle issue, not an emergency. Treat as elevated priority on internet-facing JVMs processing untrusted input, but the absence of EPSS/KEV/POC argues against drop-everything urgency. No CWE was assigned by Oracle, limiting precise root-cause classification.

An attacker with network access sends crafted, untrusted input to an exposed API in the vulnerable Security component - for example via a web service that forwards attacker-controlled data to the affected Java APIs - triggering the flaw without authentication or user interaction. Successful exploitation yields unauthorized read of a subset of data and unauthorized update/insert/delete of some data. No public exploit code is identified at the time of analysis, and the alternative sandboxed-applet/Web Start vector is largely legacy on modern JDKs.