CVE-2026-91462 in Java SE
Summary
by MITRE • 10/21/2026
Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JGSS). Supported versions that are affected are Oracle Java SE: 8u503, 8u503-perf, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 27; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Difficult to exploit 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. 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.9 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The identified vulnerability resides within the Java GSS-API, commonly referred to as JGSS, a core component of Oracle Java SE and its associated GraalVM distributions. This security flaw affects multiple supported versions including Oracle Java SE 8u503 through 27, Oracle GraalVM for JDK versions 17.0.20.1 and 21.0.12.1, as well as Oracle GraalVM Enterprise Edition version 21.3.19.1.1. The JGSS module is responsible for implementing the Generic Security Services Application Program Interface, which provides a generic interface to security services such as authentication and data integrity protection across various mechanisms like Kerberos or SPNEGO. While this component is critical for secure enterprise communications, it contains an implementation error that can be triggered under specific conditions involving network-accessible protocols.
The technical nature of the flaw allows an unauthenticated attacker with network access via multiple protocols to compromise the affected systems. The vulnerability is characterized by a difficult exploitation vector, indicated by a high complexity rating in the CVSS scoring model. This difficulty arises because the attack requires supplying malicious data directly to specific APIs within the JGSS component. Crucially, this exploit does not rely on traditional client-side vectors such as untrusted Java Web Start applications or applets, which are increasingly deprecated and restricted in modern browsers. Instead, the vulnerability is triggered through server-side interactions, specifically when processing requests from web services or other network-based clients that interact with the JGSS authentication mechanisms. The attacker must craft specific inputs that exploit logic errors within how these APIs handle security tokens or context states during the negotiation phase of secure connections.
The operational impact of a successful exploitation is significant, primarily centered on integrity violations rather than confidentiality breaches or availability disruptions. An attacker who successfully exploits this vulnerability can achieve unauthorized creation, deletion, or modification access to critical data and all Oracle Java SE accessible data within the scope of the compromised application. This aligns with high-impact Integrity metrics in standard security frameworks. The ability to modify critical data implies that an adversary could alter configuration settings, tamper with transactional records, or inject malicious logic into processes running under the affected JVM instance. Since JGSS is often used for establishing trusted channels between services, compromising it can lead to a broader breach of trust within microservices architectures where service-to-service authentication relies on these mechanisms.
From an industry standards perspective, this vulnerability maps closely to CWE-20 Improper Input Validation and potentially CWE-787 Out-of-bounds Write if the memory corruption aspect is involved in specific JGSS implementations. In terms of attack tactics, it corresponds to MITRE ATT&CK techniques related to Initial Access via Network Service Exploitation and Defense Evasion through manipulation of authentication mechanisms. The CVSS 3.1 base score of 5.9 reflects a medium severity rating driven by the high integrity impact despite the low availability and confidentiality impacts. The vector string AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N confirms that while no user interaction or privileges are required, the attack complexity is high due to the specific API-level requirements for exploitation.
Mitigation strategies must focus on both immediate patching and architectural hardening. Oracle has released updates addressing this vulnerability in the specified versions listed above. Organizations running affected Java SE or GraalVM editions should prioritize applying these security patches immediately after verifying compatibility with their existing applications. For environments where upgrading is not immediately feasible, network segmentation plays a vital role in reducing exposure. Since the attack requires network access via multiple protocols to reach the JGSS APIs, restricting inbound traffic to only necessary ports and implementing strict firewall rules can limit the attack surface. Additionally, deploying Web Application Firewalls with deep packet inspection capabilities may help detect anomalous patterns associated with exploiting this specific API flaw before they result in successful compromise.
Long-term resilience requires a review of how Java applications interact with external services using JGSS. Developers should ensure that all inputs to security-related APIs are rigorously validated and sanitized, adhering to the principle of least privilege for service accounts involved in authentication processes. Monitoring logs for unusual authentication failures or unexpected context state changes can provide early warning indicators of exploitation attempts. Furthermore, organizations should evaluate whether alternative secure communication protocols or modernized authentication frameworks like OAuth 2.0 with mutual TLS are more appropriate for their use cases, potentially reducing reliance on legacy JGSS mechanisms that may carry inherent implementation risks. Regular vulnerability scanning and penetration testing focused on network-facing Java services will help identify similar weaknesses before they can be leveraged by adversaries.