CVE-2026-46775 — Oracle REST Data Services Critical Compromise via HTTPS

Executive Summary

A critical vulnerability (CVE-2026-46775) has been disclosed in Oracle REST Data Services (ORDS), Oracle's widely deployed HTTP/HTTPS interface layer for Oracle Database. The flaw carries a CVSS score of 9.9 — among the highest severity ratings possible — and allows a low-privileged attacker with network access via HTTPS to fully compromise Oracle REST Data Services.

CVSS Score: 9.9 (Critical)

Oracle has noted that while the vulnerability exists within Oracle REST Data Services itself, attacks may significantly impact additional products connected to or exposed through ORDS. This lateral impact pattern is common with ORDS vulnerabilities because ORDS serves as the HTTP gateway for Oracle APEX applications, Oracle Database APIs, RESTful web services, and Oracle Autonomous Database interactions.

ORDS versions 24.2.0 through 26.1.0 are affected. Immediate patching is required.

Vulnerability Overview

Affected Products

Note: Oracle's advisory indicates the vulnerability's scope is Changed, meaning successful exploitation of ORDS can enable attacks against adjacent Oracle products including Oracle Database, Oracle APEX, and Oracle Autonomous Database services that rely on ORDS as their HTTP gateway.

Technical Analysis

What Is Oracle REST Data Services (ORDS)?

Oracle REST Data Services is the standard HTTP/HTTPS interface layer for Oracle Database deployments. It acts as a middleware between web clients and Oracle databases, providing:

• RESTful APIs for Oracle Database tables and views
• Oracle Application Express (APEX) HTTP gateway — APEX requires ORDS to function
• Database Actions (formerly SQL Developer Web) — browser-based SQL and database management
• Oracle Autonomous Database REST interface
• Custom RESTful web services built on PL/SQL handlers
• SODA (Simple Oracle Document Access) for document store operations

ORDS is deployed in nearly every modern Oracle Database environment, from on-premises enterprise deployments to Oracle Cloud Infrastructure (OCI) and Oracle Autonomous Database. Its role as the sole HTTP gateway for APEX and Database Actions makes it a critical component in Oracle stacks.

Why CVSS 9.9?

The unusually high score of 9.9 (versus the more typical 9.8 maximum for many critical flaws) reflects the Changed scope of this vulnerability. Oracle's CVSS scoring model assigns a higher base score when exploitation of one component leads to compromise of components outside the vulnerable component's security scope.

For ORDS, this means:

• Exploitation of CVE-2026-46775 does not just compromise ORDS itself
• It enables an attacker to compromise Oracle Database instances ORDS is connected to
• It may enable compromise of Oracle APEX applications running through ORDS
• It may enable access to business data stored in databases behind the ORDS gateway
• It may enable compromise of Oracle Cloud resources in OCI environments using ORDS

Exploitation Prerequisites

Unlike CVE-2026-34311 (Oracle OPERA 5, which requires zero authentication), CVE-2026-46775 requires a low-privileged account. In most ORDS deployments, this means:

• A valid ORDS database user (even a low-privilege read-only account)
• An APEX workspace user in environments where APEX is deployed
• Any account with the ability to authenticate to ORDS over HTTPS

The bar for the "low-privileged" requirement is typically very low — many ORDS deployments have public-registration APEX workspaces, trial accounts, or shared credentials for external partners and vendors.

Attack Surface

Client (attacker with low-privilege ORDS credentials)
    |
    | HTTPS request to ORDS
    v
Oracle REST Data Services (ORDS) — vulnerable component
    |
    |--- Oracle Database (direct DB connection via JDBC)
    |--- Oracle APEX Runtime Schema
    |--- Oracle Autonomous Database (in cloud deployments)
    |--- Custom PL/SQL REST handlers
    |--- Oracle Database Actions
    v
Full compromise of ORDS and connected Oracle resources

Impact Assessment

Immediate Remediation

Step 1: Apply Oracle Critical Patch Update

Check Oracle's CPU advisory for the applicable patch for CVE-2026-46775 and apply it immediately.

# Check current ORDS version
java -jar ords.war version
# or
ords --version
 
# For standalone ORDS deployments, download the patched version from:
# My Oracle Support → Patches & Updates → CVE-2026-46775
 
# For ORDS deployed in Tomcat or WildFly:
# Replace ords.war with the patched version and restart the application server
 
# For Oracle Autonomous Database (ORDS managed by Oracle):
# Oracle applies patches automatically — verify your patch level in OCI console

Step 2: Network Controls — Restrict ORDS Exposure

Until patching is complete, restrict who can reach ORDS:

# Nginx reverse proxy — restrict ORDS access to known IP ranges
# Block general internet access if ORDS is not intended to be public-facing
location /ords/ {
    # Allow internal network and known partner IPs only
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    allow 172.16.0.0/12;
    # Add specific trusted external IPs if needed
    # allow 203.0.113.50;
    deny all;
    proxy_pass http://ords_backend:8080;
}

# Oracle Linux / RHEL firewalld — restrict ORDS port
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" port port="8080" protocol="tcp" accept'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="8080" protocol="tcp" reject'
firewall-cmd --reload

Step 3: Audit Low-Privilege Accounts

Review accounts with ORDS access and remove unnecessary accounts:

-- Review ORDS REST-enabled database users
SELECT username, account_status, created
FROM dba_users
WHERE username NOT IN ('SYS','SYSTEM','DBSNMP','APPQOSSYS')
AND account_status = 'OPEN'
ORDER BY created DESC;
 
-- Review ORDS REST-enabled schemas
SELECT schema, status, parsing_schema
FROM all_ords_schemas;
 
-- Disable any ORDS-enabled schemas that do not require REST access
BEGIN
  ords.disable(p_schema => 'SCHEMA_NAME');
  COMMIT;
END;
/

Step 4: Review ORDS Privilege Grants

Ensure ORDS connects to the database with minimal required privileges:

-- Check the ORDS_PUBLIC_USER and ORDS_METADATA users' privileges
SELECT grantee, privilege
FROM dba_sys_privs
WHERE grantee IN ('ORDS_PUBLIC_USER', 'ORDS_METADATA', 'APEX_PUBLIC_USER');
 
-- Remove any overly broad privileges granted to ORDS service accounts
-- ORDS should NOT have DBA, SYSDBA, or CREATE ANY privileges
REVOKE DBA FROM ORDS_PUBLIC_USER;

Detection Indicators

Post-Remediation Checklist

1. Apply Oracle CPU patch for CVE-2026-46775 on all ORDS instances
2. Rotate ORDS service account credentials (ORDS_PUBLIC_USER, ORDS_METADATA)
3. Audit all ORDS REST-enabled schemas — disable REST access for schemas that do not require it
4. Review Oracle APEX workspace accounts — remove inactive or test accounts
5. Inspect ORDS access logs for exploitation evidence prior to patching
6. Verify Oracle Database audit logs for unusual DML or DDL operations via the ORDS connection
7. Check connected applications — all APEX apps served through ORDS should be audited for tampering
8. In OCI/Autonomous Database deployments, verify Oracle-managed patch status in the console
9. Notify your DPO if customer or business data may have been accessed — data protection law notification obligations apply

References

• NVD — CVE-2026-46775
• Oracle Critical Patch Update Advisory
• Oracle REST Data Services Documentation
• Oracle APEX and ORDS Deployment Guide
• Oracle My Oracle Support