Apache release new vulnerability with CVE-2021-44832 and state this vulnerability impact before all version of log4j before 2.17.0. So, please check weather this tool can support it. Thanks. https://logging.apache.org/log4j/2.x/

Can you pl. clarify if PROJECT_DIR is a binary install directory in the readme,

I am hoping it would support both :) i.e. static code analysis and also binary jar dependencies scan

• Add support for ruby scanning
• use both jgem and gem for finding gem cache dirs
• small bug fixes / improvements
• fix windows bug, add error logs when operation fails
• add bundler info to README.md, fix gempath and nil panic bugs

Would be handy to have a machine-parsable version of the output to be able to run this and get JSON back with the list of vulnerable files found. Then it can be consumed by other tools or written out in a report of the user's design.

Something like

log4j-detect.exe -d C:/path --json

By default the Windows "System Volume Information" is locked because Windows uses this folder for certain system-level features. The permissions are set to prevent users—and programs without the appropriate permissions—from tampering with the files inside and interfering with important system functions.

Are you able to please put a flag for the GO binary to ignore this folder? It throws and error. You can reproduce by going to the root level of any Windows drive and running the binary.

log4j-detect scan Scanning F:\ for vulnerabilities... fsWalkErrorFunc error: open F:\System Volume Information: Access is denied.

How do we feel about returning a non-zero exit code from the CLI process when at least one vuln is found? Then this could be used as part of an automated process which would fail when vulns were found without needing to parse the output text and depend on what wording displays. This could be done as the default behavior, or add a command line switch to enable it.

I'd like to use this tool for scanning a server for any vulnerable jars, which could be hiding in any number of places. I'd like to recommend the behavior be modified to

• also look inside of zip files
• also look inside of war files
• also look inside of jar files
• actually scratch all of those-- just recurse into any archive regardless of the extension if possible

For example, I use a lot of fat-jar deployments where I've just got one big WEB-INF/lib/fat.jar on disk that stores other jar files inside of itself for extraction at run time. Note, I don't mean the classes are shaded in, I mean if you unzip far.jar, you've got full jar files sitting inside of it that were packed in as resources. And If the bullets above (which are really all just archives) were recursively scanned, this would make the tool a lot more powerful to be able to see into hidden jar files that may be still tucked away at scan time. A real life example my hard drive right now is

─┬ lucee.zip
 └┬ engine.war
  └┬ WEB-INF/lib/lucee.jar
   ├- bundles/log4j-1.2.17.jar  <-- vulnerable
   └┬ extensions/EFDEB172-F52E-4D84-9CD1A1F561B3DFC8-2.4.1.33.lex
    └─ jars\log4j-1-2-16.jar  <-- vulnerable

Yes, that is a real actual example off my hard drive, and yes that last file is a jar inside a zip (with a .lex extension), inside a jar file, inside a war file, inside a zip file. If we can get this tool recusivley digging all the way down into any archive it comes across, it will find that deep vulnerable jar. As it stand now, I'd have to manually unpack all of those layers myself for the scanner to find it.