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).

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.

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.