Log4Shell, CVE-2021-44228, is a critical vulnerability disclosed in December 2021 in affected versions of Apache Log4j Core. Under vulnerable conditions, processing attacker-controlled logged data can lead to remote code execution through JNDI lookups. The presence of Java or a Log4j filename alone does not establish exploitability.
What is Log4j?
Log4j is a Java logging framework. It can be a direct dependency or be bundled inside another application, archive, appliance or vendor product. An organisation therefore needs to assess deployed software as well as its own source repositories.
Affected versions and historical fixes
Apache lists the affected versions and conditions for each CVE in its security advisories. Log4j 1.x is not affected by this particular Log4Shell CVE, but it reached end of life in 2015 and has separate security issues.
Versions 2.17.1, 2.12.4 and 2.3.2 belong to the historical 2021 remediation sequence for different Java branches. They are not a current blanket recommendation or a guarantee against later Log4j vulnerabilities. The early 2.15.0 release was also followed by additional fixes for related issues.
How to assess exposure
- Inventory applications and obtain the vendor’s advisory for the exact product and build.
- Review dependency manifests, software composition analysis and deployed packages, including nested archives, containers and bundled copies.
- Check the actual runtime components and configuration. A clean top-level dependency file does not establish that every deployed copy was replaced.
- Use authorised, controlled assessment methods. Tests that trigger outbound callbacks can expose information or affect a service, so agree the scope and method first.
Remediation
Use a currently maintained Log4j release compatible with the application and Java runtime, or the vendor-supported product update. Consult Apache’s current security advisories and maintenance policy at the time of deployment. Review release notes, test compatibility, align the relevant Log4j components and verify the versions actually running after deployment.
Where a vendor product bundles Log4j, follow that vendor’s supported procedure. Manually replacing a JAR or removing a class can break software, invalidate support or miss another bundled copy. Old JVM flags and class-removal instructions are version-dependent emergency measures, not a universal remediation procedure.
Network restrictions, monitoring and WAF rules may reduce exposure while an update is prepared. They do not replace a supported fix or prove that exploitation is impossible.
Investigation and follow-up
Look for suspicious logged input, unexpected outbound activity and changes to accounts, scheduled tasks or other persistence mechanisms. A logged payload can indicate an attempt without proving successful execution; absence of a known pattern does not prove the system was unaffected. If compromise is suspected, preserve evidence and use an incident-response process.
Keep an owner and update process for third-party software. Remediation of the 2021 CVE does not close the need to track new advisories and remove unsupported runtime dependencies.
References: Apache Logging Services security advisories and Log4j versioning and maintenance policy. Technical review: 30 October 2026.
