[Log4j](https://logging.apache.org/log4j/2.x/) is a widely used Java-based logging library that has been under active development since 1999 by The Apache Software Foundation. Security researchers have found a zero-day vulnerability [CVE-2021–44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) that is actively being exploited in the wild to take control of an affected computer remotely.
In response, the ASF has released a patch and recommends an immediate upgrade to fix the impacted library.
Since Log4j is an embedded library used by many applications in your server and endpoint environments: how do you know your exposure? Here we describe a query you can run using Fleet to get granular and real-time visibility into Log4j installs across your infrastructure.
The Fleet team developed this osquery SQL to detect running processes with Log4J loaded on Linux and macOS systems. Run it as a live query via [Fleet](https://fleetdm.com/) (or any other osquery manager) to quickly detect potential targets within your infrastructure. Thank you to Tim Brown for [creating these YARA queries](https://github.com/timb-machine/log4j).
This query can also be found in Fleet’s osquery [standard query library](https://fleetdm.com/queries/detect-active-processes-with-log-4-j-running).
>Note: This query is resource intensive and has caused problems on systems with limited swap space. Test on some systems before running this widely.
## How it works
The query essentially works in two parts:
1. Find loaded Java JAR files on the system.
2. Use YARA scanning to detect Log4J utilization in those files.
### Find JARs
JARs are found via two mechanisms on the host.
This complex-looking syntax actually just splits the command line arguments for each running process on the system, filtering for any arguments ending in .jar: