The Apache Logging Services PMC has received the security report
referenced below. After analysis, we classified it as HARDENING: not a
vulnerability, but a defense-in-depth improvement that is already
planned. In the interest of transparency and so that the community and
other researchers can benefit from the analysis, we are disclosing a
summary of it.
Report reference (Logging Services PMC / security archive):
https://lists.apache.org/thread/0ywhhb4r4tlqlvwpd647nl1tbpbo6olt
Reporter: Yu Bao from PayPal Cybersecurity Team
Disposition: HARDENING -- not a vulnerability; no CVE; tracked in a
public issue
TLP:CLEAR (this message may be redistributed without restriction)
The reporter was informed of this classification and of our intent to
publish this summary.
== Summary of the report ==
The `verifyHostName` attribute of the `Ssl` element used by the Socket,
Syslog and SMTP appenders, and the `log4j2.sslVerifyHostName` property
used when Log4j fetches its configuration over HTTPS, default to
`false`. Unless the operator sets them explicitly, a TLS connection
accepts any certificate trusted by the configured (or default) trust
store, regardless of the host name it was issued for. The reporter noted
that the HTTP appender's own `verifyHostname` attribute defaults to
`true`, that CVE-2026-34477 documents this asymmetry, and that an
operator who configured a restrictive `TrustStore` may reasonably
believe the connection is fully verified. The reporter demonstrated the
behavior against a local HTTPS server presenting a certificate for
another host name (CWE-297) and proposed defaulting the setting to
`true` with an explicit opt-out.
== PMC assessment ==
This is NOT a vulnerability, but we agree with the recommendation. The
default is documented on the `Ssl` element and on the property, and TLS
parameters are operator-controlled configuration, which the threat model
treats as trusted:
https://logging.apache.org/security.html#threat-common-sources-configuration
CVE-2025-68161 and CVE-2026-34477 were different in nature: in both
cases the operator had explicitly enabled host name verification and
Log4j silently ignored the setting. A documented default that the
operator can change is a weakness in our defaults, not a defect in the
enforcement of a configured control.
== Hardening ==
The PMC decided in August 2024 to switch the default to `true` and to
align the HTTP appender with the `Ssl` element, as part of a broader
clean-up of the TLS configuration:
https://github.com/apache/logging-log4j2/issues/2792 (see also
https://github.com/apache/logging-log4j2/issues/2792#issuecomment-5727662396)
https://github.com/apache/logging-log4j2/pull/3902 (draft)
The change has stalled because it is breaking for deployments whose
certificates do not match the configured host name, and because the SMTP
appender only connects when an `ERROR` event is logged, so such
deployments would notice the breakage long after upgrading. Until the
new default ships, we recommend that every deployment using TLS with
these appenders sets `verifyHostName="true"` on the `Ssl` element, or
`log4j2.sslVerifyHostName=true` when TLS is configured through
properties. We will add a warning to that effect in the manual.
== References ==
Threat model:
https://logging.apache.org/security.html
`Ssl` element reference:
https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration
Prior advisories:
https://logging.apache.org/security.html#CVE-2025-68161
https://logging.apache.org/security.html#CVE-2026-34477
Questions and follow-up are welcome on this list or GitHub Discussions.
On behalf of the Apache Logging Services PMC,
Piotr P. Karwasz
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
