Log4j fixes TLS hostname verification bypass in <Ssl> config

TL;DR — Log4j Core’s <Ssl verifyHostName> setting was silently ignored, so TLS log-shipping connections could skip hostname verification and be vulnerable to MITM interception in certain appender configurations.

What happened

Apache Log4j is a widely deployed Java logging framework; Log4j Core provides appenders for shipping logs over the network (e.g., SMTP, sockets, syslog).

CVE-2026-34477 describes a hostname verification bypass in Log4j Core’s TLS configuration: the verifyHostName attribute on the nested <Ssl> element was introduced in 2.12.0 but silently ignored through 2.25.3, due to an incomplete fix for the prior CVE-2025-68161 (which only covered hostname verification when enabled via the log4j2.sslVerifyHostName system property). The result is that deployments relying on <Ssl verifyHostName="true"> could still operate without hostname verification, leaving TLS connections potentially interceptable.

This is operationally important because TLS “on” is often treated as synonymous with “authenticated + confidential.” When hostname verification is unexpectedly skipped, log transport can become a stealthy interception point for attacker-controlled infrastructure or on-path adversaries.

Who is impacted

• Deployments using Apache Log4j Core where the deployed version falls into the affected ranges:

  Log4j Core line	Affected versions (vendor)
  2.x	2.12.0 up to and including 2.25.3
  3.x prereleases	3.0.0-alpha1 through 3.0.0-beta3

• Environments where all of the following are true (per the disclosure):

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

• Notably, the disclosure states this does not affect users of the HTTP appender, which uses a separate verifyHostname attribute and verifies hostnames by default.

What to do now

• Follow vendor remediation guidance and apply the fixed release called out by the project: upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
• Inventory where org.apache.logging.log4j:log4j-core is deployed (application artifacts, dependency locks/BOMs, and container images) and identify services that use network appenders (SMTP, Socket, Syslog) with TLS configured via <Ssl>.
• If you treat log pipelines as security evidence, validate that log receivers are authenticated as intended (hostname verification + trust store expectations) and review whether any log traffic could have been redirected or intercepted in your environment during the exposure window.