CVE-2022-21445

What is Oracle ADF Faces?

Oracle ADF (Application Development Framework) is Oracle's Java EE-based development framework for building enterprise web applications, bundled with Oracle JDeveloper and used throughout Oracle Fusion Middleware (including Oracle Fusion Applications, WebCenter, and related products). ADF Faces is the JSF-based UI component library — virtually every Oracle-built enterprise application and many customer-built Oracle Fusion Middleware deployments use it.

Overview

CVE-2022-21445 is a pre-authentication remote code execution vulnerability in Oracle ADF Faces, caused by insecure Java deserialization. An unauthenticated attacker with HTTP network access can send a crafted serialized Java object to the application, triggering arbitrary code execution on the server. CVSS 9.8 (Critical). Notably, Oracle patched this vulnerability in April 2022, but CISA did not add it to the KEV catalog until September 2024 — more than two years later — confirming active exploitation was still occurring long after the patch was available.

Affected Versions

Technical Details

The vulnerability is a deserialization of untrusted data flaw (CWE-502) in the ADF Faces framework's state management or view restore mechanism. ADF Faces uses Java serialization to persist and restore component state across HTTP requests — a design pattern common in JSF-based frameworks. The deserialization endpoint is accessible to unauthenticated users because state restoration occurs before authentication checks.

An attacker sends an HTTP request with a crafted serialized Java payload (using a gadget chain from a library on the classpath, such as Commons Collections or similar) to the ADF Faces deserialization endpoint. The server deserializes the object without validation, executing the embedded payload code with the privileges of the application server process.

Key characteristics:

• No authentication required: The deserialization endpoint is reached before the application's authentication logic
• Single HTTP request: No multi-step interaction needed
• Gadget-chain dependent: Requires an exploitable gadget chain in the application's classpath (common in enterprise Oracle environments)
• Affects all ADF Faces deployments: Any application built on ADF Faces and accessible over HTTP is potentially vulnerable

Discovery

Disclosed via Oracle's standard Critical Patch Update process in April 2022. The two-year gap before KEV addition suggests the vulnerability was quietly exploited against organizations that had not applied Oracle patches, which are notoriously complex and slow-moving in enterprise environments.

Exploitation Context

Oracle Fusion Middleware applications are deeply embedded in enterprise operations — finance systems, HR platforms, and custom applications built on Oracle's middleware stack. These systems are often accessible from the internet for partner and remote worker access.

Oracle's patching cadence (quarterly Critical Patch Updates) and the complexity of Oracle Middleware upgrades mean many organizations run outdated versions for extended periods. The two-year window between patch (April 2022) and KEV addition (September 2024) is consistent with attackers targeting unpatched stragglers — a common pattern for complex enterprise middleware vulnerabilities.

Remediation

1. Apply the Oracle April 2022 Critical Patch Update: Upgrade ADF Faces to a patched version per Oracle's patching guidance.
2. Apply all Oracle CPU patches: Organizations running Oracle Fusion Middleware should apply Critical Patch Updates promptly; quarterly patches are the primary security mechanism for Oracle products.
3. Restrict network access: Place Oracle Fusion Middleware applications behind authentication proxies or web application firewalls where possible, limiting exposure of deserialization endpoints.
4. Monitor for exploitation indicators: Look for unexpected outbound connections, process spawning from the application server, or unusual file creation that may indicate post-exploitation activity.
5. Java deserialization filters: Consider implementing Java serialization filters (available since Java 9 via ObjectInputFilter) to restrict which classes can be deserialized.