Oracle Database Server EXTPROC authentication bypass enables remote code execution

Oracle 8i and 9i with PL/SQL package for External Procedures (EXTPROC) allows remote attackers to bypass authentication and execute arbitrary functions by using the TNS Listener to directly connect to the EXTPROC process.

• Oracle Database Server: versions 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.5.1, 8.0.6, 8.1.5, 8.1.6, 8.1.7, and 8.1.7.0.0 are marked affected.
• Oracle8i: versions 8.1.5, 8.1.6, 8.1.7, 8.1.7.1, enterprise_8.0.5.0.0, enterprise_8.0.6.0.0, enterprise_8.0.6.0.1, enterprise_8.1.5.0.0, enterprise_8.1.5.0.2, enterprise_8.1.5.1.0, enterprise_8.1.6.0.0, enterprise_8.1.6.1.0, enterprise_8.1.7.0.0, and enterprise_8.1.7.1.0 are marked affected.
• Oracle9i: versions 9.0 and 9.0.1 are marked affected.
• The normalized record states that a patch is available, but it does not provide an exact fixed release or branch-specific fix boundary. A branch not listed here should not be assumed to be unaffected.

The flaw is in the PL/SQL External Procedures path, where the Oracle Listener asks an extproc or extproc.exe process to load an external library and call a function. Authentication is checked in the Oracle child process, but the Listener receives the library-loading request and assumes that the requesting process has already authenticated. An attacker can impersonate an Oracle process, connect to the Listener or EXTPROC over a socket, and request execution of arbitrary functions in libraries without a database account. The internal flow may use named pipes in some deployments, but the advisory states that it can be forced to use sockets, enabling remote TCP access. Exposure depends on whether the Listener and EXTPROC functionality are enabled and reachable from an untrusted network. The available evidence does not establish one mandatory library, function, or deployment configuration for every affected system.

• Reachability: The flaw is remotely reachable through network connections to the TNS Listener or EXTPROC process.
• Authentication: The normalized record and advisory describe exploitation without prior authentication.
• Complexity: The normalized record identifies low attack complexity.
• User interaction: No user interaction requirement is described in the available evidence.
• Exploitation status: The research advisory reports that working exploit code was provided to Oracle during disclosure. The available evidence does not establish current in-the-wild exploitation or a publicly distributed exploit.

Successful exploitation allows arbitrary code or function execution in a library with the privileges of the account running Oracle. The advisory identifies that account as commonly oracle on Unix and as SYSTEM by default on Windows, although the actual privilege level depends on deployment. The technical outcome may include reading data, modifying data, or disrupting services, corresponding to confidentiality, integrity, and availability impact. The level of control cannot be generalized across all systems because it depends on the service account and host permissions.

An attacker may perform arbitrary operations on the server with the privileges of the Oracle service account without obtaining a database account. This may enable unauthorized access to data available to that account, unauthorized changes, or disruption of database and operating-system services. The practical impact depends on the service account's permissions, host controls, and whether the Listener is reachable from an untrusted network. The available evidence does not prove a breach, data disclosure, or complete administrative control on every deployment.

1. Identify the exact deployed product and branch, then obtain and apply the corresponding Oracle security patch. The record states that a patch is available but does not confirm an exact fixed release, so do not infer an open-ended fixed range or reuse a fix boundary from another branch.
2. Use a firewall to restrict Listener access, particularly by blocking Internet or untrusted-network access to the default port 1521.
3. If External Procedures are not required, disable PLSExtproc or icache_extproc by removing the relevant entries from tnsnames.ora and listener.ora. Any removal or disabling of extproc should be validated against application dependencies and operational procedures.
4. If the functionality is required, configure trusted-node checking in sqlnet.ora with tcp.validnode_checking = YES and an allowlist in tcp.invited_nodes.
5. Run Oracle processes with only the privileges they require. On Windows, avoid running Oracle under the SYSTEM account when a lower-privileged service account can be used. Moving the Listener away from 1521 is only a secondary exposure-reduction measure and does not replace patching or access control.

1. Inventory Oracle Database deployments and compare them with the affected releases listed in this entry.
2. Inspect tnsnames.ora and listener.ora for external-procedure configurations or service names such as PLSExtproc, icache_extproc, and extproc.
3. Determine which networks can reach the Listener, including whether an untrusted network can reach the default port 1521 or the configured Listener port.
4. Review sqlnet.ora for tcp.validnode_checking and tcp.invited_nodes controls that restrict permitted clients.
5. Verify the operating-system account used by Oracle processes, especially on Windows, and review network telemetry for unexpected connections to the Listener or EXTPROC. This is precautionary monitoring, not a confirmed IOC; the absence of log evidence does not establish that a system is safe.