CVE-2021-44228 is a remote code execution vulnerability in Apache Log4j2. CISA added it to the Known Exploited Vulnerabilities catalogue on 10 December 2021, which means attackers have used it in real attacks. Apache Log4j2 contains a vulnerability where JNDI features do not protect against attacker-controlled JNDI-related endpoints, allowing for remote code execution.
What makes Log4j2 remote code execution dangerous
Log4j2 remote code execution is dangerous because a logging library can become an execution path, not just a record-keeping component. When untrusted input reaches a vulnerable lookup path, an attacker may turn routine application traffic into code execution inside the target process, which is why this class of flaw is often treated as a high-priority exposure rather than a narrow software bug.
The practical concern is that logging sits deep in many application stacks, so the vulnerable component may be present in services that never intentionally expose an admin interface or upload feature. That makes exposure discovery harder and increases the chance that the issue exists in places teams do not immediately think to inspect.
How organisations assess exposure
Exposure checks should start with asset inventory, application dependency review, and internet-facing service mapping, because the question is not only whether Log4j2 exists somewhere, but where attacker-controlled input can reach it. Organisations should then compare their inventory against vendor advisories and the NIST National Vulnerability Database and CVE Program records for authoritative identification and remediation references.
Because exploitation often depends on application behavior as much as package presence, teams should also test whether externally supplied strings are processed by logging, templating, or lookup features before assuming a host is safe. A clean software bill of materials helps, but it is not enough on its own if embedded copies, shaded jars, or third-party products still carry the vulnerable code path.
Remediation and compensating controls
The preferred fix is vendor remediation, but until patching is complete, organisations should reduce exposure by limiting untrusted input paths, constraining outbound network access from affected services, and isolating systems that handle untrusted traffic. Those controls do not remove the flaw, but they can break the chain that turns a lookup into execution.
Where immediate patching is not possible, temporary safeguards should be treated as time-bound risk reduction, not as a permanent substitute. Organisations can use the broader vulnerability management discipline described in the Vulnerability Management Guide to prioritise KEV-listed issues, confirm remediation, and verify that compensating controls are actually effective.
Detection and post-exploitation review
Detection should focus on signs that the vulnerability was used before the fix landed, not just on whether the patch is now installed. Review logs for unusual outbound lookups, unexpected process launches, suspicious class loading, and strange child processes spawned by the affected application, because remote code execution usually leaves behavioral traces even when the original payload is transient.
After remediation, organisations should review the affected host for persistence, credential exposure, and lateral movement opportunities. If an attacker gained code execution in an application process, assume that session data, service credentials, environment variables, and other reachable secrets may need to be rotated or reissued.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Log4j2 RCE is an exploited application entry point. |
| Recommendation — Map exposure to T1190 and hunt for public-facing exploitation attempts. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The term centers on urgent remediation of a known exploitable software flaw. |
| Recommendation — Track remediation and verification under SI-2 for affected systems. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This vulnerability requires inventory, prioritisation, patching and verification. |
| Recommendation — Prioritise the CVE under CIS-7 and validate remediation across all exposed assets. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | The subject directly concerns identifying, prioritising and remediating a known vulnerability. |
| Recommendation — Use PR.IP-12 to drive vulnerability remediation and validation for affected services. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The flaw arises from unsafe handling of untrusted input in application design. |
| Recommendation — Review application architecture and input handling under V15 to prevent unsafe execution paths. | ||