CVE-2026-34477: Apache Log4j TLS Bypass Vulnerability

CVE-2026-34477 Overview

CVE-2026-34477 is a certificate validation bypass vulnerability in Apache Log4j Core that represents an incomplete fix for CVE-2025-68161. The vulnerability occurs because hostname verification was only enforced when enabled via the log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName attribute of the <Ssl> element in Log4j configuration files.

Although the verifyHostName configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value. This allows network-based attackers to potentially perform man-in-the-middle attacks against applications using vulnerable Log4j appenders.

Critical Impact

Network attackers can intercept TLS-encrypted log traffic through man-in-the-middle attacks when SMTP, Socket, or Syslog appenders are configured with SSL/TLS, potentially exposing sensitive application data transmitted in log messages.

Affected Products

• Apache Log4j Core versions 2.12.0 through 2.25.3
• Applications using SMTP, Socket, or Syslog appenders with TLS configured via <Ssl> element
• Systems where verifyHostName attribute is relied upon for hostname verification

Discovery Timeline

• 2026-04-10 - CVE CVE-2026-34477 published to NVD
• 2026-04-13 - Last updated in NVD database

Technical Details for CVE-2026-34477

Vulnerability Analysis

This vulnerability (CWE-297: Improper Validation of Certificate with Host Mismatch) stems from an incomplete security fix in Apache Log4j Core. The original vulnerability CVE-2025-68161 was partially addressed, but the patch failed to account for an alternative configuration method.

The root issue is that Log4j Core supports two methods for enabling hostname verification in TLS connections: the log4j2.sslVerifyHostName system property and the verifyHostName XML attribute within <Ssl> configuration elements. The previous fix only addressed the system property path, leaving the XML attribute configuration completely non-functional.

When the verifyHostName attribute is set to true in the SSL configuration, Log4j silently ignores this setting and proceeds with TLS connections without verifying that the server's certificate hostname matches the expected destination. This creates a false sense of security for administrators who believe they have properly configured hostname verification.

Root Cause

The vulnerability exists because the hostname verification logic in Log4j Core's SSL implementation contains a code path that only checks the log4j2.sslVerifyHostName system property. The verifyHostName attribute from the <Ssl> XML element is parsed but never actually used to enable hostname verification during TLS handshakes. This represents a classic case of dead code where configuration is accepted but not honored, creating a dangerous security gap.

Attack Vector

A network-based attacker can exploit this vulnerability by performing a man-in-the-middle attack when all of the following conditions are met:

1. An SMTP, Socket, or Syslog appender is in use
2. TLS is configured via a nested <Ssl> element
3. The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured

The attacker positions themselves between the application and the log destination, presenting a valid certificate for a different domain. Because hostname verification is not enforced, the Log4j appender accepts the mismatched certificate and establishes the TLS connection with the attacker's system, allowing interception of all logged data.

Note: The HTTP appender is not affected as it uses a separate verifyHostname attribute that was not subject to this bug and verifies hostnames by default.

Detection Methods for CVE-2026-34477

Indicators of Compromise

• Review Log4j configuration files for <Ssl> elements using the verifyHostName attribute without the corresponding system property
• Check for unexpected TLS certificate warnings or errors in application logs that may indicate MITM attempts
• Monitor network traffic for TLS connections to log destinations that show certificate hostname mismatches

Detection Strategies

• Audit all Log4j Core versions in use across the environment to identify instances of 2.12.0 through 2.25.3
• Scan configuration files for SMTP, Socket, and Syslog appenders that include <Ssl> configuration elements
• Implement network monitoring to detect certificate anomalies on connections to logging infrastructure
• Use software composition analysis (SCA) tools to identify vulnerable Log4j Core dependencies

Monitoring Recommendations

• Enable verbose TLS logging in Java applications to capture certificate verification details
• Deploy network intrusion detection systems (NIDS) to monitor for potential MITM attacks on logging traffic
• Establish baseline logging traffic patterns and alert on deviations that could indicate interception

How to Mitigate CVE-2026-34477

Immediate Actions Required

• Upgrade to Apache Log4j Core 2.25.4 or later, which correctly implements hostname verification for the verifyHostName attribute
• As a temporary measure, enable hostname verification via the log4j2.sslVerifyHostName system property instead of the XML attribute
• Review all Log4j configurations using SMTP, Socket, or Syslog appenders with TLS to identify affected deployments
• Isolate network segments where logging traffic flows to reduce MITM attack surface

Patch Information

Apache has released Log4j Core 2.25.4 to address this vulnerability. The fix ensures that the verifyHostName attribute in <Ssl> configuration elements is properly honored during TLS connection establishment. Users should upgrade to this version or later to fully remediate the issue.

For additional technical details, refer to the Apache Security Advisory, the GitHub Pull Request, and the Apache Mailing List announcement.

Workarounds

• Set the log4j2.sslVerifyHostName system property to true via JVM arguments: -Dlog4j2.sslVerifyHostName=true
• Use network-level controls such as mutual TLS (mTLS) with client certificate authentication for logging connections
• Consider using the HTTP appender as an alternative, which is not affected by this vulnerability
• Implement network segmentation to ensure logging traffic does not traverse untrusted network segments

# Enable hostname verification via system property as workaround
java -Dlog4j2.sslVerifyHostName=true -jar your-application.jar