Is CVE-2021-44228 (Apache Log4j2 Remote Code Execution) being exploited in the wild?

What “exploited in the wild” means for this CVE

For this vulnerability, the practical question is not whether the flaw exists, but whether attackers were already using it against real systems. CISA’s KEV inclusion is the strongest public signal that exploitation is not theoretical. That matters because once a CVE lands in KEV, defenders should treat exposure as an active incident-response problem, not a routine patch queue item.

When a vulnerability supports remote code execution, active exploitation usually means attackers can move from a vulnerable service to command execution on the host, then use that foothold for persistence, lateral movement, or data theft. In that sense, the issue is as much about blast radius as about the initial bug.

For a broader response model, the Zero-Day and Exploited Vulnerabilities Guide is useful because it frames KEV-driven triage, emergency mitigation and post-patch hunting as one workflow rather than separate tasks.

Why Log4j2 made this vulnerability unusually dangerous

Log4j2 sits deep inside many Java applications, so exposure is often hidden behind normal application traffic and shared platform dependencies. That means teams can be affected even when they do not run Log4j2 as a consciously managed product. The operational problem is discovery: if you do not know where the library is embedded, you cannot confidently say whether you are exposed.

The vulnerability type also makes exploitation scalable. Remote code execution flaws are attractive because they can be weaponised quickly, embedded into scanning and mass-exploitation campaigns, and chained into broader intrusion activity. In practice, that means internet-facing services are only one concern; internal applications, build tools and middleware can also be entry points if they process untrusted input.

When organisations are still mapping exposure, a Vulnerability Management Guide helps because it ties asset scope, prioritisation and verification to the remediation workflow instead of stopping at scan results.

For a vendor-adjacent technical reference, the NIST National Vulnerability Database and the CVE Program remain the authoritative places to confirm the record, metadata and identifier state.

What to do if you still cannot patch immediately

If patching is delayed, the goal is to reduce reachable attack surface and gather evidence fast enough to decide whether the environment has already been touched. That usually means constraining exposure paths, disabling or restricting the risky code path where the vendor allows it, tightening egress, and increasing monitoring around the vulnerable service and its dependent hosts.

Teams should also assume that exposure may already have been used, especially when the service was reachable from the internet or from untrusted internal networks before mitigation. A short delay in patching is not unusual; a long delay without compensating controls is where the risk becomes unacceptable.

The CISA Known Exploited Vulnerabilities Catalog is the best public prioritisation reference for deciding whether the issue belongs in emergency remediation rather than normal maintenance windows. For exploit likelihood context, FIRST EPSS can complement KEV by showing how likely exploitation is across the broader population of vulnerabilities.

Risk and Threat Considerations

Active exploitation changes the threat model from “possible vulnerability” to “likely attacker opportunity.” For an RCE issue in a ubiquitous library, the main risks are rapid mass scanning, opportunistic compromise of exposed services, and secondary abuse after the initial foothold, including credential theft, persistence and lateral movement.

Failure mechanism: attacker-controlled input reaches the vulnerable logging path, the application follows a harmful resolution path, and the attacker gains code execution on a system that was assumed to be safe because the application itself looked ordinary.

Impact: once code execution is possible, the compromise can extend well beyond the original application, especially if the host has access to secrets, service credentials, internal APIs or trusted network segments.

Practitioner Guidance

What to prioritise: treat KEV-listed RCEs as exposure-confirmation problems first, patching problems second. Identify where the library is present, where the service is reachable, and whether the host can access sensitive internal resources.

What to verify: confirm whether the vulnerable component was reachable before remediation, whether any abnormal child processes, outbound connections or new files appeared near the exposure window, and whether adjacent systems show signs of credential or session reuse.

Decision rule: if you cannot patch immediately, reduce reachability and increase logging now, then move straight to compromise assessment. Do not wait for positive evidence of abuse before treating the environment as potentially impacted.

Practitioner takeaway: for a KEV-listed remote code execution flaw, the right question is not “is it exploitable,” but “where was it reachable, and what could an attacker have accessed if they got code execution?”

Related resources from NHI Mgmt Group

• CVE-2021-44228 (Apache Log4j2 Remote Code Execution)
• Is CVE-2021-1647 (Microsoft Defender Remote Code Execution) being exploited in the wild?
• Is CVE-2021-39144 (XStream Remote Code Execution) being exploited in the wild?
• Is CVE-2021-31166 (Microsoft HTTP Protocol Stack Remote Code Execution) being exploited in the wild?