Oracle JDeveloper CVE-2026-61061

Exploitation requires the attacker to already have a valid low-privileged account with interactive logon to the host where Oracle JDeveloper executes (AV:L, PR:L) - this is not remotely reachable over the network and cannot be triggered by an unauthenticated attacker. The affected configuration is any deployment of JDeveloper 12.2.1.4.0 or 14.1.2.0.0 with the Security Framework component present (default). Limiting factors that reduce realistic risk: high attack complexity (AC:H) implies special timing, state, or environmental conditions the attacker cannot fully control; local-only access means an existing foothold on the developer/build host is a prerequisite; and no user interaction is required (UI:N) once local access is obtained. There is no confirmed public exploit, further limiting near-term exploitation.

The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, score 7.0 High) presents a mixed risk picture: impact is severe (full C/I/A takeover) but exploitability is deliberately constrained by a local attack vector, high attack complexity, and a requirement for existing low-privilege access. There is no EPSS score, no CISA KEV listing, and no evidence of a public proof-of-concept in the provided data, all of which point to low near-term real-world exploitation likelihood. This is a genuine 'high CVSS, low immediate real-world urgency' case for most organizations: an attacker already needs a foothold on the JDeveloper host and must overcome non-trivial conditions (AC:H). Note the tension between Oracle's 'Information Disclosure' tag and the full I:H/A:H impact - the tag likely understates the vulnerability, so defenders should treat it as a takeover risk, not merely a data leak. Because it is bundled in an Oracle quarterly Critical Patch Update, patch it on the standard CPU cadence rather than as an emergency.

An attacker who has already gained a low-privileged local account on a developer workstation or build server running Oracle JDeveloper (e.g., via phishing, a stolen credential, or an insider) exploits the Security Framework weakness to escalate to full control of the JDeveloper installation, reading stored credentials/source and tampering with builds. Success requires overcoming the high attack complexity (AC:H) and no user interaction is needed; no public proof-of-concept is identified at time of analysis.