Executive Summary

This vulnerability arises from an incomplete fix for a previous issue (CVE-2025-68161) in Apache Log4j Core. The problem is that hostname verification during TLS connections was only enforced when enabled via a specific system property (log4j2.sslVerifyHostName), but not when configured through the verifyHostName attribute of the <Ssl> element in the configuration.

Although the verifyHostName attribute was introduced in Log4j Core 2.12.0, it was ignored silently in all versions up to 2.25.3. This means that TLS connections using SMTP, Socket, or Syslog appenders with nested <Ssl> elements were vulnerable to man-in-the-middle attacks if an attacker could present a trusted certificate.

The issue does not affect HTTP appenders, which use a different verifyHostname attribute that was not impacted by this bug.

The vulnerability is fixed in Apache Log4j Core version 2.25.4.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow a network-based attacker to perform a man-in-the-middle (MITM) attack on TLS connections established by Log4j appenders (SMTP, Socket, or Syslog) that use the <Ssl> element for TLS configuration.

If the attacker can present a certificate trusted by the appender's trust store or the default Java trust store, they could intercept or manipulate data transmitted over these TLS connections without detection.

This undermines the confidentiality and integrity of the data being logged or transmitted, potentially exposing sensitive information or allowing injection of malicious data.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves improper hostname verification in Apache Log4j Core versions up to 2.25.3 when using SMTP, Socket, or Syslog appenders with TLS configured via the <Ssl> element. Detection involves identifying if your system uses these appenders with TLS and if the Log4j version is affected.

You can check your Log4j Core version to see if it is 2.25.3 or earlier, which are vulnerable.

To detect usage of vulnerable configurations, you may search your application configuration files for SMTP, Socket, or Syslog appenders that use the <Ssl> element with the verifyHostName attribute.

Example commands to assist detection:

• Check Log4j version in your application dependencies or runtime environment, e.g., using command: `mvn dependency:list | grep log4j-core` or inspecting your packaged libraries.
• Search configuration files for usage of SMTP, Socket, or Syslog appenders with SSL configuration: `grep -r '<Ssl' /path/to/config` or `grep -r 'verifyHostName' /path/to/config`.
• Monitor network traffic for suspicious TLS connections that could indicate man-in-the-middle attempts, especially if certificates are presented by unknown or unexpected CAs trusted by your Java trust store.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to upgrade Apache Log4j Core to version 2.25.4 or later, which includes the fix for this vulnerability.

If upgrading immediately is not possible, review your Log4j configuration to ensure that SMTP, Socket, or Syslog appenders are not using TLS with the <Ssl> element and the verifyHostName attribute, or disable these appenders if feasible.

Additionally, ensure that your trust store only contains trusted certificate authorities to reduce the risk of man-in-the-middle attacks.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows a network-based attacker to perform a man-in-the-middle attack on TLS connections used by certain Log4j appenders when hostname verification is not properly enforced. Such interception of data in transit can lead to unauthorized access or disclosure of sensitive information.

Because of this, organizations using affected versions of Log4j Core (prior to 2.25.4) with SMTP, Socket, or Syslog appenders configured with TLS via the <Ssl> element may be at increased risk of data breaches or exposure.

This risk can impact compliance with common security and privacy standards and regulations such as GDPR and HIPAA, which require appropriate safeguards to protect personal and sensitive data, including secure transmission.

Failure to properly verify hostnames in TLS connections could be seen as a weakness in the security controls mandated by these regulations, potentially leading to non-compliance issues if exploited.

Upgrading to Apache Log4j Core 2.25.4 or later, which fixes this issue by correctly enforcing hostname verification, is advised to maintain compliance and reduce security risks.

Useful 0 Not Useful 0