The 9.8 CVSS on this CVE is technically accurate—network-exploitable as low-privilege user with complete system compromise is as bad as it gets. But the EPSS score of 0.00424 is your actual risk signal, and the gap between these numbers is the key to this CVE: it's gated by a privilege that most Oracle deployments don't grant casually.
DBMS_CLOUD execute privilege is not a default. It exists specifically to enable Oracle databases to interact with cloud object storage, load data from external sources, and drive ETL pipelines. That means the question isn't whether to patch—always patch—but whether this vulnerability actually applies to your environment and, more importantly, whether you can detect exploitation if it does apply.
Start by inventorying who holds DBMS_CLOUD execute in your Oracle estate. Query DBA_TAB_PRIVS for grantee='PUBLIC' or grants on DBMS_CLOUD where the grantee isn't a DBA account. Then distinguish between application schemas that legitimately need this for ETL versus any account with network exposure via Oracle Net. If ETL service accounts have both DBMS_CLOUD execute AND network-accessible listeners, that's your priority gap—not because exploitation is likely, but because if it happens, it will look identical to normal data loading operations.
The affected versions—19c through 19.31, and 23ai (23.4.0-23.26.2)—span both legacy and newer deployments. If you're on 19c with years of accumulated privilege grants, treat this as a configuration review. If you're on 23ai, it's a more recent deployment question: why was this privilege granted at all? The patch is necessary but insufficient. The real remediation is understanding whether DBMS_CLOUD execute in your environment represents a justified operational need or an undocumented blast radius sitting inside your perimeter.