Is CVE-2022-21445 (Oracle ADF Faces Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2022-21445 to its Known Exploited Vulnerabilities catalogue on 18 September 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Oracle ADF Faces library, included with Oracle JDeveloper Distribution, contains a deserialization of untrusted data vulnerability leading to unauthenticated remote code execution.

What “exploited in the wild” means for this CVE

For a CVE like this, “exploited in the wild” means the issue is no longer just a lab finding or proof of concept. The practical takeaway is that exposure may already be active in real environments, so defenders should treat it as a credible intrusion path and not wait for local detection before prioritising review, mitigation and hunting.

That distinction matters because KEV listing is an operational signal, not just a registry update. When CISA adds a CVE to the CISA Known Exploited Vulnerabilities Catalog, the issue has crossed the threshold from theoretical risk into observed exploitation, which changes patch triage, exception handling and incident response urgency.

For a deeper working model of that response path, the Zero-Day and Exploited Vulnerabilities Guide covers how to prioritise KEV items, when to trigger emergency mitigation and how to sequence post-patch validation.

What the Oracle ADF Faces issue implies operationally

The vulnerable component here is Oracle ADF Faces, included with Oracle JDeveloper Distribution, and the weakness is deserialisation of untrusted data that can lead to unauthenticated remote code execution. That combination makes initial access especially attractive because exploitation does not depend on stolen credentials or prior authentication.

In practice, the question is not only whether the product exists somewhere in your estate. You need to confirm whether the vulnerable component is deployed, reachable and exposed through a path an external party could hit, then determine whether any compensating control, reverse proxy rule or network restriction materially reduces that exposure.

The best reference point for the vulnerability class itself is the Insecure Deserialisation Guide, which explains why object injection, gadget chains and unsafe type handling so often turn into code execution rather than a simple application error.

What defenders should do before assuming compromise is absent

If you have Oracle ADF Faces in scope, first confirm whether the affected product is actually present in internet-facing or internally reachable systems, then verify whether the vendor’s remediation path has been applied. If patching is delayed, containment matters: reduce exposure, restrict access paths, and assume the service may already have been probed once it appears in KEV.

Because KEV status signals real-world exploitation, you should also look for pre-compromise indicators rather than only waiting for obvious malware artifacts. Review authentication logs, application error logs, unusual process spawning, unexpected outbound connections and any change in server-side behaviour that would be consistent with remote code execution.

For prioritisation and verification discipline, the Vulnerability Management Guide is useful because it ties KEV status to asset scope, exception handling, remediation SLAs and post-fix validation instead of treating patching as a one-time ticket closure.

Risk and Threat Considerations

Active exploitation raises the risk from a conventional vulnerability-management problem to a likely intrusion path. When unauthenticated remote code execution is available in a widely deployed application component, attackers can use it for direct foothold acquisition, lateral movement or follow-on payload delivery without needing valid credentials first.

Failure mechanism: The application accepts attacker-controlled input during deserialisation, reconstructs unsafe objects or gadget chains, and then executes code in the server context before normal access controls can intervene.

Impact: A successful exploit can lead to full application compromise, data access, persistence, and the need to investigate whether any adjacent systems were reached from the compromised host.

Standards & Framework Alignment

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

CIS Controls v8, 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
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE exploitation in the wild requires rapid prioritisation and remediation.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities on an urgent, tracked timeline.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question is about confirmed exploitation and exposure assessment for a specific CVE.
	SI-2 — Flaw Remediation	Active exploitation makes timely remediation and mitigation the central control response.
Recommendation — Scan exposed systems and validate whether the vulnerable component is present. Apply the vendor fix or mitigation as soon as operationally feasible.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	Knowing whether the Oracle ADF Faces component exists is required to judge exposure.
	RS.MA-01 — Incident Management and Mitigation	KEV status implies possible ongoing intrusion activity and containment needs.
Recommendation — Inventory affected assets and confirm where the vulnerable software is deployed. Contain exposed instances and investigate for signs of compromise before returning them to service.

Practitioner Guidance

What to verify: Confirm whether Oracle JDeveloper Distribution or embedded ADF Faces components exist anywhere in your estate, including legacy application servers and forgotten test environments. Then verify whether those instances are externally reachable, because exposure, not just install presence, determines near-term risk.

Decision rule: If a vulnerable instance is internet-facing or reachable from less-trusted networks, treat it as urgent regardless of whether you have seen local alerts. If it cannot be patched immediately, reduce reachability first and hunt for signs of pre-existing compromise before returning it to normal service.

Practitioner takeaway: For KEV-listed RCE flaws, the right question is not whether exploitation is possible, but whether the system has already been exposed long enough to require both containment and compromise assessment.