SecurityTrails Blog · Dec 10 2021 · by German Hoeffner

Critical Log4j Vulnerability Threatens Major Internet Players

Reading time: 2 minutes
Request Access to ASR

The SecurityTrails research team is tracking a critical RCE vulnerability in Apache Log4j which affects many major internet-facing services. Log4j is a Java logging package that’s used in many popular services and utilities. With a CVSS score of 10, this vulnerability (CVE-2021-44228) impacts Apache Log4j versions 2.0-beta9 to 2.14.1 according to Apache.

As of the time of writing, there is not a comprehensive list of software packages that use Log4j that are affected. Attackers are currently spraying the internet with payloads in the User-Agent that attempt to do a remote injection and generate responses to an attacker controlled LDAP server.

SecurityTrails is advising its customers to monitor all internet-facing Java-based apps and servers. For example, Log4j is present in nearly all enterprise-level Apache products and many open source products including ElasticSearch.

Our friends at Greynoise have observed IPs sending payloads trying to identify and/or exploit this vulnerability. You can get a list of the actors from here (continuously updated). Our team is monitoring honeypot data to identify how attackers are progressing.

The dependencies for Log4j run very deep so the attack surface of exploitable software will be also deep. Github lists 1,844 repositories that have dependencies in Github insights here.

Log4j dependency graph

Mitigations: This afternoon, CISA encouraged review of the Apache Log4j 2.15.0 Announcement and upgrade to Log4j 2.15.0 or apply the recommended mitigations immediately.

From the Apache post:

Mitigation: In previous releases (>=2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see protects against RCE by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.

Over the next few days, developers will determine applications that use Apache Log4j that are vulnerable. We’ll post updates here as well as add SecurityTrails ASI detections as information and research becomes available.


Log4j zero-day gets security fix just as scans for vulnerable systems ramp up (The Record)
log4j RCE Exploitation Detection (Github Gist)
Apache Log4j Security Vulnerabilities (
TR-65 - Vulnerabilities and Exploitation of Log4j (
Log4Shell: RCE 0-day exploit found in log4j2 (