CVE-2025-68161: Apache Log4j Information Disclosure Bug

CVE-2025-68161 Overview

A TLS hostname verification bypass vulnerability has been identified in Apache Log4j Core's Socket Appender component. The Socket Appender fails to properly verify the TLS hostname of the peer certificate when establishing secure connections, even when the verifyHostName configuration attribute or the log4j2.sslVerifyHostName system property is explicitly set to true. This improper certificate validation flaw (CWE-297, CWE-295) could allow attackers positioned in a man-in-the-middle scenario to intercept or redirect sensitive log traffic.

Critical Impact

Attackers capable of network interception can capture or redirect application log data by presenting fraudulent certificates, potentially exposing sensitive information logged by applications using the vulnerable Socket Appender.

Affected Products

• Apache Log4j Core versions 2.0-beta9 through 2.25.2
• Applications using Log4j Socket Appender with TLS/SSL connections
• Java applications relying on Log4j's network logging capabilities

Discovery Timeline

• 2025-12-18 - CVE-2025-68161 published to NVD
• 2026-01-20 - Last updated in NVD database

Technical Details for CVE-2025-68161

Vulnerability Analysis

This vulnerability represents a critical flaw in SSL/TLS certificate validation within Log4j's Socket Appender component. The core issue stems from the appender's failure to enforce hostname verification during TLS handshake operations, despite configuration settings indicating that such verification should occur. When applications configure the Socket Appender to use SSL/TLS for secure log transmission, they reasonably expect that enabling verifyHostName will validate that the server's certificate matches the expected hostname. However, due to this implementation defect, the verification step is bypassed entirely, leaving connections vulnerable to interception.

The vulnerability enables man-in-the-middle attacks under specific conditions: the attacker must be able to intercept network traffic between the logging client and the log receiver, and they must possess a server certificate signed by a certificate authority trusted by either the Socket Appender's configured trust store or the default Java trust store. This makes the attack particularly feasible in enterprise environments where internal CAs are commonly trusted, or in scenarios where attackers have compromised a trusted CA.

Root Cause

The root cause lies in the Socket Appender's SSL/TLS implementation failing to invoke hostname verification routines during the TLS handshake process. Despite the presence of configuration options (verifyHostName attribute and log4j2.sslVerifyHostName system property) designed to enable this security control, the underlying code path does not properly implement or call the hostname verification logic. This results in a disconnect between the documented security configuration and actual runtime behavior, where certificates are validated for chain of trust but not for hostname matching.

Attack Vector

The attack requires network-level positioning to intercept traffic between a Log4j-enabled application and its configured log receiver. An attacker exploits this vulnerability by:

1. Positioning themselves on the network path between the client application and the log server (via ARP spoofing, DNS hijacking, or compromised network infrastructure)
2. Obtaining a valid certificate from any CA trusted by the target application's trust store
3. Presenting this certificate during the TLS handshake when the client attempts to connect
4. Intercepting, logging, or modifying the log data before optionally forwarding it to the legitimate receiver

Since hostname verification is not enforced, the attacker's certificate does not need to match the intended log server's hostname—any valid certificate from a trusted CA will be accepted. The network-based attack vector with high attack complexity reflects the requirement for privileged network positioning, though no user interaction is required once the attacker is in position.

Detection Methods for CVE-2025-68161

Indicators of Compromise

• Unexpected network connections from application servers to unknown log receiver endpoints
• Certificate mismatch warnings in network monitoring tools where the presented certificate hostname differs from the expected log server
• Anomalous log traffic patterns or log data appearing in unauthorized locations
• SSL/TLS connection events where the server certificate subject does not match the configured Socket Appender destination

Detection Strategies

• Monitor outbound TLS connections from applications using Log4j Socket Appender and validate certificate subjects against expected log server hostnames
• Implement network intrusion detection rules to alert on suspicious certificate presentations during log transmission
• Deploy deep packet inspection to identify Log4j socket traffic being routed to unexpected destinations
• Review application configurations to identify Socket Appenders configured with SSL but potentially vulnerable Log4j versions

Monitoring Recommendations

• Enable verbose SSL/TLS logging in Java applications to capture certificate chain details during Socket Appender connections
• Implement certificate pinning monitoring at the network layer to detect unauthorized certificates being accepted
• Configure SIEM rules to correlate log transmission events with network flow data to identify potential interception attempts
• Audit Log4j configurations across the environment to maintain an inventory of Socket Appender deployments requiring remediation

How to Mitigate CVE-2025-68161

Immediate Actions Required

• Upgrade all Apache Log4j Core installations to version 2.25.3 or later immediately
• Audit all applications using Log4j Socket Appender with TLS/SSL configurations to identify vulnerable deployments
• Implement network segmentation to restrict log traffic to trusted network paths while patching is in progress
• Consider temporarily disabling Socket Appender TLS connections in favor of alternative secure logging mechanisms until the upgrade is complete

Patch Information

Apache has released Log4j Core version 2.25.3 which addresses this hostname verification bypass vulnerability. The fix implements proper TLS hostname verification that respects the verifyHostName configuration attribute and log4j2.sslVerifyHostName system property settings. Users should upgrade to this version immediately. Technical details of the fix can be reviewed in the GitHub Pull Request. Additional security information is available in the Apache Security Advisory.

Workarounds

• Configure the Socket Appender to use a private or restricted trust root that only contains certificates for legitimate log receivers, significantly limiting the certificates an attacker could abuse
• Implement network-level controls such as mutual TLS authentication where the log server also validates client certificates
• Use alternative logging transports (local file logging with secure log shipping) that do not rely on the vulnerable Socket Appender TLS implementation
• Deploy a VPN or encrypted tunnel between application servers and log receivers to provide an additional layer of transport security

# Configuration example: Restrict trust store to private CA only
# In log4j2.xml, configure a custom SSL context with restricted trust store
# <Ssl>
#   <TrustStore location="file:///path/to/restricted-truststore.jks" 
#              password="truststore-password"/>
#   <KeyStore location="file:///path/to/keystore.jks" 
#            password="keystore-password"/>
# </Ssl>

# Generate a restricted trust store containing only your log server's CA
keytool -importcert -alias log-server-ca \
  -file /path/to/log-server-ca.crt \
  -keystore /path/to/restricted-truststore.jks \
  -storepass truststore-password -noprompt