Apache Log4j2 Deserialization of Untrusted Data

What to do

1. Update Apache Log4j to 2.16.0 or a later version.
2. Update Log4j to 2.12.2 or 2.16.0, whichever matches your release line, or a later version.
3. Update Captial to 2019.1 or a later version.
4. CISA's required action: Apply updates per vendor instructions.
5. Read the advisory on logging.apache.org for workarounds and exact fixed builds.
6. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

Version data comes from the organisation that assigned the CVE; 31 further products are omitted here. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector

NetworkCan be exploited remotely over a network, including the internet.

Attack complexity

HighSuccess depends on conditions outside the attacker's control.

Privileges required

NoneNo account or login is needed.

User interaction

NoneNo action by a victim is required.

Scope

ChangedThe attack can reach beyond the vulnerable component into other systems.

Confidentiality

HighAll data handled by the component can be read.

Integrity

HighData or code can be modified at will.

Availability

HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. Scored by NVD.

Official description

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Neutralization of Special Elements used in an Expression Language Statement

Timeline

1. December 14, 2021CVE record published.
2. May 1, 2023Added to CISA's Known Exploited Vulnerabilities catalogue.
3. May 22, 2023Deadline for US federal agencies to remediate, set by CISA.
4. February 4, 2025CISA published its SSVC assessment (exploitation: active, automatable: no, technical impact: total).
5. June 17, 2026Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in Apache Log4j

• 7.5 High severity

  Apache Log4j: Deserialization of Untrusted Data

  CVE-2023-26464Mar 10, 2023ApacheEPSS 1.91%

Recent Improper Neutralization of Special Elements used in an Expression Language Statement vulnerabilities

• 10.0 Critical severity

  Apache Log4j2 Remote Code Execution Exploited

  CVE-2021-44228Dec 10, 2021ApacheEPSS 100%
• 9.8 Critical severity

  Atlassian Confluence Server and Data Center Object-Graph Navigation Language (OGNL) Injection Exploited

  CVE-2021-26084Aug 30, 2021AtlassianEPSS 100%
• 9.8 Critical severity

  Apache Struts Remote Code Execution Exploited

  CVE-2020-17530Dec 11, 2020ApacheEPSS 96.3%
• 8.8 High severity

  Sonatype Nexus Repository Remote Code Execution Exploited

  CVE-2020-10199Apr 1, 2020SonatypeEPSS 99.1%
• 8.8 High severity

  Red Hat Linux JBoss Seam 2 Remote Code Execution Exploited

  CVE-2010-1871Aug 5, 2010Red HatEPSS 83.4%

Spotted an error? Tell us.