Is CVE-2021-45046 (Apache Log4j2 Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2021-45046 to its Known Exploited Vulnerabilities catalogue on 1 May 2023, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Apache Log4j2 contains a deserialization of untrusted data vulnerability due to the incomplete fix of CVE-2021-44228, where the Thread Context Lookup Pattern is vulnerable to remote code execution in certain non-default configurations.

What the Log4j2 finding means for exposure and verification

For practitioners, the key question is not whether the CVE exists, but whether any reachable Log4j2 instance still has the vulnerable condition in scope. Because CISA has already placed it in the KEV catalogue, treat it as an exposure problem first, then a patching problem. Confirm where Log4j2 is embedded, whether the vulnerable code path is reachable, and whether compensating controls were only assumed rather than verified.

When teams need a structured way to separate noisy inventory from actionable exposure, Zero-Day and Exploited Vulnerabilities Guide is the fastest path to KEV-style triage and emergency response logic. For the underlying vulnerability mechanics, Insecure Deserialisation Guide is the more precise conceptual match because the issue is a deserialization of untrusted data path leading to remote code execution in certain configurations.

In practice, confirmation should include version and deployment discovery, dependency mapping, and a check for places where Log4j2 is bundled inside vendor products or internal services. If the application team says “we already patched the app,” verify the library actually changed in the runtime artifact, container image, or appliance image that is deployed.

How to handle patching, mitigation, and delay

The safest response is to apply the vendor fix or documented mitigation as soon as possible, then validate that the vulnerable behavior is no longer reachable. If patching must wait, reduce exposure by disabling or constraining the affected feature path, narrowing network reachability, and placing the system under heightened monitoring until remediation is complete. Do not treat a change ticket as proof of risk reduction.

For operational prioritisation across a larger environment, Vulnerability Management Guide supports the workflow that matters here, asset scoping, KEV-driven prioritisation, exceptions, verification, and metrics. Where the practical issue is emergency response to an actively exploited flaw, the same guide helps teams decide whether to patch, isolate, or accept a short-lived exception with explicit owner accountability.

If the vulnerable component sits in a service that cannot be taken down quickly, the decision point is whether the compensating control actually blocks exploitability or only reduces the odds. In that case, mitigation should be treated as temporary risk reduction, not closure. The remediation record should show what was changed, what evidence proved the change, and when the temporary control expires.

What to check after possible exploitation

Because this CVE is associated with active exploitation, remediation should be paired with a compromise assessment. Review logs, command execution traces, outbound connections, unusual child processes, and any evidence that the application or host was used as an initial execution point. If you patched first and investigated later, still assume the window before remediation may have been abused.

The important practitioner distinction is between blocking future exploitation and proving the system was never touched. Those are different tasks. Even where no obvious anomaly appears, look for signs of staging, persistence, credential access, or lateral movement on the affected host and its adjacent services.

Risk and Threat Considerations

Actively exploited deserialization flaws are attractive because they can turn a single request into code execution, and code execution often becomes the first step in broader intrusion activity. When the vulnerable component is internet-facing or reachable from semi-trusted internal paths, the attack surface is wider than the application team usually expects.

Failure mechanism: The attacker sends crafted input that reaches the vulnerable Log4j2 code path, causing the application to process untrusted data in a way that can result in remote code execution in the affected configuration.

Impact: Successful exploitation can lead to application takeover, follow-on payload delivery, credential theft, internal reconnaissance, and use of the host as a foothold for lateral movement or ransomware staging.

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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require inventory, prioritisation and verification of remediation.
Recommendation — Prioritise KEV-listed flaws for rapid remediation and validate closure with rescans.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Documented	This CVE response depends on identifying vulnerable Log4j2 exposure across assets and dependencies.
	RS.MA-1 — Incidents are managed	Active exploitation requires containment, remediation and coordinated response actions.
Recommendation — Identify affected assets and document where the vulnerable Log4j2 path remains reachable. Contain suspected exploitation and coordinate remediation with incident response.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	CVE remediation is fundamentally a flaw-remediation control problem.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and post-fix validation rely on scanning and monitoring vulnerable assets.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-exploitation review depends on log analysis for signs of abuse.
Recommendation — Remediate the vulnerable component and verify the fix in the deployed environment. Scan for exposed instances and recheck them after mitigation or patching. Review relevant logs for exploit attempts and suspicious activity after exposure.

Practitioner Guidance

What to verify: Do not trust a software bill of materials alone. Verify the deployed artifact, not just the source tree, because Log4j2 may appear through transitive dependency chains, embedded packages, or vendor appliances.

Decision rule: If the affected component is reachable and you cannot prove the fix is present, treat the system as exposed until evidence says otherwise. If the component may have executed attacker-controlled input before remediation, prioritize investigation and containment alongside patching.

Practitioner takeaway: For a KEV-listed flaw, the right question is whether exploitation was possible and whether compromise evidence exists, not whether the team believes the application “should have been safe.”