CVE-2026-34477

What it actually does

Apache Log4j Core versions through 2.25.3 can fail to enforce TLS hostname verification for SMTP, Socket, and Syslog appenders when TLS is configured with a nested <Ssl> element using the verifyHostName attribute. The certificate chain may still be trusted, but the remote endpoint hostname is not properly matched against the certificate identity, allowing a suitably positioned network attacker with a certificate trusted by the appender trust store, or the default Java trust store, to intercept the encrypted logging connection. This can expose log contents and may allow manipulation or redirection of log traffic. This is not a remote code execution flaw and does not affect the HTTP appender’s separate hostname verification behavior.

Why it matters to the business

Organizations using affected Log4j configurations may believe logging traffic is protected by TLS while it remains susceptible to interception on the network. If logs contain sensitive operational data, credentials, session identifiers, personal data, or security telemetry, attackers could capture or tamper with that information in transit. The risk is configuration-dependent and requires network positioning plus a trusted certificate, so broad exploitation likelihood is lower; EPSS is low and stable at 0.0041 over 30 days, the issue is not in CISA KEV, and no public exploit maturity is reported. However, because Log4j is widely deployed across Java applications, organizations should prioritize inventorying exposed configurations and upgrading where affected appenders are used.

How an attack unfolds

An attacker first needs a position where they can intercept or redirect network traffic between an application using Log4j Core and its configured SMTP, Socket, or Syslog logging endpoint. The target application must use TLS for that appender through a nested <Ssl> configuration and rely on the verifyHostName attribute for hostname validation. In vulnerable versions, that attribute is ignored, so the appender may accept a TLS certificate that chains to a trusted CA even if the certificate does not match the intended logging server hostname. The attacker presents such a trusted certificate, completes the TLS session as an impostor endpoint, and proxies, captures, drops, or modifies the log stream. Successful exploitation can disclose log data and potentially degrade the integrity of centralized logging or alerting, but it does not directly execute code on the application host.

How to fix it

Upgrade Apache Log4j Core to 2.25.4 or later, which corrects hostname verification for the affected <Ssl verifyHostName> configuration path. Prioritize applications using SMTP, Socket, or Syslog appenders with TLS configured via a nested <Ssl> element. Review dependency manifests, build files, application server libraries, shaded JARs, and container images for bundled log4j-core artifacts. If immediate upgrade is not possible, reduce exposure by avoiding affected network appenders, using the HTTP appender where appropriate, pinning or tightly restricting the appender trust store to the intended logging endpoint certificate or private CA, enforcing network-level controls so only expected application hosts can connect to logging endpoints, and preventing untrusted network paths from intercepting logging traffic. Do not treat setting verifyHostName="true" alone as sufficient on vulnerable versions, because that attribute is the affected behavior.

How to confirm the fix worked

Confirm the deployed log4j-core version is 2.25.4 or later in all runtime locations, including transitive dependencies and packaged application artifacts. Search Log4j configuration files for SMTP, Socket, or Syslog appenders that include nested <Ssl> elements and verify whether they previously relied on verifyHostName. Validate with dependency tooling such as Maven dependency:tree, Gradle dependencies, SBOM scanners, container image scanners, and runtime classpath inspection. Where feasible, perform a controlled TLS validation test in a non-production environment using a certificate trusted by the trust store but issued for a different hostname; fixed versions should reject the connection when hostname verification is enabled. Also verify that the HTTP appender is not incorrectly flagged as affected solely due to this issue, because it uses a separate hostname verification path.

Typical attack path

1. Identify an application that uses Apache Log4j Core with SMTP, Socket, or Syslog appenders for remote logging.
2. Confirm or infer that TLS is configured for the appender through a nested <Ssl> element and that the deployment relies on verifyHostName for hostname validation.
3. Gain a suitable network interception position, such as control of a routing path, DNS redirection path, compromised proxy, or adjacent network segment.
4. Obtain or present a certificate that is trusted by the appender’s configured trust store or by the default Java trust store.
5. Impersonate the configured logging endpoint during TLS negotiation; because hostname verification is not enforced, the connection may be accepted.
6. Capture, relay, suppress, or alter log events transmitted over the intercepted logging channel.

How to detect it

To determine exposure, search application configuration repositories, deployed configuration files, container images, and packaged artifacts for Log4j SMTP, Socket, or Syslog appenders using nested <Ssl> elements, especially those setting verifyHostName. To investigate possible past exploitation, review network telemetry, DNS logs, proxy logs, firewall logs, packet captures, and TLS inspection metadata for application servers connecting to unexpected logging destinations, unexpected IPs for known logging hostnames, or certificates with subjects/SANs that do not match the configured logging endpoint but chain to a trusted CA. Check centralized logging platforms for unexplained gaps, duplicate streams, source changes, timestamp discontinuities, or malformed events around network changes. Review Java TLS debug logs, if enabled, for certificate chains and peer identities used by logging appenders. There are no known public threat actors, exploit kits, malware markers, or ransomware campaigns tied to this CVE, so detection should focus on anomalous logging transport behavior rather than a fixed exploit signature.

What your security team should do

• Inventory Java applications and services using org.apache.logging.log4j:log4j-core, including shaded, bundled, and containerized copies.
• Prioritize review of systems that transmit logs to remote SMTP, Socket, or Syslog endpoints over TLS using nested <Ssl> configuration.
• Upgrade affected deployments to Apache Log4j Core 2.25.4 or later and rebuild/redeploy dependent applications.
• For high-sensitivity logging flows, restrict trust stores to the exact logging infrastructure CA or certificate chain rather than relying on broad default Java trust stores.
• Use network segmentation, firewall rules, and mutual trust boundaries to prevent untrusted systems from intercepting application-to-logging-endpoint traffic.
• Review logs and network telemetry for unexpected TLS certificate issuers, destination changes, DNS anomalies, or routing changes involving logging endpoints.
• Because the issue is not currently KEV-listed, has no reported ransomware association, and has low stable EPSS, handle as a targeted configuration-dependent risk rather than an internet-wide emergency, while still remediating where sensitive logs are transmitted.