CVE-2026-34477

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-34477", "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "state": "PUBLISHED", "assignerShortName": "apache", "dateReserved": "2026-03-28T11:26:04.052Z", "datePublished": "2026-04-10T15:36:19.740Z", "dateUpdated": "2026-04-10T17:38:57.154Z"}, "containers": {"cna": {"affected": [{"collectionURL": "https://repo.maven.apache.org/maven2", "cpes": ["cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*"], "defaultStatus": "unaffected", "packageName": "org.apache.logging.log4j:log4j-core", "packageURL": "pkg:maven/org.apache.logging.log4j/log4j-core", "product": "Apache Log4j Core", "vendor": "Apache Software Foundation", "versions": [{"lessThan": "2.25.4", "status": "affected", "version": "2.12.0", "versionType": "maven"}, {"lessThanOrEqual": "3.0.0-beta3", "status": "affected", "version": "3.0.0-alpha1", "versionType": "maven"}]}], "credits": [{"lang": "en", "type": "finder", "value": "Samuli Leinonen (original reporter)"}, {"lang": "en", "type": "finder", "value": "Naresh Kandula (independently)"}, {"lang": "en", "type": "finder", "value": "Vitaly Simonovich (independently)"}, {"lang": "en", "type": "finder", "value": "Raijuna (independently)"}, {"lang": "en", "type": "finder", "value": "Danish Siddiqui (djvirus, independently)"}, {"lang": "en", "type": "finder", "value": "Markus Magnuson (independently)"}, {"lang": "en", "type": "finder", "value": "Haruki Oyama (Waseda University, independently)"}], "descriptions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<p>The fix for <a target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/security.html#CVE-2025-68161\">CVE-2025-68161</a> was incomplete: it addressed hostname verification only when enabled via the <a target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName\"><code>log4j2.sslVerifyHostName</code></a> system property, but not when configured through the <code><a target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName\">verifyHostName</a></code> attribute of the <code>&lt;Ssl&gt;</code> element.</p><p>Although the <code>verifyHostName</code> 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.</p><p>A network-based attacker may be able to perform a man-in-the-middle attack when <strong>all</strong> of the following conditions are met:</p><ol><li>An SMTP, Socket, or Syslog appender is in use.</li><li>TLS is configured via a nested <code>&lt;Ssl&gt;</code> element.</li><li>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.</li></ol><p>This issue does not affect users of the HTTP appender, which uses a separate <code><a target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName\">verifyHostname</a></code> attribute that was not subject to this bug and verifies host names by default.</p><p>Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.</p>"}], "value": "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": [{"cvssV4_0": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "NONE", "attackVector": "NETWORK", "baseScore": 6.3, "baseSeverity": "MEDIUM", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "LOW", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "vectorString": "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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "LOW", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}]}, {"other": {"content": {"text": "moderate"}, "type": "Textual description of severity"}}], "problemTypes": [{"descriptions": [{"cweId": "CWE-297", "description": "CWE-297 Improper Validation of Certificate with Host Mismatch", "lang": "en", "type": "CWE"}]}], "providerMetadata": {"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "shortName": "apache", "dateUpdated": "2026-04-10T15:36:19.740Z"}, "references": [{"tags": ["patch"], "url": "https://github.com/apache/logging-log4j2/pull/4075"}, {"tags": ["vendor-advisory"], "url": "https://logging.apache.org/security.html#CVE-2026-34477"}, {"tags": ["vendor-advisory"], "url": "https://logging.apache.org/cyclonedx/vdr.xml"}, {"tags": ["related"], "url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName"}, {"tags": ["vendor-advisory"], "url": "https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4"}], "source": {"discovery": "EXTERNAL"}, "timeline": [{"lang": "en", "time": "2025-12-20T19:05:00.000Z", "value": "Vulnerability reported by Samuli Leinonen"}, {"lang": "en", "time": "2025-12-30T22:57:00.000Z", "value": "Candidate patch shared internally by Piotr P. Karwasz"}, {"lang": "en", "time": "2026-02-25T19:35:00.000Z", "value": "Independent report received from Naresh Kandula"}, {"lang": "en", "time": "2026-03-01T23:01:00.000Z", "value": "Independent report received from Vitaly Simonovich"}, {"lang": "en", "time": "2026-03-02T06:31:00.000Z", "value": "Independent report received from Raijuna"}, {"lang": "en", "time": "2026-03-08T18:17:00.000Z", "value": "Independent report received from Danish Siddiqui"}, {"lang": "en", "time": "2026-03-19T09:46:00.000Z", "value": "Independent report received from Markus Magnuson"}, {"lang": "en", "time": "2026-03-21T11:13:00.000Z", "value": "Independent report received from Haruki Oyama"}, {"lang": "en", "time": "2026-03-24T19:46:00.000Z", "value": "Fix shared publicly by Piotr P. Karwasz as pull request #4075"}, {"lang": "en", "time": "2026-03-28T11:19:00.000Z", "value": "Log4j 2.25.4 released"}], "title": "Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass", "x_generator": {"engine": "Vulnogram 0.2.0"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2026-04-10T17:36:46.652477Z", "id": "CVE-2026-34477", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-04-10T17:38:57.154Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2026-34477", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-04-10T17:36:46.652477Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-04-10T17:38:37.230Z"}}], "cna": {"title": "Apache Log4j Core: verifyHostName attribute silently ignored in TLS configuration, allowing hostname verification bypass", "source": {"discovery": "EXTERNAL"}, "credits": [{"lang": "en", "type": "finder", "value": "Samuli Leinonen (original reporter)"}, {"lang": "en", "type": "finder", "value": "Naresh Kandula (independently)"}, {"lang": "en", "type": "finder", "value": "Vitaly Simonovich (independently)"}, {"lang": "en", "type": "finder", "value": "Raijuna (independently)"}, {"lang": "en", "type": "finder", "value": "Danish Siddiqui (djvirus, independently)"}, {"lang": "en", "type": "finder", "value": "Markus Magnuson (independently)"}, {"lang": "en", "type": "finder", "value": "Haruki Oyama (Waseda University, independently)"}], "metrics": [{"format": "CVSS", "cvssV4_0": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 6.3, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "valueDensity": "NOT_DEFINED", "vectorString": "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", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "HIGH", "attackRequirements": "NONE", "privilegesRequired": "NONE", "subIntegrityImpact": "LOW", "vulnIntegrityImpact": "NONE", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "LOW", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}, {"other": {"type": "Textual description of severity", "content": {"text": "moderate"}}}], "affected": [{"cpes": ["cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*"], "vendor": "Apache Software Foundation", "product": "Apache Log4j Core", "versions": [{"status": "affected", "version": "2.12.0", "lessThan": "2.25.4", "versionType": "maven"}, {"status": "affected", "version": "3.0.0-alpha1", "versionType": "maven", "lessThanOrEqual": "3.0.0-beta3"}], "packageURL": "pkg:maven/org.apache.logging.log4j/log4j-core", "packageName": "org.apache.logging.log4j:log4j-core", "collectionURL": "https://repo.maven.apache.org/maven2", "defaultStatus": "unaffected"}], "timeline": [{"lang": "en", "time": "2025-12-20T19:05:00.000Z", "value": "Vulnerability reported by Samuli Leinonen"}, {"lang": "en", "time": "2025-12-30T22:57:00.000Z", "value": "Candidate patch shared internally by Piotr P. Karwasz"}, {"lang": "en", "time": "2026-02-25T19:35:00.000Z", "value": "Independent report received from Naresh Kandula"}, {"lang": "en", "time": "2026-03-01T23:01:00.000Z", "value": "Independent report received from Vitaly Simonovich"}, {"lang": "en", "time": "2026-03-02T06:31:00.000Z", "value": "Independent report received from Raijuna"}, {"lang": "en", "time": "2026-03-08T18:17:00.000Z", "value": "Independent report received from Danish Siddiqui"}, {"lang": "en", "time": "2026-03-19T09:46:00.000Z", "value": "Independent report received from Markus Magnuson"}, {"lang": "en", "time": "2026-03-21T11:13:00.000Z", "value": "Independent report received from Haruki Oyama"}, {"lang": "en", "time": "2026-03-24T19:46:00.000Z", "value": "Fix shared publicly by Piotr P. Karwasz as pull request #4075"}, {"lang": "en", "time": "2026-03-28T11:19:00.000Z", "value": "Log4j 2.25.4 released"}], "references": [{"url": "https://github.com/apache/logging-log4j2/pull/4075", "tags": ["patch"]}, {"url": "https://logging.apache.org/security.html#CVE-2026-34477", "tags": ["vendor-advisory"]}, {"url": "https://logging.apache.org/cyclonedx/vdr.xml", "tags": ["vendor-advisory"]}, {"url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName", "tags": ["related"]}, {"url": "https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4", "tags": ["vendor-advisory"]}], "x_generator": {"engine": "Vulnogram 0.2.0"}, "descriptions": [{"lang": "en", "value": "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.", "supportingMedia": [{"type": "text/html", "value": "<p>The fix for <a target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/security.html#CVE-2025-68161\">CVE-2025-68161</a> was incomplete: it addressed hostname verification only when enabled via the <a target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName\"><code>log4j2.sslVerifyHostName</code></a> system property, but not when configured through the <code><a target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName\">verifyHostName</a></code> attribute of the <code>&lt;Ssl&gt;</code> element.</p><p>Although the <code>verifyHostName</code> 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.</p><p>A network-based attacker may be able to perform a man-in-the-middle attack when <strong>all</strong> of the following conditions are met:</p><ol><li>An SMTP, Socket, or Syslog appender is in use.</li><li>TLS is configured via a nested <code>&lt;Ssl&gt;</code> element.</li><li>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.</li></ol><p>This issue does not affect users of the HTTP appender, which uses a separate <code><a target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName\">verifyHostname</a></code> attribute that was not subject to this bug and verifies host names by default.</p><p>Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.</p>", "base64": false}]}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-297", "description": "CWE-297 Improper Validation of Certificate with Host Mismatch"}]}], "providerMetadata": {"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "shortName": "apache", "dateUpdated": "2026-04-10T15:36:19.740Z"}}}, "cveMetadata": {"cveId": "CVE-2026-34477", "state": "PUBLISHED", "dateUpdated": "2026-04-10T17:38:57.154Z", "dateReserved": "2026-03-28T11:26:04.052Z", "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09", "datePublished": "2026-04-10T15:36:19.740Z", "assignerShortName": "apache"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"collectionURL": "https://repo.maven.apache.org/maven2", "cpes": ["cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*"], "defaultStatus": "unaffected", "packageName": "org.apache.logging.log4j:log4j-core", "packageURL": "pkg:maven/org.apache.logging.log4j/log4j-core", "product": "Apache Log4j Core", "vendor": "Apache Software Foundation", "versions": [{"lessThan": "2.25.4", "status": "affected", "version": "2.12.0", "versionType": "maven"}, {"lessThanOrEqual": "3.0.0-beta3", "status": "affected", "version": "3.0.0-alpha1", "versionType": "maven"}]}], "source": "security@apache.org"}], "configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*", "matchCriteriaId": "2C60BA8E-5300-45BD-AB82-2B8AD28917CD", "versionEndExcluding": "2.25.4", "versionStartIncluding": "2.12.0", "vulnerable": true}, {"criteria": "cpe:2.3:a:apache:log4j:3.0.0:alpha1:*:*:*:*:*:*", "matchCriteriaId": "5EE518C3-2F43-40FF-B754-C340B7003FC7", "vulnerable": true}, {"criteria": "cpe:2.3:a:apache:log4j:3.0.0:alpha1_rc1:*:*:*:*:*:*", "matchCriteriaId": "6D2A01C1-D56C-4198-8ADB-11739F791E2B", "vulnerable": true}, {"criteria": "cpe:2.3:a:apache:log4j:3.0.0:alpha1_rc2:*:*:*:*:*:*", "matchCriteriaId": "D6F8BD61-DD30-4D64-842C-850E5B117036", "vulnerable": true}, {"criteria": "cpe:2.3:a:apache:log4j:3.0.0:beta1:*:*:*:*:*:*", "matchCriteriaId": "ED00C38D-27EA-489C-9A2B-3594ACA8A3C5", "vulnerable": true}, {"criteria": "cpe:2.3:a:apache:log4j:3.0.0:beta2:*:*:*:*:*:*", "matchCriteriaId": "8794D719-1D90-4378-B48B-698EA40FBFB2", "vulnerable": true}, {"criteria": "cpe:2.3:a:apache:log4j:3.0.0:beta3:*:*:*:*:*:*", "matchCriteriaId": "74C9FCBD-ECAD-4C29-B97A-2B9D97C0FC1F", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "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."}, {"lang": "es", "value": "La correcci\u00f3n para CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 fue incompleta: abordaba la verificaci\u00f3n del nombre de host solo cuando se habilitaba a trav\u00e9s de la propiedad del sistema log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName, pero no cuando se configuraba a trav\u00e9s del atributo verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName del elemento [Ssl].\n\nAunque el atributo de configuraci\u00f3n verifyHostName se introdujo en Log4j Core 2.12.0, fue ignorado silenciosamente en todas las versiones hasta la 2.25.3, dejando las conexiones TLS vulnerables a la intercepci\u00f3n independientemente del valor configurado.\n\nUn atacante basado en red podr\u00eda realizar un ataque man-in-the-middle cuando se cumplen todas las siguientes condiciones:\n\n * Se est\u00e1 utilizando un appender SMTP, Socket o Syslog.\n * TLS est\u00e1 configurado a trav\u00e9s de un elemento [Ssl] anidado.\n * El atacante puede presentar un certificado emitido por una CA de confianza para el almac\u00e9n de confianza configurado del appender, o por el almac\u00e9n de confianza predeterminado de Java si no hay ninguno configurado.\nEste problema no afecta a los usuarios del appender HTTP, que utiliza un atributo verifyHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName separado que no estaba sujeto a este error y verifica los nombres de host por defecto.\n\nSe aconseja a los usuarios actualizar a Apache Log4j Core 2.25.4, que corrige este problema."}], "id": "CVE-2026-34477", "lastModified": "2026-10-26T22:10:00.163", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 5.9, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N", "version": "3.1"}, "exploitabilityScore": 2.2, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}], "cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "NONE", "attackVector": "NETWORK", "availabilityRequirement": "NOT_DEFINED", "baseScore": 6.3, "baseSeverity": "MEDIUM", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "LOW", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "vectorString": "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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "LOW", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "security@apache.org", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-34477", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-04-10T17:36:46.652477Z", "version": "2.0.3"}}]}, "published": "2026-04-10T16:16:30.843", "references": [{"source": "security@apache.org", "tags": ["Issue Tracking", "Patch"], "url": "https://github.com/apache/logging-log4j2/pull/4075"}, {"source": "security@apache.org", "tags": ["Mailing List"], "url": "https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4"}, {"source": "security@apache.org", "tags": ["Vendor Advisory"], "url": "https://logging.apache.org/cyclonedx/vdr.xml"}, {"source": "security@apache.org", "tags": ["Product"], "url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName"}, {"source": "security@apache.org", "tags": ["Vendor Advisory"], "url": "https://logging.apache.org/security.html#CVE-2026-34477"}], "sourceIdentifier": "security@apache.org", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-297"}], "source": "security@apache.org", "type": "Secondary"}, {"description": [{"lang": "en", "value": "CWE-295"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "org.apache.logging.log4j/log4j-core: Apache Log4j Core: Man-in-the-middle attack due to incomplete hostname verification", "id": "2457319", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2457319"}, "csaw": false, "cvss3": {"cvss3_base_score": "6.8", "cvss3_scoring_vector": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N", "status": "draft"}, "cwe": "CWE-295", "details": ["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."], "mitigation": {"lang": "en:us", "value": "Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability."}, "name": "CVE-2026-34477", "package_state": [{"cpe": "cpe:/a:redhat:ai_inference_server:3", "fix_state": "Fix deferred", "package_name": "redhat-user-workloads/rhaiis-cuda-ubi9-3-2-2", "product_name": "Red Hat AI Inference Server"}, {"cpe": "cpe:/a:redhat:ai_inference_server:3", "fix_state": "Fix deferred", "package_name": "redhat-user-workloads/rhaiis-cuda-ubi9-3-3", "product_name": "Red Hat AI Inference Server"}, {"cpe": "cpe:/a:redhat:amq_broker:7", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat AMQ Broker 7"}, {"cpe": "cpe:/a:redhat:camel_spring_boot:4", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat build of Apache Camel for Spring Boot 4"}, {"cpe": "cpe:/a:redhat:apache_camel_hawtio:4", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat build of Apache Camel - HawtIO 4"}, {"cpe": "cpe:/a:redhat:service_registry:2", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat build of Apicurio Registry 2"}, {"cpe": "cpe:/a:redhat:apicurio_registry:3", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat build of Apicurio Registry 3"}, {"cpe": "cpe:/a:redhat:optaplanner:::el6", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat build of OptaPlanner 8"}, {"cpe": "cpe:/a:redhat:jboss_data_grid:8", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat Data Grid 8"}, {"cpe": "cpe:/a:redhat:jboss_data_grid:8", "fix_state": "Fix deferred", "package_name": "log4j-core-test", "product_name": "Red Hat Data Grid 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "log4j:2/log4j", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "pki-core:10.6/resteasy", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "pki-deps:10.6/resteasy", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "log4j", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "resteasy", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "bazel7", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "bazel8", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "redhat-user-workloads/bootc-cuda-3-3", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "redhat-user-workloads/bootc-cuda-aws-3-3", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "redhat-user-workloads/bootc-cuda-azure-3-3", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:enterprise_linux_ai:3", "fix_state": "Fix deferred", "package_name": "redhat-user-workloads/bootc-cuda-gcp-3-3", "product_name": "Red Hat Enterprise Linux AI (RHEL AI) 3"}, {"cpe": "cpe:/a:redhat:jboss_fuse:7", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat Fuse 7"}, {"cpe": "cpe:/a:redhat:jboss_enterprise_application_platform:7", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat JBoss Enterprise Application Platform 7"}, {"cpe": "cpe:/a:redhat:jboss_enterprise_application_platform:8", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat JBoss Enterprise Application Platform 8"}, {"cpe": "cpe:/a:redhat:jboss_enterprise_application_platform:8", "fix_state": "Fix deferred", "package_name": "log4j-core-test", "product_name": "Red Hat JBoss Enterprise Application Platform 8"}, {"cpe": "cpe:/a:redhat:jbosseapxp", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat JBoss Enterprise Application Platform Expansion Pack"}, {"cpe": "cpe:/a:redhat:jbosseapxp", "fix_state": "Fix deferred", "package_name": "log4j-core-test", "product_name": "Red Hat JBoss Enterprise Application Platform Expansion Pack"}, {"cpe": "cpe:/a:redhat:jboss_enterprise_web_server:6", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "Red Hat JBoss Web Server 6"}, {"cpe": "cpe:/a:redhat:offline_knowledge_portal:1", "fix_state": "Fix deferred", "package_name": "redhat-user-workloads/rhokp-core-encrypted", "product_name": "Red Hat Offline Knowledge Portal"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-modelmesh-rhel8", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-modelmesh-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-pipeline-runtime-datascience-cpu-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-pipeline-runtime-pytorch-cuda-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-pipeline-runtime-pytorch-rocm-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-pipeline-runtime-tensorflow-cuda-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-pipeline-runtime-tensorflow-rocm-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-vllm-cuda-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-vllm-gaudi-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-workbench-jupyter-datascience-cpu-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-workbench-jupyter-pytorch-cuda-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-workbench-jupyter-pytorch-rocm-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-workbench-jupyter-tensorflow-cuda-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-workbench-jupyter-tensorflow-rocm-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:openshift_ai", "fix_state": "Fix deferred", "package_name": "rhoai/odh-workbench-jupyter-trustyai-cpu-py312-rhel9", "product_name": "Red Hat OpenShift AI (RHOAI)"}, {"cpe": "cpe:/a:redhat:amq_streams:2", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "streams for Apache Kafka 2"}, {"cpe": "cpe:/a:redhat:amq_streams:3", "fix_state": "Fix deferred", "package_name": "log4j-core", "product_name": "streams for Apache Kafka 3"}], "public_date": "2026-04-10T15:36:19Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2026-34477\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-34477\nhttps://github.com/apache/logging-log4j2/pull/4075\nhttps://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4\nhttps://logging.apache.org/cyclonedx/vdr.xml\nhttps://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName\nhttps://logging.apache.org/security.html#CVE-2026-34477"], "threat_severity": "Moderate"}

{"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\u2011in\u2011the\u2011middle 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\u2019s <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\u2011295 (Improper Authentication) and CWE\u2011297 (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\u2011based attacker who can present a certificate trusted by the application\u2019s trust store, or the default Java trust store, can meet the conditions and mount a man\u2011in\u2011the\u2011middle 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"]}