CVE-2026-70907 in Java SE
Summary
by MITRE • 08/19/2026
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: 8u501, 11.0.32, 17.0.20, 21.0.12, 25.0.4, 26.0.2; Oracle GraalVM for JDK: 17.0.20 and 21.0.12; Oracle GraalVM Enterprise Edition: 21.3.19. Easily exploitable vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The identified vulnerability resides within the Java Secure Socket Extension, commonly referred to as JSSE, which is a core component of Oracle Java SE and its associated GraalVM distributions. This security flaw affects multiple supported versions including Oracle Java SE 8u501, 11.0.32, 17.0.20, 21.0.12, 25.0.4, and 26.0.2, as well as specific releases of Oracle GraalVM for JDK versions 17.0.20 and 21.0.12, and Oracle GraalVM Enterprise Edition version 21.3.19. The vulnerability is classified under the JSSE component, which handles SSL/TLS protocol implementations in Java applications. This specific flaw allows an unauthenticated attacker with network access via TLS to compromise these systems by exploiting a logic error or resource management issue within the secure socket layer processing routines.
The technical nature of this vulnerability centers on its exploitability through direct API interaction rather than through traditional browser-based attack vectors. Specifically, exploitation requires supplying malicious data directly to APIs within the JSSE component without relying on Untrusted Java Web Start applications or untrusted Java applets. This distinction is critical as it limits the attack surface primarily to server-side services and backend systems that utilize TLS connections programmatically, such as web services, API endpoints, and microservices architectures. The attacker can trigger a partial denial of service condition by causing the JSSE implementation to enter an unstable state or consume excessive resources during the handling of specific malformed or specially crafted TLS handshake data. This results in the degradation of availability for the affected Java SE environment, effectively preventing legitimate users from accessing services hosted on vulnerable systems.
From a risk assessment perspective, this vulnerability carries a CVSS 3.1 Base Score of 5.3, indicating a medium severity level with an impact primarily on availability rather than confidentiality or integrity. The vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) confirms that the attack requires no authentication, has low complexity, and does not require user interaction, while affecting only the availability of the system. In terms of industry standard classifications, this vulnerability aligns with CWE-400, which describes uncontrolled resource consumption leading to denial of service conditions. Furthermore, from a tactical standpoint within the MITRE ATT&CK framework, this behavior corresponds to techniques associated with Resource Hijacking or Denial of Service attacks where an adversary aims to disrupt service availability rather than exfiltrate data or gain persistent access. The lack of requirement for user interface interaction makes it particularly dangerous in automated environments and high-throughput server applications.
Mitigation strategies must focus on immediate patching and architectural hardening. Oracle has released updates that address this flaw, so the primary remediation step is to upgrade all affected Java SE, GraalVM for JDK, and GraalVM Enterprise Edition installations to their respective latest secure versions as specified in the vendor advisory. For environments where immediate patching is not feasible due to operational constraints, network-level controls should be implemented to restrict TLS traffic from untrusted sources. This includes deploying Web Application Firewalls or intrusion prevention systems capable of detecting anomalous TLS handshake patterns associated with this specific vulnerability. Additionally, developers utilizing JSSE APIs in their applications should review code for any direct manipulation of low-level socket parameters and ensure that input validation is applied rigorously to all data passed into secure communication channels. Regular monitoring of system resources such as CPU and memory usage during TLS negotiations can also help in early detection of potential exploitation attempts before a full denial of service occurs.