CVE-2025-30754 in Java SE
Summary
by MITRE • 07/15/2025
Vulnerability in Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE: 8u451, 8u451-perf, 11.0.27, 17.0.15, 21.0.7, 24.0.1; Oracle GraalVM for JDK: 17.0.15, 21.0.7 and 24.0.1; Oracle GraalVM Enterprise Edition: 21.3.14. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE accessible data as well as unauthorized read access to a subset of Oracle Java SE accessible data. Note: This vulnerability 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. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/28/2025
This vulnerability resides within the Java Secure Socket Extension component of Oracle Java SE, representing a significant security weakness that affects multiple version lines including Java 8, 11, 17, 21, and 24, along with corresponding GraalVM implementations. The flaw manifests as a difficulty in exploitation scenario that permits unauthenticated attackers to compromise systems through network-based TLS connections, making it particularly concerning for environments where sandboxed Java applications are executed. The vulnerability's classification under CWE-250 indicates improper privilege management or insufficient access control mechanisms within the JSSE implementation. According to the CVSS 3.1 scoring system with a base score of 4.8, the vulnerability presents a moderate risk level with low attack complexity and no requirement for prior privileges or user interaction, though it requires network access to exploit effectively.
The technical exploitation of this vulnerability occurs within the context of sandboxed Java Web Start applications or applets that execute untrusted code downloaded from the internet. These applications rely on the Java sandbox security model to prevent malicious code from accessing system resources or data. However, the flaw in the JSSE component creates a pathway for attackers to potentially bypass these security boundaries. The impact assessment reveals that successful exploitation could enable unauthorized modification of data through update, insert, or delete operations on accessible Oracle Java SE data, alongside unauthorized read access to sensitive information within the system's data scope. This aligns with ATT&CK technique T1059.007 for application execution and T1566 for credential access through network-based attacks. The vulnerability's scope is limited to client-side deployments where untrusted code execution occurs, excluding server environments that typically run only trusted administrator-installed code.
The operational impact of this vulnerability extends beyond simple data integrity concerns to encompass potential compromise of entire client-side security models. Systems running sandboxed Java applications that load internet-based code are particularly at risk, as attackers could leverage this weakness to manipulate data or extract confidential information from applications that should be isolated by design. The attack vector through TLS connections makes this vulnerability particularly dangerous in environments where network traffic is monitored or intercepted, as the exploitation process could occur without detection. Organizations utilizing Java Web Start applications or applets for business-critical functions face elevated risk levels, especially when these applications process sensitive data or interact with external resources. The vulnerability's presence in multiple Java version lines means that organizations must conduct comprehensive inventory assessments to identify affected systems and prioritize remediation efforts accordingly, with particular attention to deployments that execute untrusted code from external sources.