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 worth making. 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/13ygxko8h9036jjt9wjwyttj1cm4drxh
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 ==
When an `Ssl` element of a Socket, Syslog, SMTP, or HTTP appender
contains a `TrustStore` element that cannot be loaded (missing or
corrupted file, wrong password, permission error),
`TrustStoreConfiguration` throws, the plugin builder logs an error and
returns `null` for the element, and `SslConfiguration` is built with no
trust store. The resulting `SSLContext` is initialized with `null` trust
managers and therefore uses the JVM's default trust store. The reporter
argued that this fails open (CWE-636): a deployer who restricted trust
to a private CA silently ends up trusting every public CA in the JVM
bundle, with a single startup-time status logger error as the only
symptom. The reporter proposed failing to build the `Ssl` element
whenever a `TrustStore` child is present but cannot be loaded.
== PMC assessment ==
This is NOT a vulnerability. The trigger is an invalid configuration.
Configuration files and the resources they reference are trusted input
under our threat model, and keeping them correct is the deployer's
responsibility; an adversary able to corrupt the trust store or its
password already has write access to configuration and is out of scope:
https://logging.apache.org/security.html#threat-common-sources-configuration
The failure is reported at ERROR level by the status logger at
configuration time, so unlike CVE-2026-34477, where a valid setting was
ignored without any diagnostic, no configured control is silently
discarded. The fallback, the JVM default trust store, is the documented
behavior of an `Ssl` element without a `TrustStore` child; it is not the
absence of certificate validation.
== Hardening ==
We nevertheless agree that failing closed is the better behavior for a
security-relevant element. Two mechanisms produce the current result:
the plugin system does not distinguish a child element that is absent
from one that failed to build, so `SslConfiguration` receives `null` in
both cases, and `SslConfiguration#createSslContext` falls back to the
default `SSLContext` when initialization fails. We opened a public issue
to change both, in the context of the ongoing TLS configuration rework:
https://github.com/apache/logging-log4j2/issues/4332
https://github.com/apache/logging-log4j2/issues/2792
Until then, deployers who rely on a restrictive trust store should
monitor the status logger output for errors at startup, for instance by
setting `status="ERROR"` on the `Configuration` element and forwarding
the status output to their monitoring.
== References ==
Threat model:
https://logging.apache.org/security.html
TLS configuration of network appenders:
https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration
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]
