Critical Remote Code Execution in Apache Log4j2 (CVE‑2021‑44228) Enables Unauthenticated JNDI Exploits
What It Is — Apache Log4j 2.0‑2.15 contains a flaw in its JNDI lookup feature that allows an attacker‑controlled JNDI endpoint to trigger remote code execution. The vulnerability (commonly called “Log4Shell”) is publicly disclosed, has a CVSS 3.1 base score of 10.0, and has been weaponised in the wild.
Exploitability — Exploits are publicly available; attackers can trigger RCE simply by sending a crafted string to any logging call that processes attacker‑supplied data. No authentication is required.
Affected Products — The Apache Log4j 2 library, embedded in countless Java‑based applications, middleware, and cloud services (e.g., Apache Struts, Elasticsearch, Minecraft servers, many SaaS platforms).
Why It Matters for Trust & Control Assurance
- Demonstrates the need for a robust vulnerability‑management control that ensures timely identification, risk‑based prioritisation, and remediation of critical flaws.
- Highlights the importance of continuous evidence collection (patch status, configuration baselines) to prove due‑diligence during audits.
- Serves as a concrete test of the control objective “Maintain up‑to‑date software and secure configurations,” which maps to multiple frameworks (NIST CSF, ISO 27001, PCI DSS, etc.).
Recommended Actions
- Inventory all assets that include Log4j 2 and determine the exact version in use.
- Apply the Apache‑provided patches (upgrade to 2.17.1 or later) or implement the recommended mitigations (e.g., disable JNDI, set
log4j2.formatMsgNoLookups=true). - Update your vulnerability‑management process to capture this class of library‑level risk and retain remediation evidence.
- Deploy runtime monitoring to detect unexpected outbound LDAP/RMI calls indicative of exploitation attempts.
- Document the remediation steps in your audit trail to satisfy control‑assurance requirements.
Source: CISA KEV – CVE‑2021‑44228