JSSE Vulnerability in Oracle Java SE and Oracle GraalVM Enables Unauthorized Data Access

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u511-b32, 8u511-perf-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; Oracle GraalVM for JDK: 17.0.21.0.2 and 21.0.13.0.2; Oracle GraalVM Enterprise Edition: 21.3.20.0.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 9.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).

• Oracle Java SE: Affected versions are 8u511-b32, 8u511-perf-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2, and 27.0.1.0.2.
• Oracle GraalVM for JDK: Affected versions are 17.0.21.0.2 and 21.0.13.0.2.
• Oracle GraalVM Enterprise Edition: The affected version is 21.3.20.0.2.
• Confirmed Oracle Java SE fixes: Oracle release notes identify fixes in 8u511 b33, 11.0.33.0.3, 17.0.21.0.3, 21.0.13.0.3, 25.0.5.0.3, and 27.0.1.0.3.
• The returned release notes do not separately confirm an exact fixed version for the 8u511-perf branch or for each GraalVM product release. Do not infer that every later or parallel branch is unaffected without reconciling Oracle's Patch Availability Document.

Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition are affected in the JSSE component. Oracle describes exploitation through APIs in that component, including a web service that supplies data to the APIs; the risk matrix identifies multiple protocols. The attacker can provide data over the network without authentication, but the advisory does not disclose the specific API, function, input format, or processing path that triggers the flaw. Oracle's update removes impacted root CA certificates related to eMudhra from the JDK trust store, indicating that the issue involves certificate trust handling in JSSE, although this is an inference from the remediation rather than a complete description of the defect. The exact implementation weakness and minimum data conditions required to trigger it remain undisclosed.

• Reachability: The vulnerability is reachable over the network through multiple protocols and through JSSE APIs; Oracle gives a web service supplying data to those APIs as an example.
• Authentication and interaction: The attacker does not need authentication or user interaction in the described network scenario.
• Complexity: Oracle describes the vulnerability as easily exploitable with low attack complexity.
• Client deployments: The issue also applies to sandboxed Java deployments, particularly Java Web Start applications or Java applets that load and run untrusted code.
• Known status: The normalized record marks public exploit as false and does not confirm a known-exploited status. That does not prove that exploitation has never occurred.

The vulnerability may allow an unauthenticated remote attacker to bypass expected JSSE protections and perform unauthorized operations on data accessible to the Java process. Oracle describes possible outcomes including reading critical data, accessing all available data, and creating, deleting, or modifying data. Because the stated scope is unchanged, the permissions of the compromised process may determine the practical data boundary, but the record does not provide additional operating-system or application privilege details. Organizations may need to investigate data integrity, review services using JSSE, and handle certificate compatibility failures after applying the fix. No availability impact is confirmed by the available evidence.

• Data: A successful attack may compromise the confidentiality of data used by the runtime or application and may allow unauthorized creation, deletion, or modification of critical data.
• Access: The practical scope may include all data accessible to the affected Oracle Java SE or GraalVM process, not only data owned by JSSE.
• Exposed services: Network services that supply data to JSSE APIs should be prioritized because the Oracle description does not require attacker authentication.
• Clients: Client deployments that execute untrusted code inside the Java sandbox may also be affected.
• Limit: The record does not describe an availability consequence and provides no evidence of a specific breach, data alteration, or compromise.

1. Update Oracle Java SE first: Move affected Oracle Java SE branches to the corresponding Oracle-confirmed fixed releases: 8u511 b33, 11.0.33.0.3, 17.0.21.0.3, 21.0.13.0.3, 25.0.5.0.3, or 27.0.1.0.3, as applicable to the deployed branch. For 8u511-perf-b32, confirm the corresponding fixed perf build in Oracle's release documentation rather than inferring it from the standard JDK build.
2. Address GraalVM deployments: Update Oracle GraalVM for JDK and Oracle GraalVM Enterprise Edition according to the corresponding Java release and the Patch Availability Document linked by Oracle. The returned sources do not name a separate GraalVM fixed release, so an exact product-specific boundary should not be assumed.
3. If patching is not immediately possible: Apply the mitigations recommended by Oracle for the impacted eMudhra-related root CAs. Do not treat a manual trust-store edit as complete remediation unless it has been reconciled with Oracle guidance and the certificates used by the application.
4. Test after the change: Test TLS connections and JAR-signature verification workflows that may depend on removed root certificates. Confirm that legitimate certificates are replaced or configured according to the certificate owner's guidance.
5. Reduce exposure: Temporarily restrict unnecessary endpoints or services that supply data to JSSE APIs, and retire obsolete sandboxed Java Web Start or applet deployments where they are not required.

1. Inventory runtimes: Identify every Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition installation, including runtimes embedded in servers, desktop applications, web services, and build environments.
2. Check versions: Compare installed versions with the affected branches in affected_summary. Do not check only the system JDK, because an application may use a bundled JRE or JDK.
3. Inspect trust stores: Review cacerts and application-specific trust stores for impacted eMudhra and Comodo root certificates that Oracle removes in its updates. Their presence is a review signal, not standalone proof of exposure because repackaged runtimes and custom trust stores may differ.
4. Review entry points: Identify services that supply data to JSSE APIs and clients still running sandboxed Java Web Start applications or Java applets with untrusted code.
5. Validate after patching: Review TLS handshake failures and signed-JAR verification failures that may appear after the impacted root certificates are removed. This is post-update compatibility validation, not a published exploitation IOC.
6. Oracle has not disclosed a dedicated log event, IOC, or detection signature for exploitation of this vulnerability.