
Fastest filesystem scanner for log4shell (CVE-2021-44228, CVE-2021-45046) and other vulnerable (CVE-2017-5645, CVE-2019-17571, CVE-2022-23305, CVE-2022-23307 ... ) instances of log4j library. Excellent performance and low memory footprint.

Python port of https://github.com/mergebase/log4j-detector log4j-detector is copyright (C) Copyright 2021 Mergebase Software Inc. https://mergebase.com/ Licensed via GPLv3.
Motivation for porting to Python was to improve perfomance, reduce memory consumption and increase code readability. See below section about performance comparism.
And it seems this is the fastest scanning tool with lowest memory requirement
Identifies log4j (1.x), reload4j (1.2.18+) and log4j-core (2.x) versions on your file-system vulnerable to CVE-2021-44228, CVE-2021-45046 and many others - see table below. It is able to find instances embedded in larger applications several layers deep. Works on Linux, Windows, Mac or anywhere else Python 3.8+ runs.
Can correctly detect log4j inside executable spring-boot jars/wars, dependencies blended
into uber jars, shaded jars, and even
exploded jar files just sitting uncompressed on the file-system (aka *.class).
It can also handle shaded class files - extensions .esclazz (elastic) and .classdata (Azure).
Java archive extensions searched: .zip, .jar, .war, .ear, .aar, .jpi,
.hpi, .rar, .nar, .wab, .eba, .ejb, .sar, .apk, .par, .kar
| Detects | CVE | CVSSv3 | Severity | Java | Vuln from | Vulnerable to | Fixed in | library |
|---|---|---|---|---|---|---|---|---|
| YES | CVE-2021-44228 | 10.0 | Critical | 8 | 2.0-beta9 | 2.14.1 | 2.15.0 | log4jv2 |
| YES | CVE-2017-5645 | 9.8 | Critical | 7 | 2.0-alpha1 | 2.8.1 | 2.8.2 | log4jv2 |
| YES | CVE-2019-17571 | 9.8 | Critical | 1.2.0 | 1.2.17 | nofix | log4jv1 | |
| YES | CVE-2021-45046 | 9.0 | Critical | 7/8 | 2.0-beta9 | 2.15.0 excluding 2.12.2 | 2.12.2/2.16.0 | log4jv2 |
| YES | CVE-2022-23305 | 9.8 | Critical | 1.2.0 | 1.2.17 | nofix / 1.2.18.1 | log4jv1, reload4j | |
| YES | CVE-2022-23307 | 9.8 | Critical | 1.2.0 | 1.2.17 | nofix / 1.2.18.1 | log4jv1, reload4j | |
| YES | CVE-2022-23302 | 8.8 | High | 1.0 | 1.2.17 | nofix / 1.2.18.1 | log4jv1, reload4j | |
| YES | CVE-2021-4104 | 7.5 | High | - | 1.0 | 1.2.17 | nofix | log4jv1 |
| YES | CVE-2021-44832 | 6.6 | Medium | 6/7/8 | 2.0-alpha7 | 2.17.0, excluding 2.3.2/2.12.4 | 2.3.2/2.12.4/2.17.1 | log4jv2 |
| - | CVE-2021-42550 | 6.6 | Medium | - | 1.0 | 1.2.7 | 1.2.8 | logback |
| YES | CVE-2021-45105 | 5.9 | Medium | 6/7/8 | 2.0-beta9 | 2.16.0, excluding 2.12.3 | 2.3.1/2.12.3/2.17.0 | log4jv2 |
| - | CVE-2020-9488 | 3.7 | Low | 7/8 | 2.0-alpha1 | 2.13.1 | 2.12.3/2.13.2 | log4jv2 |
Each instance is reported with apropriate list of CVEs. For each CVE log4j library file is being analyzed whether the recommended workarounds (e.g. JndiLookup.class or JMSAppender.class removed) has been applied and in that case is considered as non-vulnerable. Status STRANGE is reported for archives with log4j-core pom.properties file, but without actual bytecode classes, ususally those are source packages and can be ignored.
Warning
--fixfeature is experimental, use it on your own risk, make sure you backup your jar files prior using it.
Argument --fix attempts to rename instances of JndiLookup.class into JndiLookup.vulne, thus preventing the class
from loading. Within Java archives it's done via in place rename, does not require re-zipping of the archive and is
instant fast.
Binaries are available for Linux 64bit, MS Windows 64bit and 32bit - see Releases
Minimum supported Python version is 3.8. According to my testing Python 3.6 zip implementation cannot open many
.jarfiles from my test data.
log4shell finder is optimized for performance and low memory footprint.
Updated on 23.1.2022, performance measured on a directory with 26237 files in 2005 folders.
Runtime reduced by half, memory consumtion by 2/3, file system reads byt at least 90%
Command being timed: "./test_log4shell.py /home/hynek/war/ --exclude-dirs /mnt --same-fs"
User time (seconds): 17.68
System time (seconds): 1.20
Percent of CPU this job got: 127%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:14.47
Maximum resident set size (kbytes): 64144
File system inputs: 114424
Command being timed: "./log4j-finder.py /home/hynek/war/"
User time (seconds): 23.59
System time (seconds): 1.09
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:26.18
Maximum resident set size (kbytes): 38604
File system inputs: 142824
Command being timed: "java -jar log4j-detector-latest.jar /home/hynek/war"
User time (seconds): 30.56
System time (seconds): 1.39
Percent of CPU this job got: 113%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:28.26
Maximum resident set size (kbytes): 214116
File system inputs: 14416
Command being timed: "./log4j2-scan /home/hynek/war --scan-log4j1 --scan-zip"
User time (seconds): 52.05
System time (seconds): 25.32
Percent of CPU this job got: 88%
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:27.86
Maximum resident set size (kbytes): 593080
File system inputs: 215416
all parameter--no-csv-header to omit csv header to allow easier merging of results from multiple hosts--threads parameter to manually tune number of scanning threads--cvs-clean parameter in order to write "CLEAN" line to csv output in case no log4j library detected--cvs-stats parameter in order to write "STATS" line to csv output with runtime in seconds and number of files and folders scanned--fix command in version 1.19 and 1.20 could corrupt .jar archives.For previous changes see Release Notes
Either run from a python interpreter or use the Windows/Linux binaries from the dist folder.
Beware to run it as a user with access (at least read-only) to the whole filesystem. log4shell-finder traverses just folders it can access to, not reporting permission denied errors.