Key facts
Each fact is linked to the source that supports it.- NVD scores CVE-2021-44228 CVSS v3.1 10.0. NIST NVD
- Apache states that applications using only log4j-api without log4j-core are not impacted. Apache Software Foundation
- CISA added the CVE to KEV on 10 December 2021. CISA
Summary
JNDI lookup substitution in log messages and parameters can load attacker-controlled code from a remote endpoint, leading to remote code execution.
Component: Apache Log4j 2 (log4j-core). Disclosed: 10 December 2021. Last verified: 22 October 2026, 16:45 UTC.
Affected versions
| Product | Affected range | Note |
|---|---|---|
| log4j-core | 2.0-beta9 to < 2.3.1 | Apache lists this range; 2.3.1 is the Java 6 fix. |
| log4j-core | 2.4 to < 2.12.2 | Java 7 fix is 2.12.2. |
| log4j-core | 2.13.0 to < 2.15.0 | Java 8+ fix starts at 2.15.0. |
Version ranges preserve the source wording. A distribution package may contain a backport without changing this string. Apache Software Foundation
Fixed versions
| Product | Fixed version | Note |
|---|---|---|
| log4j-core | 2.3.1 | Java 6. |
| log4j-core | 2.12.2 | Java 7. |
| log4j-core | 2.15.0 | Java 8 and later; later releases addressed follow-up issues. |
Use a vendor-supported fixed release. Apache later published follow-up fixes; consult the vendor page rather than stopping at the first fixed version. Apache Software Foundation
Conditions and scope
These are the conditions named by the sources. They are not a score and not a prediction.
- The application uses log4j-core in an affected range.
- Attacker-controlled data reaches a logged message or parameter.
- JNDI lookup substitution is enabled by the configuration or the affected default.
Exploitation status
CISA added CVE-2021-44228 to KEV on 10 December 2021. Exploitation was widespread and is not in dispute.
Present in the downloaded CISA KEV catalog.
Catalog version · checked 22 October 2026, 16:53 UTC · added 2021-12-10.
Severity and scoring
Scores are listed with their version and assessor. Different CVSS versions, and different assessors, are not averaged. The presence of a high score does not establish exploitation, and a lower score does not make a memory-safety defect harmless.
Why it is here
Log4Shell is a historical reference for scale and response, not a claim that PHP2Shell shares its mechanism. Log4j is a Java library; PHP2Shell is a defect in the PHP runtime. The relation on this site is explicitly labelled historical reference.
The comparison is useful in one narrow sense: both show why a dependency inventory that stops at the top-level application misses the component that actually executes attacker-controlled input.
Operational lessons
The original fix was followed by additional advisories and updated versions. 'Upgrade once and close the ticket' is not a reliable pattern for a component with a broad dependency graph. Re-check the vendor page and the exact resolved artefact.
Apache's scope statement is also a reminder to read affected-component wording carefully: log4j-api alone is not the vulnerable component.
What to do
- Verify the serving runtime and the installed fix — useful for any runtime update, not only PHP.
- Interim controls and their limits — how to buy time without claiming a fix.
- Read the advisory labels correctly — CVSS versions, KEV, PoC and exploitation.
Sources
Sources for this record
- Full text read
- Full text read
- Metadata only
Last verified 22 October 2026, 16:45 UTC. A statement that no evidence was found in checked sources is not a statement that an event never occurred.