{"advisories":[{"id":"GHSA-6hg6-v5c8-fphq","source":"ghsa","title":"Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration","url":"https://github.com/advisories/GHSA-6hg6-v5c8-fphq"}],"cve":"CVE-2026-34477","enrichment":{"affected":[{"configurations":[{"platform":null,"status":"affected","versions":{"scheme":"semver","value":"[2.12.0,2.25.4)"}},{"platform":null,"status":"affected","versions":{"scheme":"semver","value":"[3.0.0-alpha1,3.0.0-beta3]"}}],"enrichment":{"confidence":83.0,"confidence_source":"matching","scores":[{"score":95.0,"source":"inferred"},{"score":83.0,"source":"matching"}]},"original":{"product":"Apache Log4j Core","source":"cna","vendor":"Apache Software Foundation"},"product":"log4j","vendor":"apache"}],"analysis":{"en":{"generated_at":"2026-04-14T01:41:35.250364+00:00","value":{"mitigation_remediation":["Update to Apache Log4j Core 2.25.4 or later, which fixes the verifyHostName handling bug.","Verify that the verifyHostName attribute is set to true in any remaining <Ssl> configurations, or use the system property log4j2.sslVerifyHostName to enforce hostname checks.","If an upgrade is not immediately possible, configure appenders to avoid TLS via <Ssl> or switch to the HttpAppender, which correctly verifies host names by default.","Review the trust store used by the application to ensure it does not contain untrusted CA certificates that could be presented by an attacker."],"summary":{"action":"Patch Now","impact":"Hostname verification bypass, allowing man‑in‑the‑middle attacks on TLS connections"},"threat_synthesis":{"affected_systems":"Apache Log4j Core versions 2.12.0 through 2.25.3 are impacted, specifically when an SMTP, Socket, or Syslog appender is used and TLS is configured via a nested <Ssl> element. The HTTP appender is not affected because it uses a distinct verifyHostname attribute that behaves correctly.","description_and_impact":"A silent ignore of the verifyHostName attribute in Log4j Core’s <Ssl> configuration enables an attacker to bypass TLS hostname verification, effectively turning a secure connection into a Trojan horse. This weakness can allow the interception and manipulation of log transmission, exposing sensitive logging data and enabling further compromise. The flaw is rooted in CWE‑295 (Improper Authentication) and CWE‑297 (Improper Verification of Cryptographic Parameters).","risk_and_exploitability":"The CVSS score of 6.3 reflects a moderate severity, but the EPSS score is below 1% and the vulnerability is not listed in the CISA KEV catalog, indicating a lower likelihood of widespread exploitation. Nevertheless, a network‑based attacker who can present a certificate trusted by the application’s trust store, or the default Java trust store, can meet the conditions and mount a man‑in‑the‑middle attack. The attack requires the presence of a vulnerable appender and an adjacent TLS layer that does not enforce hostname validation. While not immediately exploitable in all environments, the potential impact on confidentiality warrants prompt attention."}}}},"created":"2026-04-13T12:44:45.042885+00:00","updated":"2026-04-14T16:36:28.002767+00:00","vendors":["apache","apache$PRODUCT$log4j"]},"epss":{"score":0.00502},"mitre":{"cpes":["cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*"],"created":"2026-04-10T15:36:19.740000+00:00","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.\n\nAlthough 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.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n  *  An SMTP, Socket, or Syslog appender is in use.\n  *  TLS is configured via a nested <Ssl> element.\n  *  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.\nThis 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.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.","metrics":{"cvssV2_0":{},"cvssV3_0":{},"cvssV3_1":{},"cvssV4_0":{"score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N"}},"mitre_repo_path":"cves/2026/34xxx/CVE-2026-34477.json","references":["https://github.com/apache/logging-log4j2/pull/4075","https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4","https://logging.apache.org/cyclonedx/vdr.xml","https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName","https://logging.apache.org/security.html#CVE-2026-34477"],"title":"Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass","updated":"2026-04-10T17:38:57.154000+00:00","vendors":["apache","apache$PRODUCT$log4j"],"weaknesses":["CWE-297"]},"nvd":{"cpes":["cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:alpha1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:alpha1_rc1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:alpha1_rc2:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta2:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta3:*:*:*:*:*:*"],"created":"2026-04-10T16:16:30.843000+00:00","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.\n\nAlthough 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.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n  *  An SMTP, Socket, or Syslog appender is in use.\n  *  TLS is configured via a nested <Ssl> element.\n  *  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.\nThis 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.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.","metrics":{"cvssV2_0":{},"cvssV3_0":{},"cvssV3_1":{"score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N"},"cvssV4_0":{"score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"}},"nvd_repo_path":"2026/CVE-2026-34477.json","references":["https://github.com/apache/logging-log4j2/pull/4075","https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4","https://logging.apache.org/cyclonedx/vdr.xml","https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName","https://logging.apache.org/security.html#CVE-2026-34477"],"title":null,"updated":"2026-06-17T10:39:06.643000+00:00","vendors":["apache","apache$PRODUCT$log4j"],"weaknesses":["CWE-295","CWE-297"]},"opencve":{"changes":[{"created":"2026-04-10T16:00:00+00:00","data":[{"details":{"new":"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.\n\nAlthough 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.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n  *  An SMTP, Socket, or Syslog appender is in use.\n  *  TLS is configured via a nested <Ssl> element.\n  *  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.\nThis 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.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.","old":null},"type":"description"},{"details":{"new":"Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass","old":null},"type":"title"},{"details":["apache","apache$PRODUCT$log4j"],"type":"first_time"},{"details":{"added":["CWE-297"],"removed":[]},"type":"weaknesses"},{"details":{"added":["cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*"],"removed":[]},"type":"cpes"},{"details":{"added":["apache","apache$PRODUCT$log4j"],"removed":[]},"type":"vendors"},{"details":{"added":["https://github.com/apache/logging-log4j2/pull/4075","https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4","https://logging.apache.org/cyclonedx/vdr.xml","https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName","https://logging.apache.org/security.html#CVE-2026-34477"],"removed":[]},"type":"references"},{"details":{"added":{"cvssV4_0":{"score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N"}},"removed":{},"updated":{}},"type":"metrics"}],"id":"fa8f88d9-d162-48a0-ba5b-8f230ac5f4d3"},{"created":"2026-04-10T18:15:00+00:00","data":[{"details":{"added":{"ssvc":{"options":{"Automatable":"no","Exploitation":"none","Technical Impact":"partial"},"version":"2.0.3"}},"removed":{},"updated":{}},"type":"metrics"}],"id":"30bf70ec-f435-4334-8d2b-231cf0b453ec"},{"created":"2026-04-14T00:15:00+00:00","data":[{"details":{"added":["CWE-295"],"removed":[]},"type":"weaknesses"},{"details":{"added":["https://nvd.nist.gov/vuln/detail/CVE-2026-34477","https://www.cve.org/CVERecord?id=CVE-2026-34477"],"removed":[]},"type":"references"},{"details":{"added":{"cvssV3_1":{"score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N"}},"removed":{},"updated":{"threat_severity":{"new":"Moderate","old":null}}},"type":"metrics"}],"id":"2b201683-05b4-4628-9c62-c6f7cb16ec33"},{"created":"2026-05-06T17:00:00+00:00","data":[{"details":{"added":["cpe:2.3:a:apache:log4j:3.0.0:alpha1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:alpha1_rc1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:alpha1_rc2:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta2:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta3:*:*:*:*:*:*"],"removed":[]},"type":"cpes"},{"details":{"added":{},"removed":{},"updated":{"cvssV3_1":{"new":{"score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N"},"old":{"score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N"}}}},"type":"metrics"}],"id":"a7f9074a-6b4a-45d8-b8b3-87f64b746277"}],"cpes":{"data":["cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:alpha1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:alpha1_rc1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:alpha1_rc2:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta1:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta2:*:*:*:*:*:*","cpe:2.3:a:apache:log4j:3.0.0:beta3:*:*:*:*:*:*"],"providers":["mitre","nvd"]},"created":{"data":"2026-04-10T15:36:19+00:00","provider":"redhat"},"description":{"data":"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.\n\nAlthough 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.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n  *  An SMTP, Socket, or Syslog appender is in use.\n  *  TLS is configured via a nested <Ssl> element.\n  *  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.\nThis 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.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.","provider":"mitre"},"metrics":{"cvssV2_0":{"data":{},"provider":null},"cvssV3_0":{"data":{},"provider":null},"cvssV3_1":{"data":{"score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N"},"provider":"nvd"},"cvssV4_0":{"data":{"score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N"},"provider":"mitre"},"epss":{"data":{"score":0.00502},"provider":"first"},"kev":{"data":{},"provider":null},"ssvc":{"data":{"options":{"Automatable":"no","Exploitation":"none","Technical Impact":"partial"},"version":"2.0.3"},"provider":"vulnrichment"},"threat_severity":{"data":"Moderate","provider":"redhat"}},"references":{"data":["https://github.com/apache/logging-log4j2/pull/4075","https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4","https://logging.apache.org/cyclonedx/vdr.xml","https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName","https://logging.apache.org/security.html#CVE-2026-34477","https://nvd.nist.gov/vuln/detail/CVE-2026-34477","https://www.cve.org/CVERecord?id=CVE-2026-34477"],"providers":["mitre","nvd","redhat"]},"title":{"data":"Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass","provider":"mitre"},"updated":{"data":"2026-05-06T16:49:51.080000+00:00","provider":"nvd"},"vendors":{"data":["apache","apache$PRODUCT$log4j"],"providers":["mitre","nvd","enrichment"]},"weaknesses":{"data":["CWE-295","CWE-297"],"providers":["mitre","nvd","redhat"]}},"redhat":{"cpes":[],"created":"2026-04-10T15:36:19+00:00","description":"A flaw was found in Apache Log4j Core. A network-based attacker can perform a man-in-the-middle (MITM) attack, allowing them to intercept encrypted communications. This occurs when an SMTP, Socket, or Syslog appender uses Transport Layer Security (TLS) with a nested <Ssl> element, and the attacker has a certificate from a trusted Certificate Authority (CA). The vulnerability stems from an incomplete hostname verification fix, making TLS connections susceptible to interception.","metrics":{"cvssV2_0":{},"cvssV3_0":{},"cvssV3_1":{"score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N"},"threat_severity":"Moderate"},"redhat_repo_path":"2026/CVE-2026-34477.json","references":["https://github.com/apache/logging-log4j2/pull/4075","https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4","https://logging.apache.org/cyclonedx/vdr.xml","https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName","https://logging.apache.org/security.html#CVE-2026-34477","https://nvd.nist.gov/vuln/detail/CVE-2026-34477","https://www.cve.org/CVERecord?id=CVE-2026-34477"],"title":"org.apache.logging.log4j/log4j-core: Apache Log4j Core: Man-in-the-middle attack due to incomplete hostname verification","updated":"2026-04-10T15:36:19+00:00","vendors":[],"weaknesses":["CWE-295"]},"vulnrichment":{"cpes":[],"created":"2026-04-10T15:36:19.740000+00:00","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.\n\nAlthough 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.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n  *  An SMTP, Socket, or Syslog appender is in use.\n  *  TLS is configured via a nested <Ssl> element.\n  *  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.\nThis 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.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.","metrics":{"cvssV2_0":{},"cvssV3_0":{},"cvssV3_1":{},"cvssV4_0":{},"kev":{},"ssvc":{"options":{"Automatable":"no","Exploitation":"none","Technical Impact":"partial"},"version":"2.0.3"}},"references":[],"title":"Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass","updated":"2026-04-10T17:38:37.230000+00:00","vendors":[],"vulnrichment_repo_path":"2026/34xxx/CVE-2026-34477.json","weaknesses":[]}}