CVE-2026-34477: CWE-297 Improper Validation of Certificate with Host Mismatch in Apache Software Foundation Apache Log4j Core
The fix for CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName attribute of the <Ssl> element. 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. A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met: * 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 by the default Java trust store if none is configured. This issue does not affect users of the HTTP appender, which uses a separate verifyHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName attribute that was not subject to this bug and verifies host names by default. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
AI Analysis
Technical Summary
The vulnerability CVE-2026-34477 in Apache Log4j Core arises from incomplete hostname verification in TLS connections when using SMTP, Socket, or Syslog appenders configured with a nested <Ssl> element. Although the verifyHostName attribute was introduced in version 2.12.0, it was ignored up to version 2.25.3, leaving TLS connections vulnerable to interception via man-in-the-middle attacks if the attacker can present a certificate trusted by the appender's trust store. The HTTP appender is unaffected as it uses a separate, correctly functioning verifyHostname attribute. The issue was addressed in Apache Log4j Core 2.25.4.
Potential Impact
An attacker capable of intercepting network traffic and presenting a trusted CA-issued certificate could exploit this vulnerability to perform man-in-the-middle attacks on TLS connections established by SMTP, Socket, or Syslog appenders using the affected Log4j versions. This could lead to interception or manipulation of sensitive logging data transmitted over these connections. The vulnerability does not impact HTTP appenders. There are no known exploits in the wild at this time.
Mitigation Recommendations
Users should upgrade Apache Log4j Core to version 2.25.4 or later, where this issue is corrected. No other mitigation or temporary workaround is indicated. Patch status is not explicitly stated in the vendor advisory excerpt, but the recommendation to upgrade to 2.25.4 confirms an official fix is available.
CVE-2026-34477: CWE-297 Improper Validation of Certificate with Host Mismatch in Apache Software Foundation Apache Log4j Core
Description
The fix for CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName attribute of the <Ssl> element. 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. A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met: * 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 by the default Java trust store if none is configured. This issue does not affect users of the HTTP appender, which uses a separate verifyHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName attribute that was not subject to this bug and verifies host names by default. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability CVE-2026-34477 in Apache Log4j Core arises from incomplete hostname verification in TLS connections when using SMTP, Socket, or Syslog appenders configured with a nested <Ssl> element. Although the verifyHostName attribute was introduced in version 2.12.0, it was ignored up to version 2.25.3, leaving TLS connections vulnerable to interception via man-in-the-middle attacks if the attacker can present a certificate trusted by the appender's trust store. The HTTP appender is unaffected as it uses a separate, correctly functioning verifyHostname attribute. The issue was addressed in Apache Log4j Core 2.25.4.
Potential Impact
An attacker capable of intercepting network traffic and presenting a trusted CA-issued certificate could exploit this vulnerability to perform man-in-the-middle attacks on TLS connections established by SMTP, Socket, or Syslog appenders using the affected Log4j versions. This could lead to interception or manipulation of sensitive logging data transmitted over these connections. The vulnerability does not impact HTTP appenders. There are no known exploits in the wild at this time.
Mitigation Recommendations
Users should upgrade Apache Log4j Core to version 2.25.4 or later, where this issue is corrected. No other mitigation or temporary workaround is indicated. Patch status is not explicitly stated in the vendor advisory excerpt, but the recommendation to upgrade to 2.25.4 confirms an official fix is available.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- apache
- Date Reserved
- 2026-03-28T11:26:04.052Z
- Cvss Version
- 4.0
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 69d91fde1cc7ad14dacba274
Added to database: 4/10/2026, 4:05:50 PM
Last enriched: 4/10/2026, 4:21:35 PM
Last updated: 4/11/2026, 6:03:01 AM
Views: 5
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.