Oracle Java SE EUVD-2026-106627

Exploitation requires a Java application that uses the JSSE component to process attacker-supplied TLS data - i.e., it exposes a network-reachable TLS endpoint or web service whose APIs consume untrusted TLS input (AV:N/AC:L/PR:N/UI:N, no authentication, no special configuration, no user interaction). The practical limiting factor is impact scope, not access: the vulnerability yields only a partial denial of service (A:L) with no confidentiality or integrity effect, and it only matters where a Java process actually handles untrusted TLS traffic. A secondary vector exists for sandboxed Java Web Start applications or applets that load untrusted code, but this deployment mode is deprecated and rare in current environments, so it is a minor concern for most defenders.

This is a moderate, availability-only issue despite affecting an ubiquitous product. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, base 5.3) indicates a network-reachable, low-complexity, unauthenticated flaw, but impact is confined to a PARTIAL denial of service (A:L) with no confidentiality or integrity impact - this is a hang/resource-exhaustion class issue in the JSSE/TLS stack, not code execution or data disclosure. No EPSS score, SSVC decision, KEV listing, or POC was provided in the input, so there is no signal of active exploitation or automatability; per the input this is 'no public exploit identified at time of analysis.' The realistic priority is MEDIUM-LOW: the wide Java footprint raises aggregate exposure, but the capped availability impact and absence of any exploitation evidence mean this is a routine patch-cycle item (Oracle CPU October 2026) rather than an emergency. Note the dual-attack-surface framing in Oracle's description: the primary vector is server-side TLS APIs, while the secondary sandboxed-applet/Web Start vector is largely obsolete in modern deployments - verify which surface applies to your environment.

An attacker with network access to a Java service that terminates or initiates TLS via JSSE (e.g., an HTTPS endpoint, message broker, or web service) supplies crafted TLS protocol data to the exposed API. Processing the malicious input triggers a flaw in the JSSE component that exhausts or stalls resources, degrading availability. No authentication or user interaction is required, but the outcome is limited to a partial denial of service; no public exploit code is identified at time of analysis.