This content has average runtimes in our environment of 1-2s without running anything in the background past the completion of the fixlet.
This content takes a different approach from most others. It is likely to produce false negatives (it is not a perfect detection mechanism) but hopefully minimizes false positive. The most vulnerable systems are systems running java-based servers (web servers, background servers, etc) and not java-based desktop apps. If the JAR hasn’t been fat-packed then each JAR will be an open file handle by the java process. We can use this information to look for java processes, see if Log4j is present and then report the version of Log4j present.
This content does not recursively open JAR files, does not find JAR files not in use on the system, does not find JAR files by their hashes, and may miss beta versions of the Log4j JARs. For that functionality seek out a heavier handed solution like logpresso.