Detects log4j versions on your file-system, including deeply recursively nested copies (jars inside jars inside jars). Works on Linux, Windows, and Mac, and everywhere else Java runs, too!
Currently detects log4j-core versions 2.12.2, 2.15.0 and 2.16.0 as SAFE. All other versions as VULNERABLE (although it does report pre-2.0-beta9 as "POTENTIALLY_SAFE").
Can correctly detect log4j inside executable spring-boot jars/wars, as well as dependencies blended into uber jars and shaded jars.
java -jar log4j-detector-2021.12.14.jar [path-to-scan] > hits.txt
java -jar log4j-detector-2021.12.14.jar /var/tmp/l
/var/tmp/l/log4j-core-2.10.0.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
/var/tmp/l/log4j-core-2.12.2.jar contains Log4J-2.x >= 2.12.2 _SAFE_ :-)
/var/tmp/l/log4j-core-2.14.1.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
/var/tmp/l/log4j-core-2.15.0.jar contains Log4J-2.x >= 2.15.0 _SAFE_ :-)
/var/tmp/l/log4j-core-2.16.0.jar contains Log4J-2.x >= 2.15.0 _SAFE_ :-)
- It currently skips directories / files that current user does not have permission to read. It does not say anything about this.
- It ignores symlinks (and similarly says nothing about this).
We plan to fix both of these issues by December 15th, 2021.
The "!" means the log4j-detector entered a zip archive (e.g., *.zip, *.ear, *.war, *.aar, *.jar). Since zip files can contain zip files, a single result might contain more than one "!" indicator in its result.
Note: the log4j-detector only recursively enters zip archives. It does not enter tar or gz or bz2, etc. The main reason being that Java systems are often configured to execute jars inside jars, but they are never configured to execute other file formats (that I know of!). And so a log4j copy inside a *.tar.gz is probably not reachable for a running Java system, and hence, not a vulnerability worth reporting.
2nd note: for zips-inside-zips our scanner does load the inner-zip completely into memory (using ByteArrayInputStream) before attempting to scan it. You might need to give Java some extra memory if you have extremely large inner-zips on your system (e.g., 1 GB or larger).
java -jar log4j-detector-2021.12.14.jar
Usage: java -jar log4j-detector-2021.12.14.jar [--verbose] [paths to scan...]
Exit codes: 0 = No vulnerable Log4J versions found.
2 = At least one vulnerable Log4J version found.
About - MergeBase log4j detector (version 2021.12.14)
Docs - https://github.com/mergebase/log4j-detector
(C) Copyright 2021 Mergebase Software Inc. Licensed to you via GPLv3.
git clone https://github.com/mergebase/log4j-detector.git
cd log4j-detector/
mvn install
java -jar target/log4j-detector-2021.12.14.jar
GPL version 3.0
The Java compiler stores String literals directly in the compiled *.class files. If log4j-detector detects a file named "JndiManager.class" on your file-system, it then examines that file for this String: "Invalid JNDI URI - {}". Turns out that specific String literal is only present in the patched version of Log4J (version 2.15.0). Any versions of Log4J without that String are vulnerable.
Only versions of Log4J 2.x (from 2.0-beta9 to 2.14.1) are vulnerable to CVE-2021-44228.
Great question! Since we include the complete source code here in Github (all 600 lines of Java), as well as the steps to build it, and since this tool has zero dependencies, it shouldn't take too long to carefully study the code to your satisfaction. If you don't trust Maven you can go directly into the "src/main/java/com/mergebase/log4j" directory and type "javac *.java". That works, too!
MergeBase is an SCA company (Software Composition Analysis) based in Vancouver, Canada. We're similar to companies like Snyk, Sonatype, Blackduck, etc., in that we help companies detect and manage vulnerable open-source libraries in their software. Check us out! We have great accuracy, great language support, and we're not too expensive, either: mergebase.com/pricing