Oracle Coherence CVE-2026-60242

The prerequisite is network HTTP reachability to an affected Oracle Coherence 12.2.1.4.0 or 14.1.1.0.0 instance (Fusion Middleware Core); per the CVSS vector (AV:N/AC:L/PR:N/UI:N) there is no authentication, no special configuration, and no user interaction required for exploitation against affected versions. What limits exploitation in practice: Coherence cluster/management listeners are often deployed on internal application-tier networks rather than internet-facing, so the primary mitigating factor is network segmentation and whether the vulnerable listener is exposed beyond trusted hosts. Exploitation is constrained to the two named versions; the exact triggering feature/endpoint is not detailed in Oracle's advisory, so verify listener exposure in your specific deployment.

The signals point to high real-world priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) indicates network-reachable, low-complexity, unauthenticated exploitation with no user interaction and full impact - the strongest possible exploitability profile short of scope change. No EPSS score, SSVC decision, or POC is provided, and the CVE is not in CISA KEV, so there is currently no evidence of active exploitation or automated weaponization; the risk is driven by exploitability and the product's role rather than confirmed in-the-wild activity. One inconsistency to note: the vendor tag says 'Information Disclosure' while both the description ('takeover') and CVSS (C:H/I:H/A:H) indicate full compromise - treat the CVSS/description as authoritative and the tag as understated. Bottom line: a genuine high priority for any exposed Coherence/WebLogic tier, not a high-CVSS-but-low-real-risk case.

An attacker who can reach a Coherence node's HTTP/listener port from the network sends a crafted request that triggers the flaw without any credentials or user interaction, resulting in full compromise of the Coherence instance and the data it holds. Given AV:N/AC:L/PR:N, a single unauthenticated request over HTTP is sufficient, so an exposed cluster in a DMZ or flat network could be taken over remotely. No public proof-of-concept is identified at time of analysis, so real-world attempts would currently require independent exploit development.