I'm obviously worried about this vulnerability, but I wonder if I even have this library on my machine?

The machine is a webserver running a couple of node expressjs frameworks over nginx, plus a geoserver

I patched the machine today with sudo apt update && sudo apt upgrade: ubuntu-advantage-tools, openssl and libssl1.1 were upgraded.

My java version is: openjdk version "1.8.0_292" OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~18.04-b10) OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

The geoserver is v2.13.0 which I believe to be the only program that might use log4j. My geoserver is the platform independent binary version (not the Tomcat version), which uses jetty as its webserver I think.

How can I find out if and what version of log4j I have?

  • 1
    Does pgrep -fa log4j or locate log4j output anything?
    – muru
    Dec 11, 2021 at 10:28
  • Yes! locate log4j gives: /usr/local/geoserver-2.13.0/lib/log4j-1.2.17.jar /usr/local/geoserver-2.13.0/resources/log4j.properties /usr/local/geoserver-2.13.0/webapps/geoserver/WEB-INF/lib/log4j-1.2.17.jar /usr/local/geoserver-2.13.0/webapps/geoserver/WEB-INF/lib/slf4j-log4j12-1.6.4.jar so looks like my geoserver uses it. Thank you. Hmm, what to do?
    – minisaurus
    Dec 11, 2021 at 10:30
  • I found a setting in Geoserver "Number of character to log for incoming POST requests (0 to disable)" and changed it to 0. I have no idea if that will help/do anything?
    – minisaurus
    Dec 11, 2021 at 10:46
  • What vulnerability ?
    – Soren A
    Dec 11, 2021 at 11:10
  • 1
    See ubuntu.com/security/CVE-2021-44228
    – user535733
    Dec 11, 2021 at 14:59

4 Answers 4


You can check if it is installed in apt:

apt list --installed | grep -i log4j

But you still have to also check this to find possible files that might be running somewhere:

locate log4j

Also, it's good to check if you are running java run time on the server:

java -version

If you are not even running the java run time, log4j may not be relevant on this server as it is a java library.

There may be other places to check.


UPDATE: 2021-12-18...

Remember to always check for the latest information from the resources listed below

CVE-2021-45105... 2.16.0 and 2.12.2 are no longer valid remediations! The current fixing versions are 2.17.0 (Java 8) and 2.12.3 (Java 7). All other Java versions have to take the stop gap approach (removing/deleting JndiLookup.class file from the log4j-core JAR.
I have updated my message below accordingly.

Answering the question directly:
Go to Reddit thread: log4j_0day_being_exploited and ctrl+f for .class and .jar recursive hunter. Run the program there, and if it finds anything, remediate.

Then go to the same website and ctrl+f for Vendor Advisories. Search those lists to see if you are running any of the affected software. If you are and an update is available, update.

CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
While most people that need to know probably already know enough to do what they need to do, I thought I would still put this just in case...

  • Follow the guidance in those resources... it may change, but

As of 2021-12-18

It's basically

  • Remove log4j-core JAR files if possible
    • From both running machines for immediate fix AND
    • in your source code / source code management files to prevent future builds / releases / deployments from overwriting the change
  • If that is not possible (due to a dependency), upgrade them
    • If you are running Java 8, then you can upgrade to log4j 2.17.0+
    • If you are running Java 7, then you can upgrade to log4j 2.12.3
    • If you are running an older version of Java, you need to upgrade to the newest version of Java, and then use the newest version of Log4J
    • Again, these changes have to happen both on running machine and in code
  • If neither of those are possible for some reason... then there is the NON-remediation stop gap of removing the JndiLookup.class file from the log4j-core JARs.
    • There is a one-liner for the stop gap option on Linux using the zip command that comes packaged with most Linux distros by default.
      • zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
    • At time of writing, most of the guides online for the stop gap option on Windows say to do the following (again... assuming you can't do one of the remove JAR or upgrade options above):
      • Install something like 7-zip
      • Locate all of your log4j-core JAR files and for each one do the following...
      • Rename the JAR to change the extension to .zip
      • Use 7-zip to unzip the JAR (which now has a .zip extension)
      • Locate and remove the JndiLookup.class file from the unzipped folder
        • The path is \\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
      • Delete the old JAR file (which now has an extension of .zip)
      • Use 7-zip to RE-zip the folder
      • Rename the new .zip folder to change the extension to .jar
    • There are also some options to use Power Shell

This is fine if you only have 1 or 2 JAR files to deal with and you don't mind installing 7-zip or you have PowerShell available to do it. However, if you have lots of JAR files, or if you don't want to install 7-zip and don't have access to Power Shell, I created an open-source VBS script that will do it for you without needing to install any additional software. https://github.com/CrazyKidJack/Windowslog4jClassRemover

Read the README and the Release Notes https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest

  • @muru Thanks for the formatting edit. Is it alright if I make the "UPDATE" part a heading again? Dec 19, 2021 at 8:19
  • Sure, but I personally feel that that first line doesn't add anything as a heading (it is kinda stating the obvious).
    – muru
    Dec 19, 2021 at 8:21
  • Thank you :) I just made the "UPDATE" piece a heading because I want to make sure people see it... especially people that are coming back to this a second time and might otherwise quickly scroll to the specific part they want to reference... I want to ensure they notice it has changed Dec 19, 2021 at 8:25

Be aware that it is only log4j v2 that has this vulnerability. The older log4j v1 is not affected by this vulnerability.

Important, you will not find it in your apt list (as described in the accepted answer) as it would not usually be installed as a stand-alone application or service. log4j is a java logging library used by applications and so it would be installed along with another (Java) application.

You will need to search for the file named log4jv2*.jar anywhere on disk to be certain. locate will do this if installed else sudo find / -iname log4j2*.jar.

Note that some applications also rename the log4j2 JAR files.

Also please be aware as of today (2021-DEC-19) a further vulnerability has been found with Log4J v2 that could allow remote denial of service and everyone that patched to v2.16 should now patch to v2.17.



You can search for log4j:

 find / -type f -name log4*

The output will have log4j related jar files. The most important one is the core files.

Read the README on How to update log4j in ubuntu and Centos

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .