No, Apache Isn’t Vulnerable to the Log4j Vulnerability

Updated December 19, 2021

The Log4j Java library has been in the news recently. The details of vulnerability CVE-2021-44228 have been well documented by others, but to summarize, it allows arbitrary code execution through maliciously crafted messages. These messages cause the Java virtual machine to look up classes from an LDAP server and load them. This is obviously not good, but unless you’re familiar with Java, you might be concerned what is and isn’t vulnerable; this article aims to clarify that.

Apache Foundation, not Apache web server

Log4j is a Java library developed by the Apache Software Foundation. The foundation develops a lot of projects, including Log4j and the Apache web server. Apache’s HTTPd (web server) isn’t vulnerable – it’s not written in Java, and thus it can’t use Log4j. However, Log4j is incredibly popular with Java applications. Every grown-up application needs formalized logging, and Log4j provides it very well.

Even if your own applications don’t use Java, it’s possible you might be using products that use Java behind the scenes. A lot of IBM products are written in Java, after all, but it’s very popular for enterprise software.

How do I know if I’m using Log4j?

You might start by reviewing this list of known vulnerable and not vulnerable software.

If you know your application’s classpath (where Java looks for code), look for the logj4 JARs. If they don’t have a version in the filename, you may be able to find a specific version in the META-INF/MANIFEST.MF inside of the JAR (since a JAR is just a Zip file inside). It’s also possible the Log4j JAR may be inside of another JAR file (an uber-JAR).

Only Log4j 2.x is vulnerable. If you’re using Log4j 1.x, you have other problems and should also update it.

Ultimately, if you’re not sure, it doesn’t hurt to ask your vendor. They might have an update out to update Log4j to a fixed version. For example, IBM is taking updates and notices on a product-by-product basis, such as for WebSphere.

Mitigations and solutions

As of this writing, updating to Log4j 2.17 is the best choice. Version 2.15 resolved the most common vulnerability, but 2.16 and 2.17 resolved other rare ones. If, however, you cannot update Log4j right now, perhaps because you are waiting for a vendor’s update, you could try these:

1. A web application firewall (for example, Cloudflare) can try to filter things, but can be inadequate. A filter won’t catch all the different ways the vulnerability can be encoded, especially if it slips by somehow.
2. The latest version of Java disables the exploitable lookups by default by setting com.sun.jndi.ldap.object.trustURLCodebase=false.
3. The setting in 2. above is inadequate, because other ways to trigger the issue have been found. Newer-but-still-vulnerable versions of Log4j (2.10 or newer) allow disabling the lookups. You can set a Java property like Log4j2.formatMsgNoLookups=true (on i, this can also be put into SystemDefault.properties to be set globally) or an environment variable like LOG4J_FORMAT_MSG_NO_LOOKUPS=true.
4. For step-by-step instructions, see the FAQ by IBM’s Jesse Gorzinski.

However, these precautions aren’t silver bullets. The safest option is, again, update as soon as possible, and refer to the official Log4j security fix page for updates.