{"id":"CVE-2026-34477","aliases":["CLSA-2026-1779929356","CLSA-2026-1785727932","CLSA-2026-1787726168","CLSA-2026-1790872639","CLSA-2026-1791375236","CLSA-2026-1791819410","CLSA-2026-1791901346","CLSA-2026-1792696729","CLSA-2026-1792756951","CLSA-2026-1793354113","EUVD-2026-21407","GHSA-3pxv-7cmr-fjr4","GHSA-445c-vh5m-36rj","GHSA-6hg6-v5c8-fphq","GHSA-vc5p-v9hr-52mj","RHLW-2026-64cfac683d7a9af7","RHLW-2026-97a6348484d7bbf1","ROOT-APP-MAVEN-CVE-2026-34477","SUSE-SU-2026:1843-1","UBUNTU-CVE-2026-34477","openSUSE-SU-2026:10544-1"],"status":"published","title":"Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass","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 \u003cSsl\u003e 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 \u003cSsl\u003e 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.","severity":{"version":"4.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","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00569,"percentile":0.47596,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-295","CWE-297"],"published":"2026-04-10T15:36:19Z","modified":"2026-11-02T19:46:33Z","fixes":[{"ecosystem":"Maven","package":"org.apache.logging.log4j:log4j-core","fixed_in":["2.25.4"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","fixed_in":["2.17.1-tuxcare.2","2.18.0-tuxcare.2","2.19.0-tuxcare.2"],"sources":["osv"]},{"ecosystem":"Root:Maven","package":"org.apache.logging.log4j:log4j-core","fixed_in":["2.12.4-aikido.10","2.19.0-aikido.9","2.25.0-aikido.11","2.25.0-aikido.12","2.21.1-aikido.5","2.23.1-aikido.3","2.19.0-aikido.9306"],"sources":["osv"]},{"ecosystem":"Root:Maven","package":"io.root.org.apache.logging.log4j:log4j-core","fixed_in":["2.19.0-root.io.2","2.19.0-root.io.3","2.25.0-root.io.2","2.12.4-root.io.3","2.19.0-root.io.8","2.12.4-root.io.9","2.25.0-root.io.10","2.12.4-root.io.10","2.19.0-root.io.9","2.25.0-root.io.11","2.21.1-root.io.4","2.25.0-root.io.12","2.21.1-root.io.5","2.23.1-root.io.3","2.19.0-root.io.9306"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.12.0"},{"fixed":"2.25.4"}]}]},{"source":"ghsa","ecosystem":"Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.0.0-alpha1"},{"last_affected":"3.0.0-beta3"}]}]},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.17.1"},{"fixed":"2.17.1-tuxcare.2"}]}],"versions":["2.17.1","2.17.1-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.17.2"},{"fixed":"2.17.2-tuxcare.2"}]}],"versions":["2.17.2","2.17.2-tuxcare.1"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-layout-template-json","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.17.2"},{"fixed":"2.17.2-tuxcare.2"}]}],"versions":["2.17.2","2.17.2-tuxcare.1"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-1.2-api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.24.3"},{"fixed":"2.24.3-tuxcare.2"}]}],"versions":["2.24.3","2.24.3-tuxcare.1"],"bundled":4},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.24.3"},{"fixed":"2.24.3-tuxcare.2"}]}],"versions":["2.24.3","2.24.3-tuxcare.1"],"bundled":4},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.24.3"},{"fixed":"2.24.3-tuxcare.2"}]}],"versions":["2.24.3","2.24.3-tuxcare.1"],"bundled":4},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-1.2-api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.13.3"},{"fixed":"2.13.3-tuxcare.1"}]}],"versions":["2.13.3"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.13.3"},{"fixed":"2.13.3-tuxcare.1"}]}],"versions":["2.13.3"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.23.1"},{"fixed":"2.23.1-tuxcare.2"}]}],"versions":["2.23.1","2.23.1-tuxcare.1"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.18.0"},{"fixed":"2.18.0-tuxcare.2"}]}],"versions":["2.18.0","2.18.0-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.19.0"},{"fixed":"2.19.0-tuxcare.2"}]}],"versions":["2.19.0","2.19.0-tuxcare.1"]},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-1.2-api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.20.0"},{"fixed":"2.20.0-tuxcare.2"}]}],"versions":["2.20.0","2.20.0-tuxcare.1"],"bundled":5},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.20.0"},{"fixed":"2.20.0-tuxcare.2"}]}],"versions":["2.20.0","2.20.0-tuxcare.1"],"bundled":5},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.20.0"},{"fixed":"2.20.0-tuxcare.2"}]}],"versions":["2.20.0","2.20.0-tuxcare.1"],"bundled":5},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-layout-template-json","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.20.0"},{"fixed":"2.20.0-tuxcare.2"}]}],"versions":["2.20.0","2.20.0-tuxcare.1"],"bundled":5},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-1.2-api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.12.4"},{"fixed":"2.12.4-tuxcare.2"}]}],"versions":["2.12.4","2.12.4-tuxcare.1"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.12.4"},{"fixed":"2.12.4-tuxcare.2"}]}],"versions":["2.12.4","2.12.4-tuxcare.1"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-1.2-api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.25.2"},{"fixed":"2.25.2-tuxcare.1"}]}],"versions":["2.25.2"],"bundled":5},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.25.2"},{"fixed":"2.25.2-tuxcare.1"}]}],"versions":["2.25.2"],"bundled":5},{"source":"osv","ecosystem":"TuxCare:Maven","package":"org.apache.logging.log4j:log4j-layout-template-json","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.25.2"},{"fixed":"2.25.2-tuxcare.1"}]}],"versions":["2.25.2"],"bundled":5},{"source":"osv","ecosystem":"Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.12.0"},{"fixed":"2.25.4"}]}],"versions":["2.12.0","2.12.1","2.12.2","2.12.3","2.12.4","2.13.0","2.13.1","2.13.2","2.13.3","2.14.0","2.14.1","2.15.0","2.16.0","2.17.0","2.17.1","2.17.2","2.18.0","2.19.0","2.20.0","2.21.0","2.21.1","2.22.0","2.22.1","2.23.0","2.23.1","2.24.0","2.24.1","2.24.2","2.24.3","2.25.0","2.25.1","2.25.2","2.25.3"]},{"source":"osv","ecosystem":"Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.0.0-alpha1"},{"last_affected":"3.0.0-beta3"}]}],"versions":["3.0.0-alpha1","3.0.0-beta1","3.0.0-beta2","3.0.0-beta3"]},{"source":"osv","ecosystem":"Red Hat Lightwell:Maven","package":"org.apache.logging.log4j:log4j-1.2-api","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.24.3.rhlw-00004"}]}],"versions":["2.0","2.0-beta5","2.0-beta6","2.0-beta7","2.0-beta8","2.0-beta9","2.0-rc1","2.0-rc2","2.0.1","2.0.2","2.1","2.10.0","2.11.0","2.11.1","2.11.2","2.12.0","2.12.1","2.12.2","2.12.3","2.12.4","2.13.0","2.13.1","2.13.2","2.13.3","2.14.0","2.14.1","2.15.0","2.16.0","2.17.0","2.17.1","2.17.2","2.18.0","2.19.0","2.2","2.20.0","2.21.0","2.21.1","2.22.0","2.22.1","2.23.0","2.23.1","2.24.0","2.24.1","2.24.2","2.24.3","2.3","2.3.1","2.3.2","2.4","2.4.1","2.5","2.6","2.6.1","2.6.2","2.7","2.8","2.8.1","2.8.2","2.9.0","2.9.1"],"bundled":4},{"source":"osv","ecosystem":"Red Hat Lightwell:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.24.3.rhlw-00004"}]}],"versions":["2.0","2.0-alpha1","2.0-alpha2","2.0-beta1","2.0-beta2","2.0-beta3","2.0-beta4","2.0-beta5","2.0-beta6","2.0-beta7","2.0-beta8","2.0-beta9","2.0-rc1","2.0-rc2","2.0.1","2.0.2","2.1","2.10.0","2.11.0","2.11.1","2.11.2","2.12.0","2.12.1","2.12.2","2.12.3","2.12.4","2.13.0","2.13.1","2.13.2","2.13.3","2.14.0","2.14.1","2.15.0","2.16.0","2.17.0","2.17.1","2.17.2","2.18.0","2.19.0","2.2","2.20.0","2.21.0","2.21.1","2.22.0","2.22.1","2.23.0","2.23.1","2.24.0","2.24.1","2.24.2","2.24.3","2.3","2.3.1","2.3.2","2.4","2.4.1","2.5","2.6","2.6.1","2.6.2","2.7","2.8","2.8.1","2.8.2","2.9.0","2.9.1"],"bundled":4},{"source":"osv","ecosystem":"Root:Maven","package":"org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.12.4-aikido.10"},{"fixed":"2.19.0-aikido.9"},{"fixed":"2.25.0-aikido.11"},{"fixed":"2.25.0-aikido.12"},{"fixed":"2.21.1-aikido.5"},{"fixed":"2.23.1-aikido.3"},{"fixed":"2.19.0-aikido.9306"}]}]},{"source":"osv","ecosystem":"Root:Maven","package":"io.root.org.apache.logging.log4j:log4j-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.19.0-root.io.2"},{"fixed":"2.19.0-root.io.3"},{"fixed":"2.25.0-root.io.2"},{"fixed":"2.12.4-root.io.3"},{"fixed":"2.19.0-root.io.8"},{"fixed":"2.12.4-root.io.9"},{"fixed":"2.25.0-root.io.10"},{"fixed":"2.12.4-root.io.10"},{"fixed":"2.19.0-root.io.9"},{"fixed":"2.25.0-root.io.11"},{"fixed":"2.21.1-root.io.4"},{"fixed":"2.25.0-root.io.12"},{"fixed":"2.21.1-root.io.5"},{"fixed":"2.23.1-root.io.3"},{"fixed":"2.19.0-root.io.9306"}]}]},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"apache-log4j2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.2-1","2.4-1","2.4-2","2.4-2ubuntu0.1~esm1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"apache-log4j2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.8.2-1","2.8.2-2","2.10.0-1","2.10.0-2","2.10.0-2ubuntu0.1","2.12.4-0ubuntu0.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"apache-log4j2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.11.1-2","2.11.2-1","2.15.0-0.20.04.1","2.16.0-0.20.04.1","2.17.0-0.20.04.1","2.17.1-0.20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"apache-log4j2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.13.3-1","2.15.0-1","2.16.0-1","2.17.0-1","2.17.1-1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"apache-log4j2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.19.0-2"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"apache-log4j2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.19.0-2"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"apache-log4j2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.19.0-2build1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"apache-log4j2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.19.0-2","2.19.0-2build1"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"log4j","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.20.0-2.1"}]}],"bundled":4}],"products":[{"vendor":"apache","product":"log4j"},{"vendor":"apache software foundation","product":"apache log4j core"}],"references":[{"url":"https://github.com/apache/logging-log4j2/pull/4075","tags":["patch","Issue Tracking","Patch","fix","web","report"]},{"url":"https://logging.apache.org/security.html#CVE-2026-34477","tags":["vendor-advisory","Vendor Advisory","advisory","web","report"]},{"url":"https://logging.apache.org/cyclonedx/vdr.xml","tags":["vendor-advisory","Vendor Advisory","advisory","web","report"]},{"url":"https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName","tags":["related","Product","web","report"]},{"url":"https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4","tags":["vendor-advisory","Mailing List","advisory","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34477","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-6hg6-v5c8-fphq","tags":["advisory"]},{"url":"https://repo.maven.apache.org/maven2","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/34xxx/CVE-2026-34477.json","tags":["advisory"]},{"url":"https://github.com/apache/logging-log4j2","tags":["package"]},{"url":"https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/68xxx/CVE-2025-68161.json","tags":["advisory"]},{"url":"https://lists.apache.org/thread/xr33kyxq3sl67lwb61ggvm1fzc8k7dvx","tags":["advisory"]},{"url":"https://logging.apache.org/security.html#CVE-2025-68161","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68161","tags":["advisory"]},{"url":"https://github.com/apache/logging-log4j2/pull/4002","tags":["fix"]},{"url":"https://github.com/advisories/GHSA-vc5p-v9hr-52mj","tags":["advisory"]},{"url":"https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/34xxx/CVE-2026-34478.json","tags":["advisory"]},{"url":"https://lists.apache.org/thread/3k1clr2l6vkdnl4cbhjrnt1nyjvb5gwt","tags":["advisory"]},{"url":"https://logging.apache.org/security.html#CVE-2026-34478","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34478","tags":["advisory"]},{"url":"https://github.com/apache/logging-log4j2/pull/4074","tags":["fix"]},{"url":"https://github.com/advisories/GHSA-445c-vh5m-36rj","tags":["advisory"]},{"url":"https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/34xxx/CVE-2026-34480.json","tags":["advisory"]},{"url":"https://lists.apache.org/thread/5x0hcnng0chhghp6jgjdp3qmbbhfjzhb","tags":["advisory"]},{"url":"https://logging.apache.org/security.html#CVE-2026-34480","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-34480","tags":["advisory"]},{"url":"https://github.com/apache/logging-log4j2/pull/4077","tags":["fix"]},{"url":"https://github.com/advisories/GHSA-3pxv-7cmr-fjr4","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20261843-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1262050","tags":["report"]},{"url":"https://bugzilla.suse.com/1262091","tags":["report"]},{"url":"https://bugzilla.suse.com/1262092","tags":["report"]},{"url":"https://bugzilla.suse.com/1262093","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34477","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34479","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34480","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34481","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2026-34477","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-34477","tags":["report"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-34477","title":"Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass","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 \u003cSsl\u003e 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 \u003cSsl\u003e 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.","status":"published","published":"2026-04-10T15:36:19.74Z","modified":"2026-04-10T17:38:57.154Z","cvss":[{"version":"4.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","level":"medium","assessor":"cna"}],"cwes":["CWE-297"],"updated_at":"2026-11-02T14:20:14.665567Z"}],"euvd":[{"id":"EUVD-2026-21407","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 \u003cSsl\u003e 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 \u003cSsl\u003e 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.","status":"published","published":"2026-04-10T15:36:19Z","modified":"2026-04-10T17:38:57Z","cvss":[{"version":"4.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","level":"medium"}],"updated_at":"2026-11-02T19:24:29.850635Z"}],"ghsa":[{"id":"GHSA-6hg6-v5c8-fphq","title":"Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration","description":"The fix for  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 `\u003cSsl\u003e` 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 \u003cSsl\u003e 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.\n\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.","status":"published","published":"2026-04-10T18:31:17Z","modified":"2026-04-14T00:11:56Z","cvss":[{"version":"4.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","level":"medium"}],"cwes":["CWE-297"],"updated_at":"2026-11-02T14:39:53.087746Z"}],"nvd":[{"id":"CVE-2026-34477","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 \u003cSsl\u003e 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 \u003cSsl\u003e 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.","status":"published","published":"2026-04-10T16:16:30.843Z","modified":"2026-10-26T22:10:00.163Z","cvss":[{"version":"4.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","level":"medium","assessor":"secondary"},{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-297","CWE-295"],"updated_at":"2026-11-02T14:12:13.902911Z"}],"osv":[{"id":"CVE-2026-34477","title":"Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass","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 \u003cSsl\u003e 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 \u003cSsl\u003e 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.","status":"published","published":"2026-04-10T15:36:19.74Z","modified":"2026-10-28T02:31:09.60518209Z","cvss":[{"version":"4.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","level":"medium"}],"cwes":["CWE-297"],"updated_at":"2026-11-02T15:45:02.247031Z"},{"id":"GHSA-6hg6-v5c8-fphq","title":"Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration","description":"The fix for  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 `\u003cSsl\u003e` 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 \u003cSsl\u003e 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.\n\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.","status":"published","published":"2026-04-10T18:31:17Z","modified":"2026-09-10T03:50:43.570169134Z","cvss":[{"version":"4.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","level":"medium"}],"cwes":["CWE-297"],"updated_at":"2026-11-02T15:46:39.618611Z"},{"id":"RHLW-2026-64cfac683d7a9af7","title":"Lightwell Security Advisory: log4j-1.2-api 2.24.3.rhlw-00004","description":"Red Hat Lightwell has released org.apache.logging.log4j:log4j-1.2-api 2.24.3.rhlw-00004 with backported fixes for CVE-2025-68161, CVE-2026-34477, CVE-2026-34478, and CVE-2026-34480.\n\nCVE-2025-68161: Apache Log4j Core: Missing TLS hostname verification in Socket appender\n\nCVE-2026-34477: Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass\n\nCVE-2026-34478: Apache Log4j Core: Log injection in Rfc5424Layout due to silent configuration incompatibility\n\nCVE-2026-34480: Apache Log4j Core: Silent log event loss in XmlLayout due to unescaped XML 1.0 forbidden characters\n\nThis patched artifact is a drop-in replacement for org.apache.logging.log4j:log4j-1.2-api 2.24.3 from Maven Central.","status":"published","published":"2026-10-08T19:45:56Z","modified":"2026-10-27T04:13:02.72107918Z","cvss":[{"version":"4.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","level":"medium"}],"updated_at":"2026-11-02T15:52:58.636919Z"},{"id":"RHLW-2026-97a6348484d7bbf1","title":"Lightwell Security Advisory: log4j-core 2.24.3.rhlw-00004","description":"Red Hat Lightwell has released org.apache.logging.log4j:log4j-core 2.24.3.rhlw-00004 with backported fixes for CVE-2025-68161, CVE-2026-34477, CVE-2026-34478, and CVE-2026-34480.\n\nCVE-2025-68161: Apache Log4j Core: Missing TLS hostname verification in Socket appender\n\nCVE-2026-34477: Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass\n\nCVE-2026-34478: Apache Log4j Core: Log injection in Rfc5424Layout due to silent configuration incompatibility\n\nCVE-2026-34480: Apache Log4j Core: Silent log event loss in XmlLayout due to unescaped XML 1.0 forbidden characters\n\nThis patched artifact is a drop-in replacement for org.apache.logging.log4j:log4j-core 2.24.3 from Maven Central.","status":"published","published":"2026-10-12T19:52:23Z","modified":"2026-10-27T04:13:03.483520242Z","cvss":[{"version":"4.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","level":"medium"},{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T15:52:58.636919Z"},{"id":"ROOT-APP-MAVEN-CVE-2026-34477","title":"CVE-2026-34477 in org.apache.logging.log4j:log4j-core - Patched by Root","description":"Root has patched CVE-2026-34477 in the org.apache.logging.log4j:log4j-core package for Root:Maven. Multiple fixed versions available.","status":"published","published":"2026-10-27T13:14:33Z","modified":"2026-10-27T14:15:02.44532791Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T15:53:27.066589Z"},{"id":"UBUNTU-CVE-2026-34477","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 \u003cSsl\u003e 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 \u003cSsl\u003e 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.","status":"published","published":"2026-04-10T16:16:00Z","modified":"2026-10-17T13:00:01.939080984Z","cvss":[{"version":"4.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","level":"medium"},{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T16:56:16.036833Z"},{"id":"CLSA-2026-1779929356","title":"TuxCare security update for org.apache.logging.log4j:log4j-core (1 CVE)","description":"TuxCare rebuilt org.apache.logging.log4j:log4j-core to address 1 CVE. Fixed in 2.17.1-tuxcare.2.","status":"published","published":"2026-08-04T14:52:34Z","modified":"2026-11-02T19:45:32.089645605Z","updated_at":"2026-11-02T20:30:18.404297Z"},{"id":"CLSA-2026-1785727932","title":"TuxCare security update for org.apache.logging.log4j (3 CVEs)","description":"TuxCare rebuilt 2 org.apache.logging.log4j packages to address 3 CVEs. Fixed in 2.17.2-tuxcare.2.","status":"published","published":"2026-08-04T14:52:51Z","modified":"2026-11-02T19:45:49.91461624Z","updated_at":"2026-11-02T20:30:00.884471Z"},{"id":"CLSA-2026-1787726168","title":"TuxCare security update for org.apache.logging.log4j (4 CVEs)","description":"TuxCare rebuilt 3 org.apache.logging.log4j packages to address 4 CVEs. Fixed in 2.24.3-tuxcare.2.","status":"published","published":"2026-08-26T06:36:08Z","modified":"2026-11-02T19:45:58.94366801Z","updated_at":"2026-11-02T20:29:49.757752Z"},{"id":"CLSA-2026-1790872639","title":"TuxCare security update for org.apache.logging.log4j (3 CVEs)","description":"TuxCare rebuilt 2 org.apache.logging.log4j packages to address 3 CVEs. Fixed in 2.13.3-tuxcare.1.","status":"published","published":"2026-10-01T16:37:19Z","modified":"2026-11-02T19:46:24.964528467Z","updated_at":"2026-11-02T20:29:22.637147Z"},{"id":"CLSA-2026-1791375236","title":"TuxCare security update for org.apache.logging.log4j:log4j-core (3 CVEs)","description":"TuxCare rebuilt org.apache.logging.log4j:log4j-core to address 3 CVEs. Fixed in 2.23.1-tuxcare.2.","status":"published","published":"2026-10-07T12:13:56Z","modified":"2026-11-02T19:46:26.288157628Z","updated_at":"2026-11-02T20:29:17.805906Z"},{"id":"CLSA-2026-1791819410","title":"TuxCare security update for org.apache.logging.log4j:log4j-core (1 CVE)","description":"TuxCare rebuilt org.apache.logging.log4j:log4j-core to address 1 CVE. Fixed in 2.18.0-tuxcare.2.","status":"published","published":"2026-10-12T15:36:50Z","modified":"2026-11-02T19:46:27.049955396Z","updated_at":"2026-11-02T20:29:13.152182Z"},{"id":"CLSA-2026-1791901346","title":"TuxCare security update for org.apache.logging.log4j:log4j-core (1 CVE)","description":"TuxCare rebuilt org.apache.logging.log4j:log4j-core to address 1 CVE. Fixed in 2.19.0-tuxcare.2.","status":"published","published":"2026-10-13T14:22:26Z","modified":"2026-11-02T19:46:27.304587776Z","updated_at":"2026-11-02T20:29:13.152182Z"},{"id":"CLSA-2026-1792696729","title":"TuxCare security update for org.apache.logging.log4j (5 CVEs)","description":"TuxCare rebuilt 4 org.apache.logging.log4j packages to address 5 CVEs. Fixed in 2.20.0-tuxcare.2.","status":"published","published":"2026-10-22T19:18:49Z","modified":"2026-11-02T19:46:31.511807766Z","updated_at":"2026-11-02T20:28:59.01272Z"},{"id":"CLSA-2026-1792756951","title":"TuxCare security update for org.apache.logging.log4j (3 CVEs)","description":"TuxCare rebuilt 2 org.apache.logging.log4j packages to address 3 CVEs. Fixed in 2.12.4-tuxcare.2.","status":"published","published":"2026-10-23T12:02:31Z","modified":"2026-11-02T19:46:31.66329913Z","updated_at":"2026-11-02T20:28:59.01272Z"},{"id":"CLSA-2026-1793354113","title":"TuxCare security update for org.apache.logging.log4j (5 CVEs)","description":"TuxCare rebuilt 3 org.apache.logging.log4j packages to address 5 CVEs. Fixed in 2.25.2-tuxcare.1.","status":"published","published":"2026-10-30T10:55:14Z","modified":"2026-11-02T19:46:33.204047397Z","updated_at":"2026-11-02T20:28:42.34712Z"},{"id":"openSUSE-SU-2026:10544-1","title":"log4j-2.20.0-2.1 on GA media","description":"These are all security issues fixed in the log4j-2.20.0-2.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-04-14T00:00:00Z","modified":"2026-04-15T08:00:07.138921Z","updated_at":"2026-11-02T16:58:38.415593Z"},{"id":"SUSE-SU-2026:1843-1","title":"Security update for log4j","description":"This update for log4j fixes the following issues:\n\n- CVE-2026-34477: TLS connections vulnerable to interception due to incomplete hostname verification configuration\n  checks (bsc#1262050).\n- CVE-2026-34479: silent log event loss due to improper XML escaping in `Log4j1XmlLayout` (bsc#1262091).\n- CVE-2026-34480: silent log event loss due to improper XML escaping in `XmlLayout` (bsc#1262092).\n- CVE-2026-34481: silent log event loss due to improper serialization of non-finite floating-point values in\n  `JsonTemplateLayout` (bsc#1262093).\n","status":"published","published":"2026-05-13T15:24:57Z","modified":"2026-05-14T08:15:07.933753Z","updated_at":"2026-11-02T15:54:01.610851Z"}]}}