⚠ Reference material — not professional advice. Test in staging, back up first, verify against your specific version. Use your own judgment for your environment.
● Critical · CVSS 9.0 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2021-45046: Log4j Lookup RCE and Information Disclosure

By Sai Kiran Pandrala

⚡ At a glance
SeverityCVSS 9.0 - Critical (revised upward from 3.7 after RCE was confirmed)
Actively exploited?Yes, listed in CISA KEV (added 2023-05-01). Mass exploitation since December 2021 alongside CVE-2021-44228.
AffectedApache Log4j 2.x before 2.16.0 (Java 8) and before 2.12.2 (Java 7). Includes Log4j 2.15.0, which was the original Log4Shell patch.
Fixed inLog4j 2.16.0 for Java 8, Log4j 2.12.2 for Java 7, Log4j 2.3.1 for Java 6
Type (CWE)CWE-917 Expression Language Injection (JNDI lookup)

Patch immediately. This is the second Log4j CVE. The 2.15.0 release intended to fix Log4Shell turned out to be incomplete in non-default configurations. CISA added it to the Known Exploited Vulnerabilities catalog on 2023-05-01. Any Java application still on 2.15.0 should be treated as vulnerable.

What is CVE-2021-45046?

CVE-2021-45046 is the follow-up vulnerability to CVE-2021-44228 (Log4Shell). The Apache Log4j team shipped 2.15.0 on December 10, 2021 to fix Log4Shell by restricting JNDI lookups to localhost. Researchers then demonstrated that the restriction could be bypassed when the logging configuration used a non-default Pattern Layout containing a Context Lookup (such as ${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, %MDC).

The bypass lets an attacker who controls Thread Context Map (MDC) input data craft a JNDI Lookup payload that triggers remote code execution in some environments and at least local code execution in all environments. The original CVE was scored 3.7 (denial of service only). Apache and NIST revised it upward to 9.0 once RCE was confirmed in the wild.

The fix in 2.16.0 (Java 8) and 2.12.2 (Java 7) goes further than 2.15.0: it removes support for message lookup patterns entirely and disables JNDI by default. That removes the root cause for both Log4Shell and this bypass.

Am I affected?

You are affected if any Java application in your environment ships Apache Log4j 2.x at:

Check every JAR on every host. Log4j is bundled by hundreds of products and inside fat JARs that may not be obvious from package listings.

Find Log4j on Linux:


find / -name "log4j-core*.jar" 2>/dev/null

Find Log4j on Windows PowerShell:


Get-ChildItem -Path C:\ -Recurse -Filter "log4j-core*.jar" -ErrorAction SilentlyContinue

Inspect the version inside a JAR:


unzip -p log4j-core-2.15.0.jar META-INF/MANIFEST.MF | grep -i version

Maven dependency tree on a project:


mvn dependency:tree -Dincludes=org.apache.logging.log4j

Gradle equivalent:


gradle dependencies | grep log4j

How to fix CVE-2021-45046

  1. Inventory every Java application that uses Log4j 2.x. Treat fat JARs and vendor appliances as in-scope until proven otherwise.
  2. Upgrade Log4j to the verified patched version for your Java runtime:

- Java 8 or later: 2.16.0 (or any later 2.x release)

- Java 7: 2.12.2

- Java 6: 2.3.1

  1. For Maven projects, update the dependency:

# Vendor advisory: https://logging.apache.org/log4j/2.x/security.html
   <dependency>
     <groupId>org.apache.logging.log4j</groupId>
     <artifactId>log4j-core</artifactId>
     <version>2.16.0</version>
   </dependency>
  1. For Gradle projects, update build.gradle:

   implementation 'org.apache.logging.log4j:log4j-core:2.16.0'
  1. For vendor-supplied software, apply the vendor's Log4j patch. Do not hot-swap JARs inside vendor products unless the vendor explicitly authorizes it.
  2. Restart every JVM that loaded the old Log4j class. Class reloading is unreliable.
  3. Re-run a Log4j scanner (log4j-scan, logpresso/CVE-2021-44228-Scanner, vendor tools) on the host afterward.

IoC hunt

Because exploitation has been continuous since December 2021, treat every internet-facing Java service as a possible prior victim. Look for:

Rotate any credentials or secrets the Java service had access to.

Update the Java dependency


# The patched Maven / Gradle version is listed in the vendor advisory: https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032
# Maven
mvn versions:set -DnewVersion=<patched-version> -DartifactId=<artifact-id>
mvn clean install

# Gradle
./gradlew --refresh-dependencies build

# Verify the runtime version
java -version


# Vendor advisory: https://logging.apache.org/log4j/2.x/security.html
# Restart the affected Windows service after replacing the JAR
Restart-Service -Name "<service-name>"
Get-Service -Name "<service-name>"

Verify the fix landed


# 1. Confirm the running version matches the fixed-in version from the advisory:
#    https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032
#    Use the platform-specific version probe above.

# 2. Re-scan with your vulnerability scanner (Nessus, Qualys, Tenable, OpenVAS).
#    The scanner should no longer flag CVE-2021-45046 on the patched target.

# 3. Inspect recent service / kernel logs for crash loops or rollback events.
journalctl -u <service> --since "10 minutes ago"
dmesg --since "10 minutes ago"

If you can't patch immediately

Apache's interim mitigation for 2.10 through 2.14.1 was to set log4j2.formatMsgNoLookups=true or remove the JndiLookup class from the classpath. After 2.15.0 was bypassed by this CVE, the official guidance changed: only upgrading to 2.16.0 (Java 8) or 2.12.2 (Java 7) is the verified fix.

If you absolutely cannot upgrade right now:


zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

This removes the JndiLookup class from the JAR. The JVM must be restarted for the change to take effect. Test on a copy first. Vendor warranty implications vary.

Network controls help reduce exposure but do not fix the bug:

How to verify the fix worked

  1. Confirm the loaded Log4j JAR version on each host. Programmatic check inside an application: log LogManager.getRootLogger().getClass().getProtectionDomain().getCodeSource().getLocation() and check the resolved JAR is 2.16.0 or later.
  2. Run a local scanner against the host and confirm CVE-2021-45046 and CVE-2021-44228 both come back clean.
  3. Confirm the JndiLookup class no longer triggers code execution by sending a benign canary string (${jndi:dns://your-canary-domain/test}) into a logged field and verifying no DNS lookup arrives at your canary.
  4. Review the IoC hunt findings. Anything unexplained is an incident-response case, not a checklist tick.

Frequently asked questions

Other vulnerabilities in the same area that are worth patching alongside this one:

I patched to Log4j 2.15.0 in December 2021. Am I safe?

No. 2.15.0 is the build this CVE specifically bypasses. Upgrade to 2.16.0 or later on Java 8, or 2.12.2 on Java 7.

Is this the same as Log4Shell (CVE-2021-44228)?

They are siblings. Log4Shell is the original. CVE-2021-45046 is the bypass of the first fix. Real-world scans usually find both together, and the same upgrade closes both.

Why was the CVSS score raised from 3.7 to 9.0?

The initial advisory described only denial of service. Researchers later demonstrated reliable remote code execution in real configurations, and the score was revised. Treat it as Critical.

Does setting log4j2.formatMsgNoLookups=true fix this CVE?

No. That flag was sufficient for 2.10-2.14.1 against the original Log4Shell. It does not fix CVE-2021-45046 in 2.15.0. The verified fix is the upgrade to 2.16.0 or 2.12.2.

References

*Assembled from the official Apache Log4j security advisory, NVD record, and CISA KEV listing on 2026-05-25. Always confirm against Apache's security page before applying changes in production.*