Oracle Reports Developer CVE-2026-62622

Exploitation requires network reachability to the Oracle Reports Developer IIOP endpoint of a version 12.2.1.19.0 deployment; the CVSS vector (AV:N/AC:L/PR:N/UI:N) indicates no authentication, no user interaction, and low complexity, so against a reachable default deployment there are no additional prerequisites. The concrete limiting factor is exposure of the IIOP protocol port: deployments where IIOP is firewalled, disabled, or restricted to trusted internal hosts are not remotely exploitable by external attackers, and only the specified 12.2.1.19.0 build is confirmed affected. No specific non-default configuration toggle is named in the advisory beyond the IIOP transport being accessible.

This is a genuine top-priority issue rather than an inflated high-CVSS score: the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) indicates trivial, unauthenticated, remote exploitation with full impact, and Oracle itself flags it as 'easily exploitable,' which is a strong signal because vendors are typically conservative. Working against reflexive panic, there is no EPSS score, no published POC, and no CISA KEV listing supplied, so widespread automated exploitation is not yet evidenced - the practical exposure hinges on whether the IIOP port is reachable from untrusted networks, which in well-segmented estates it usually is not. Given Oracle middleware is a frequent target once CPU details are public, even a mid-sized municipal IT team in tczew should treat this as urgent and patch promptly rather than wait for in-the-wild reports. Bottom line: high-confidence high severity by vector and vendor assessment, but current real-world exploitation is unconfirmed, so prioritize based on IIOP exposure.

An attacker who can reach the Oracle Reports Developer IIOP listener over the network sends a crafted request to the Security and Authentication component and, with no credentials and no user interaction, bypasses authentication or triggers remote code execution to take over the server. Because AC:L and PR:N make exploitation trivial and repeatable, an internet-exposed or flat-network deployment could be compromised in a single unauthenticated interaction. No public POC is currently identified, but the low complexity makes exploit development straightforward once technical details circulate.