CVE-2026-91477 in JavaFX
Summary
by MITRE • 10/21/2026
Vulnerability in the Oracle JavaFX product of Oracle Java SE (component: JavaFX). Supported versions that are affected are Oracle JavaFX: 25.0.4 and 27. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle JavaFX. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle JavaFX 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 3.1 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The identified vulnerability resides within the Oracle JavaFX component of Oracle Java SE, specifically affecting versions 25.0.4 and 27. This security flaw is characterized by a difficult-to-exploit nature that permits an unauthenticated attacker to compromise the integrity of the application through network access via multiple protocols. The core technical issue involves a failure in how the JavaFX runtime handles certain inputs or states, leading to unauthorized read access against a subset of accessible data within the JavaFX environment. This type of flaw is typically categorized under CWE-200 as an Information Exposure vulnerability, where sensitive information may be disclosed to an attacker who does not have explicit authorization to view it. The complexity of exploitation suggests that while the underlying mechanism exists, triggering it requires specific conditions or sequences that are not trivially achievable by automated tools alone.
The operational impact of this vulnerability is primarily confined to confidentiality, as indicated by a CVSS 3.1 Base Score of 3.1 with low impact on integrity and availability. The attack vector allows for unauthorized reading of data, which could potentially expose user-specific information or application state if the attacker can successfully trigger the condition. However, the requirement for human interaction significantly mitigates the risk in many scenarios. Successful exploitation necessitates that a person other than the attacker interacts with the vulnerable system, such as by clicking on a malicious link, opening a compromised file, or engaging with a manipulated JavaFX interface element. This aligns with ATT&CK technique T1534, which involves internal spearphishing where an adversary uses social engineering to trick users into taking actions that facilitate further compromise. The presence of this human-in-the-loop requirement acts as a substantial barrier for automated attacks and reduces the likelihood of widespread exploitation in environments without active user engagement.
It is critical to note the specific deployment context in which this vulnerability applies, as it strictly pertains to Java deployments running sandboxed applications rather than server-side implementations. The flaw affects clients executing sandboxed Java Web Start applications or sandboxed Java applets that load and run untrusted code from the internet while relying on the Java sandbox for security boundaries. In these environments, the assumption is that untrusted code should be restricted in its access to system resources and data. The vulnerability represents a breach of this isolation model, allowing potentially malicious code loaded via Web Start or applet mechanisms to bypass expected restrictions and read internal data structures. Conversely, the advisory explicitly states that this vulnerability does not apply to Java deployments on servers where only trusted code is executed by administrators. This distinction highlights that server-side applications with strict access controls and pre-approved libraries are insulated from this specific threat vector because they do not rely on the same sandboxing mechanisms for untrusted internet-sourced content.
Mitigation strategies must focus on updating the Oracle Java SE environment to a version where the flaw in the JavaFX component has been remediated by Oracle. Organizations should prioritize patching systems running affected versions 25.0.4 and 27, particularly those deploying Java Web Start or applets that interact with untrusted sources. In addition to software updates, administrators should evaluate whether legacy technologies like Java Applets are still necessary in their infrastructure, as these present inherent risks due to their reliance on browser plugins and sandboxing mechanisms that have been deprecated or restricted by modern web standards. Implementing strict allow-lists for trusted code sources can further reduce the attack surface. Security awareness training is also recommended to mitigate the human interaction aspect of this vulnerability, ensuring users are cautious when interacting with Java-based applications from unverified origins. By combining technical remediation through patch management with operational controls and user education, organizations can effectively neutralize the risk posed by this information disclosure flaw in Oracle JavaFX.