Join our Newsletter — 33% off our NHI Course

How do you patch or mitigate CVE-2022-21445 (Oracle ADF Faces Deserialization of Untrusted Data)?

CISA’s required action for CVE-2022-21445 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Oracle ADF Faces in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

How to patch or mitigate CVE-2022-21445 in Oracle ADF Faces

Start by proving where Oracle ADF Faces exists in your environment, because this flaw is only actionable once you know which applications, middleware stacks, and exposed endpoints actually use it. For patching, follow Oracle’s security update or documented mitigation exactly, and treat unsupported instances as removal candidates rather than long-term exceptions. CISA Known Exploited Vulnerabilities Catalog and CVE Program are the authoritative references for the vulnerability record and tracking.

Deserialization flaws are dangerous because the input boundary is often weakly visible to operators until exploitation is already possible. In practice, that means patching is only part of the work: you also need to reduce the attack surface around any ADF Faces deployment, especially if the application is reachable from untrusted networks or feeds data from external clients. Insecure Deserialisation Guide explains the failure mode and the kinds of controls that limit object-injection risk.

If you cannot remediate immediately, use compensating controls that materially reduce exposure, not just administrative deferral. The strongest interim actions are to remove direct internet exposure, place the application behind tighter access controls, and verify that any temporary mitigation really blocks the vulnerable code path rather than merely obscuring it. For vulnerability triage and emergency response, Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide provide the right prioritisation lens.

Risk and Threat Considerations

The main risk is not the presence of a CVE record, but the combination of a deserialization weakness and a reachable application path. If attackers can submit crafted input to the affected component, the flaw can become an initial access or code execution path, which makes exposed or externally accessible deployments materially higher risk than isolated internal ones.

Failure mechanism: Untrusted serialized data is accepted and processed by application logic, allowing malicious object structures or gadget chains to alter control flow during deserialization. If the product instance is exposed and the vulnerable path remains active, exploitation can occur before normal application validation or authentication checks stop it.

Impact: Successful exploitation can lead to compromise of the application server, theft of data handled by the application, and follow-on movement into adjacent systems or secrets that the server can reach. Where the system is business-critical, the operational impact can include service interruption, emergency isolation, and a broader incident response rather than a routine patch cycle.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 SI-10 — Information Input Validation Deserialization flaws are input-handling failures that require validating untrusted data.
SC-34 — Non-modifiable Executable Programs Mitigation may require reducing exploitability of application execution paths and deployment exposure.
RA-5 — Vulnerability Monitoring and Scanning The response depends on finding every affected instance and confirming remediation status.
Recommendation — Validate and constrain external input before it reaches deserialization logic. Restrict execution paths so untrusted content cannot alter runtime behavior. Scan for all Oracle ADF Faces deployments and track remediation to closure.
NIST CSF 2.0 PR.IP-12 — Vulnerability Management The question is about prioritizing and remediating an exploited vulnerability.
Recommendation — Use a vulnerability management process to identify, prioritize, and remediate affected systems.

Practitioner Guidance

What to verify: Confirm every deployed Oracle ADF Faces instance, including embedded or legacy deployments that may not appear in standard software inventories. Then verify whether the vulnerable instance is internet-facing, reachable from partner networks, or otherwise accessible from a lower-trust zone.

Decision rule: If the vendor fix or documented mitigation can be applied cleanly, treat that as the primary action and validate it with repeatable testing. If it cannot be applied, remove the exposure path first, then decide whether the application can remain in service under a reduced-risk architecture or must be retired.

Common mistake: Teams often mark the CVE “handled” after a change ticket is raised, even though the application remains reachable and the vulnerable component is still present. The better test is whether the exploit path is actually closed, not whether a maintenance task was opened.

Practitioner takeaway: For a deserialization CVE, the real security question is whether untrusted input can still reach the vulnerable code path, so patching, mitigation, and exposure reduction must be validated together.