Pete Freitag Pete Freitag

Log4j 1.x Vulnerability Mitigation Guide

Updated: February 08, 2022

Almost every day I see someone asking what to do about log4j 1.2 / 1.x versions. It can be quite a lot of wrap your head around, and it can't be answered easily in a sentence or two. So here's my attempt at providing some clarity and solutions for the millions of applications that are still using Log4j 1.x

TLDR: Apache Log4j 1.x does have vulnerabilities that are unpatched. Many configurations are not impacted by the vulnerabilities by default. Log4j 1.x is EOL so there are no fixed 1.x versions. You can patch the jar files yourself by removing the vulnerable class files. It's not a simple upgrade to go from Log4j 1.x to 2.x in most cases.

Current List of Log4j Security Vulnerabilities

As of December 28, 2021

CVE-2017-5645 published on April 17, 2017

In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

Log4j 2.x Vulnerable: Yes, fixed in version 2.8.2

Log4j 1.x Vulnerable: Yes, see CVE-2019-17571

Mitigating CVE-2017-5645 on Log4j 1.x
  • Upgrade to latest version of log4j 2
  • or remove SocketServer.class and SocketAppender.class from your jar files
  • or ensure you do not run a log4j SocketServer, and your log4j configuration does not use a SocketAppender

Most log4j implementations do not use the SocketServer or the SocketServer appender, you'd have to enable a SocketAppender in your configuration, then start a log4j server like this:

java -classpath log4j.jar 4712

Most log4j implementations are simply writing logs to a file, not distributing logs to another server.

CVE-2019-17571 published on December 20, 2019

Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.

Log4j 2.x Vulnerable: Yes, same as CVE-2017-5645

Log4j 1.x Vulnerable: Yes, all versions no fixed version published

Mitigating CVE-2019-17571 on Log4j 1.x

Same steps as above under CVE-2017-5645.

CVE-2020-9488 published on April 27, 2020

Improper validation of certificate with host mismatch in Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

Log4j 2.x Vulnerable: Yes, fixed in 2.13.2

Log4j 1.x Vulnerable: Yes, all versions no fixed version published

Mitigating CVE-2019-17571 on Log4j 1.x
  • Upgrade to latest version of log4j 2
  • or remove SMTPAppender.class and SMTPAppender$1.class files from your jar files
  • or ensure your log4j configuration does not use a SMTPAppender

CVE-2021-4104 published on December 14, 2021

JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.

Log4j 2.x Vulnerable: No, but similar to CVE-2021-44228

Log4j 1.x Vulnerable: Yes, all versions no fixed version published

Mitigating CVE-2021-4104 on Log4j 1.x
  • Upgrade to latest version of log4j 2
  • or remove JMSAppender.class from your jar files
  • or ensure your log4j configuration does not use JMSAppender

CVE-2021-44228 published on December 10, 2021

Log4j 2.x Vulnerable: Yes, fixed in 2.15.0

Log4j 1.x Vulnerable: Configurations without JMSAppender are Not impacted according to Log4j Security Page, see CVE-2021-4104 above.

CVE-2021-44228 is the very serious / critical Remote Code Execution Vulnerability known as Log4Shell.

CVE-2021-45046 published on December 13, 2021

Log4j 2.x Vulnerable: Yes, fixed in 2.16.0

Log4j 1.x Vulnerable: Not impacted according to Log4j Security Page

DOS, RCE vulnerability.

CVE-2021-45105 published on December 18, 2021

Log4j 2.x Vulnerable: Yes, fixed in 2.17.0

Log4j 1.x Vulnerable: Not impacted according to Log4j Security Page

DOS vulnerability.

CVE-2021-44832 published on December 28, 2021

Log4j 2.x Vulnerable: Yes, fixed in 2.17.1

Log4j 1.x Vulnerable: Not impacted according to Log4j Security Page

RCE when attacker can control log4j configuration.

CVE-2022-23302 published on January 18, 2022

JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to.

Log4j 2.x Vulnerable: No

Log4j 1.x Vulnerable: Yes

CVE-2022-23305 published on January 18, 2022

By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout.

Log4j 2.x Vulnerable: No, Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries.

Log4j 1.x Vulnerable: Yes

This can allow for SQL Injection depending on how the JDBC Appender is configured.

CVE-2022-23307 published on January 18, 2022

CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was included as a component of Apache Log4j 1.2.x where the same issue exists.

Log4j 2.x Vulnerable: No

Log4j 1.x Vulnerable: Yes

Chainsaw is a log viewer GUI that is contained within the java package org.apache.log4j.chainsaw within log4j-1.2.17.jar.

Log4j 1.x Is No Longer Supported

The Apache Log4j 1.2 project page clearly states On August 5, 2015 the Logging Services Project Management Committee announced that Log4j 1.x had reached end of life... Users of Log4j 1 are recommended to upgrade to Apache Log4j 2.

The Log4j Project Maintainers have had their hands full with the issues in Log4j 2, and are understandably not at all interested in doing much to help log4j 1.x users. You'll have to either upgrade to Log4j 2, or get creative.

Is it easy to upgrade from Log4j 1 to Log4j 2?

No, it's not as simply as simply swapping out the jars unfortunately. If that were the case, we would probably have seen a lot more people using v2 that are still on v1.

The Log4j 1.2 Bridge

There is a log4j 1.2 bridge or adapter, which allows software written for Log4j 1.2 to use Log4j version 2 jars instead. I haven't investigated this fully yet, but it looks like for some software you might be able to use this to drop a bunch of jars in the right places. I'll post more info here after I investigate it more.

Checking log4j configuration for vulnerable Appenders

Log4j is very configurable, so you can configure it either from a configuration file, or at runtime. It is much harder to determine what appenders are being used at runtime (you need to review the source code). To review the configuration, search your file system for files containing log4j.appender or any of the following:

  • SocketAppender
  • SMTPAppender
  • JMSAppender
  • JDBCAppender
  • log4j.appender.server
  • log4j.appender.jms

The files may be either a properties file or an XML file, some common log4j configuration file names are:

  • log4j.xml
  • logger.xml
  • logging.xml

If you were using the SocketAppender you might see a hit like this in a file:

For the JMSAppender it might look like this:

And for the SMTPAppender like this:

Removing vulnerable classes from Log4j 1.x jars

In case you were not aware, a jar file is just a zip file, you can use any zip command to operate on them. For example using the command zip -d file.jar 'path/to/ClassName.class' you can remove a class from a jar file on Linux or a Mac.

Important: Make a backup of the jar files first before modifying them, and stop any running servers or java processes first.

To remove the JMSAppender class from a Log4j 1.2.17 jar:

zip -d log4j-1.2.17.jar 'org/apache/log4j/net/JMSAppender.class'

You will see output like this if it works:

deleting: org/apache/log4j/net/JMSAppender.class

If the jar path is incorrect, or it doesn't have the class you will see:

zip warning: name not matched: org/apache/log4j/net/JMSAppender.class

Or if you want to multiple vulnerable classes in one shot:

zip -d log4j.jar 'org/apache/log4j/net/JMSAppender.class' 'org/apache/log4j/net/SocketAppender.class' 'org/apache/log4j/net/SocketServer.class' 'org/apache/log4j/net/SMTPAppender$1.class' 'org/apache/log4j/net/SMTPAppender.class'

To make sure it worked, you can list the files contained in the jar file by running:

jar -tf log4j-1.2.17.jar

Or if you have unzip installed:

unzip -l log4j.jar

If possible, rename your jar file to something like log4j-1.2.17-patched-2021-12-20.jar so that it is more obvious that it was patched. Depending on how your java server or process starts, the jar file path may be in the classpath. Sometimes however all jar files in a directory are loaded into the classpath, so you can name it whatever you want, just be sure to remove the unpatched jars.

Now start your java server, or application again and test to make sure it still works.

Potentially Vulnerable Classes in Log4j 1.2

Here's a table listing the classes you might want to remove from a log4j 1.2 jar file:

Class FileCVE

DISCLAIMER: The content (and links) on this page are provided as is, without warranty of any kind. Use at your own risk. You should consult with your software vendors to ensure that you are properly protected.

Like this? Follow me ↯

Log4j 1.x Vulnerability Mitigation Guide was first published on December 23, 2021.

If you like reading about log4j, java, or security then you might also like:

Want Security Advisories via Email?

Advisory Week is a new weekly email containing security advisories published by major software vendors (Adobe, Apple, Microsoft, etc).


Does Lucee have any problems if we we remove those classes?
by Andrew on 12/23/2021 at 7:56:12 PM UTC
@Andrew - I haven't seen any problems on Lucee with removing the vulnerable classes.
by Pete Freitag on 12/23/2021 at 8:40:34 PM UTC
Thanks for this great page, Pete. Did you have plans to update it for the the new JMSSink, JDBCAppender, or Chainsaw vulnerabilities for Log4j 1.2? (CVE-2022-23302, CVE-2022-23303, and CVE-2022-23305, respectively)
by George on 02/01/2022 at 8:21:56 PM UTC
@George - yes, planning on updating it once I've had a chance to review them properly.
by Pete Freitag on 02/01/2022 at 8:36:25 PM UTC
log4j v1.x reached EOL on Aug. 5, 2015 and in the blog, Apache stated "Users are encouraged to upgrade to Log4j 2". That was almost 7 years ago. As we know in cybersecurity EOL means unsupported and will never fix vulnerabilities after the EOL date. The 3 CVEs associated with v1.x had workarounds, but after the Dec. 9, 2021 announcement, it was less than 30 days before 3 critical CVEs with no mitigation were found in v1.x. Using 1.x more than 6.5 years after EOL was a ticking time bomb and we have detected several new attacks. Future suggestions, when a vendor releases EOL statements, upgrade ASAP. If you are vulnerable, time to remediate is today. If you've been breached, time to remediate was yesterday.
by Bruce Bading on 02/08/2022 at 12:29:05 AM UTC
Hi Pete - I noticed a possible mistake you made. Please correct in your blog post if so. The first is the path to JDBCAppender.class. It should be under the /jdbc folder vs. /net folder. At least that is where I found mine. Secondly, /net/JMSSink.class was notincluded in your list at the bottom. Was that an oversight? It should be included for removal, right?
by Mike on 04/26/2022 at 4:03:02 PM UTC

Post a Comment