A new follow-on log4j vulnerability has been discovered and fixed in 2.16.0

Source: https://www.linkedin.com/posts/the-apache-software-foundation_apache-opensource-innovation-activity-6876303520321040384-csOP

A new follow-on #log4j vulnerability has been discovered and fixed in 2.16.0: (CVE-2021-44228 + CVE-2021-45046) following on from my first post regarding the initial exploit and fixed version 2.15.0

TL;DR: You now need to update your #log4j library to 2.16.0

As you would expect, both sides of the community are active. With that, the previous fixed version 2.15.0 and documented mitigations are still vulnerable in specific non-default configurations, such as using the Thread Context value in the log message Pattern Layout. There is a newer version from apache 2.16.0 that you should upgrade to mitigate this. This more recent version completely removes the message lookup feature, which is the critical enabler of this exploit!

Finally, there is tons of information around the recent #log4j exploits, and some are misleading. Perhaps take your cue from an application security company’s blog post like lunasec

Giving this is an evolving situation still I would not post the latest fixes here instead, please see the official Apache security page for an always up to date fix

Example misleading fixes that would not save you from this log4j exploit 🙂 :
– Updating #Java
– #WAF (Web Application Firewall) filtering
– Simply modifying the log statement format to %m{nolookupzz}

Log4J zero-day exploit explained and proposed fixes – a Critical Security Vulnerability (CVE-2021-44228)


There is a new zero-day exploit of the famous log4j library reported and fixed in the latest version, 2.15.0.  In brief, this vulnerability is critical and can give the offender complete server control. For more, please see the Apache Log4j security page.   Everyone in the Java-sphere should be aware of it. Actually, no! Every engineer and information security personnel should take action (looking over to my .net and Javascript buddies who are giggling at another Java security issue and then realising by the end of this post that their Elasticsearch and Atlassian apps are affected). This post will attempt to explain the log4j security exploit, help you determine if you are compromised, how to fix the exploit, and crucially, how to ascertain that you have resolved the log4j security exploit.

The best evidence I have seen so far is that of a little bobby table LinkedIn exploit.

Quick specifics about the log4j-core

  • Log4J: The CVE-2021-44228 vulnerability affects only the log4j-core library.
  • Springboot: The bundle libraries log4j-to-slf4j and log4j-api in spring-boot-starter-logging are not affected according to Spring. Unless of cause you have swapped them out to directly use log4j-core or another logging library that transitively brings it in scope.
  • So far reports seems to suggest applications are only affected when user inputs are logged.
  • PS: Springboot says, v2.5.8 & v2.6.2 releases (due Dec 23, 2021) will contain the fixed Log4J version v2.15.0.

Although the affected versions are anything between 2.0-beta9 and 2.14.1, any beta versions of 2.15.* would be affected.  The most secure/”permanent” fix is to update your log4j library to 2.15.0 immediately.  Please see Maven Central and log4j security announcements or carry on reading. 

Am I affected?

Anyone running Java is affected.  With the assumption that you would have something at least in your application’s transitive dependencies that bring in log4j if you are not using it directly.  Best to assume you have it and act accordingly.  In practice, any java application that takes in a user input that may end up in a log is affected given that log4j is ubiquitous in the java community! 

How to tell which version of Log4J library I have

You can use your dependencies managers like Maven or Gradle to print out all your dependencies and their versions to verify what version of Log4J you have.

For example, for Gradle:

# execute, logging out only the log4j dependency lines
./gradlew dependencies | grep “log4j”

Also, note you can right-click on your pom.xml or build.gradle file in popular IDEs like IntelliJ then chose to “generate visual dependency graph” / “effective dependency”

How to fix the log4J zero-day secuirty exploit

Example fix of the Log4j zero day exploit for Maven

# Override the log4j dependency of a Springboot project

# And then verify the override works
./mvnw dependency:list | grep log4j

Example fix of the log4j zero day exploit for Gradle

# Via gradle's platform support add

# or for those with Springboot simply set the log4j's version
ext['log4j2.version'] = '2.15.0'

# And then verify the override works
./gradlew dependencyInsight --dependency log4j-core

Where upgrading the dependency is not possible

A workaround exists for some versions, such as releases >=2.10, by setting either the system property log4j2.formatMsgNoLookups or any of the following:

# In the JVM.Options file, add this:
# or set the environment variable:  LOG4J_FORMAT_MSG_NO_LOOKUPS=true
# or simply run the application with (you may need to add quotes, depending on your shell . i.e "true")
java -Dlog4j2.formatMsgNoLookups=true -jar myapplication.jar

Popular applications affected by the log4J critical vulnerability

If you think you are not affected, have a look at this flavour of applications that would be affected:

  • Libraries:
    • Spring Boot
    • Struts
  • Apps
    • Solr
    • ElasticSearch
    • Kafka
    • Logstash
    • Jira
    • Confluence
    • Stash
    • Bamboo
    • Crowd
    • Fisheye
    • Crucible 
  • Server:
    • Steam
    • Apple iCloud
    • Minecraft

Yes, that’s almost any good Java application out there…

As a final reminder, this vulnerability is classed as critical by Apache.  Apache describes a Critical vulnerability as one “which a remote attacker could potentially exploit to get Log4j to execute arbitrary code (either as the user the server is running as or root). These are the sorts of vulnerabilities that could be exploited automatically by worms”.  Here are additional resources for you on the recent Log4J security vulnerability: