Security :: Apache Logging Services

The Logging Services Security Team believes that accuracy, completeness and availability of security information is essential for our users. We choose to pool all information on this one page, allowing easy searching for security vulnerabilities over a range of criteria.

Log4cxx: semver scheme
Log4j: maven scheme
Log4net: nuget scheme

For brevity, mathematical interval notation is used, with the union operator (∪) to represent multiple ranges.

CVE-2025-68161

Summary	Missing TLS hostname verification in Socket appender
CVSS 4.x Score & Vector	6.3 MEDIUM (CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N)
Components affected	Log4j Core
Versions affected	`[2.0-beta9, 2.25.3)`
Versions fixed	`2.25.3`

Description

The Socket Appender in Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName configuration attribute or the log4j2.sslVerifyHostName system property is set to true.

This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:

The attacker is able to intercept or redirect network traffic between the client and the log receiver.
The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured).

Remediation

Users are advised to upgrade to Log4j Core version 2.25.3, which fully addresses this issue.

For earlier versions, the risk can be reduced by carefully restricting the trust store used by the Socket Appender.

When configuring a trust store for Log4j Core, we recommend following established best practices. For example, NIST SP 800-52 Rev. 2 (§4.5.2) recommends using a trust store that contains only the CA certificates required for the intended communication scope, such as a private or enterprise CA.

Credits

This issue was discovered by Samuli Leinonen.

CVE-2025-54813

Summary	Improper escaping with JSONLayout
CVSS 4.x Score & Vector	6.3 MEDIUM (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N)
Components affected	Log4cxx
Versions affected	`[0.11.0, 1.5.0)`
Versions fixed	`1.5.0`

Description

When using JSONLayout, not all payload bytes are properly escaped. If an attacker-supplied message contains certain non-printable characters, these will be passed along in the message and written out as part of the JSON message. This may prevent applications that consume these logs from correctly interpreting the information within them.

Remediation

Users are recommended to upgrade to version 1.5.0, which fixes the issue.

Credits

CVE-2025-54812

Summary	Improper HTML escaping in HTMLLayout
CVSS 4.x Score & Vector	2.1 LOW (CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N)
Components affected	Log4cxx
Versions affected	`[0, 1.5.0)`
Versions fixed	`1.5.0`

Description

When using HTMLLayout, logger names are not properly escaped when writing out to the HTML file. If untrusted data is used to retrieve the name of a logger, an attacker could theoretically inject HTML or Javascript in order to hide information from logs or steal data from the user. In order to activate this, the following sequence must occur:

Log4cxx is configured to use HTMLLayout.
Logger name comes from an untrusted string.
Logger with compromised name logs a message.
User opens the generated HTML log file in their browser, leading to potential XSS.

Because logger names are generally constant strings, we assess the impact to users as LOW.

Remediation

Users are recommended to upgrade to version 1.5.0, which fixes the issue.

Credits

CVE-2021-44832

Summary	JDBC appender is vulnerable to remote code execution in certain configurations
CVSS 3.x Score & Vector	6.6 MEDIUM (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Components affected	`log4j-core`
Versions affected	`[2.0-beta7, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.17.0)`
Versions fixed	`2.3.1` (for Java 6), `2.12.3` (for Java 7), or `2.17.0` (for Java 8 and later)

Description

An attacker with write access to the logging configuration can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol.

Mitigation

Upgrade to 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than java.

CVE-2021-45105

Summary	Infinite recursion in lookup evaluation
CVSS 3.x Score & Vector	5.9 MEDIUM (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Components affected	`log4j-core`
Versions affected	`[2.0-alpha1, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.17.0)`
Versions fixed	`2.3.1` (for Java 6), `2.12.3` (for Java 7), and `2.17.0` (for Java 8 and later)

Description

Log4j versions 2.0-alpha1 through 2.16.0 (excluding 2.3.1 and 2.12.3), did not protect from uncontrolled recursion that can be implemented using self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DoS (Denial-of-Service) attack.

Mitigation

Upgrade to 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

Alternatively, this infinite recursion issue can be mitigated in configuration:

In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input. Note that this mitigation is insufficient in releases older than 2.12.2 (for Java 7), and 2.16.0 (for Java 8 and later) as the issues fixed in those releases will still be present.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Credits

Independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein of Trend Micro Research working with Trend Micro’s Zero Day Initiative, and another anonymous vulnerability researcher.

CVE-2021-45046

Summary	Thread Context Lookup is vulnerable to remote code execution in certain configurations
CVSS 3.x Score & Vector	9.0 CRITICAL (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
Components affected	`log4j-core`
Versions affected	`[2.0-beta9, 2.3.1) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.16.0)`
Versions fixed	`2.3.1` (for Java 6), `2.12.3` (for Java 7), and `2.16.0` (for Java 8 and later)

Description

It was found that the fix to address CVE-2021-44228 in Log4j 2.15.0 was incomplete in certain non-default configurations. When the logging configuration uses a non-default Pattern Layout with a Thread Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) can 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. Remote code execution has been demonstrated on macOS, Fedora, Arch Linux, and Alpine Linux.

Note that this vulnerability is not limited to just the JNDI lookup. Any other Lookup could also be included in a Thread Context Map variable and possibly have private details exposed to anyone with access to the logs.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.16.0 (for Java 8 and later).

Credits

This issue was discovered by Kai Mindermann of iC Consult and separately by 4ra1n.

Additional vulnerability details discovered independently by Ash Fox of Google, Alvaro Muñoz and Tony Torralba from GitHub, Anthony Weems of Praetorian, and RyotaK (@ryotkak).

CVE-2021-44228

Summary	JNDI lookup can be exploited to execute arbitrary code loaded from an LDAP server
CVSS 3.x Score & Vector	10.0 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Components affected	`log4j-core`
Versions affected	`[2.0-beta9, 2.3.1) ∪ [2.4, 2.12.2) ∪ [2.13.0, 2.15.0)`
Versions fixed	`2.3.1` (for Java 6), `2.12.2` (for Java 7), and `2.15.0` (for Java 8 and later)

Description

In Log4j, the JNDI features used in configurations, 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.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Mitigation

Log4j 1 mitigation

Log4j 1 has reached End of Life in 2015, and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1 are not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

Log4j 1 does not have Lookups, so the risk is lower. Applications using Log4j 1 are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate, audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1 configurations without JMSAppender are not impacted by this vulnerability.

Log4j 2 mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.2 (for Java 7), or 2.15.0 (for Java 8 and later).

Credits

This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.

CVE-2020-9488

Summary	Improper validation of certificate with host mismatch in SMTP appender
CVSS 3.x Score & Vector	3.7 LOW (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)
Components affected	`log4j-core`
Versions affected	`[2.0-beta1, 2.3.2) ∪ [2.4, 2.12.3) ∪ [2.13.0, 2.13.2)`
Versions fixed	`2.3.2` (for Java 6), `2.12.3` (for Java 7) and `2.13.2` (for Java 8 and later)

Description

Improper validation of certificate with host mismatch in SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack which could leak any log messages sent through that appender.

The reported issue was caused by an error in SslConfiguration. Any element using SslConfiguration in the Log4j Configuration is also affected by this issue. This includes HttpAppender, SocketAppender, and SyslogAppender. Usages of SslConfiguration that are configured via system properties are not affected.

Mitigation

Upgrade to 2.3.2 (Java 6), 2.12.3 (Java 7) or 2.13.2 (Java 8 and later).

Alternatively, users can set the mail.smtp.ssl.checkserveridentity system property to true to enable SMTPS hostname verification for all SMTPS mail sessions.

Credits

This issue was discovered by Peter Stöckli.

CVE-2017-5645

Summary	TCP/UDP socket servers can be exploited to execute arbitrary code
CVSS 2.0 Score & Vector	7.5 HIGH (AV:N/AC:L/Au:N/C:P/I:P/A:P)
Components affected	`log4j-core`
Versions affected	`[2.0-alpha1, 2.8.2)`
Versions fixed	`2.8.2` (for Java 7 and later)

Description

When using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

Mitigation

Java 7 and above users should migrate to version 2.8.2 or avoid using the socket server classes. Java 6 users should avoid using the TCP or UDP socket server classes, or they can manually backport the security fix commit from 2.8.2.

Credits

This issue was discovered by Marcio Almeida de Macedo of Red Team at Telstra.