The Apache Logging Services PMC has received the security report
referenced below. After analysis, we classified it as a BUG: a real
defect, fixed through the public issue tracker, but without security
impact. 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/o974f64vgrbqvjtd0xf5vlvcrhlz87jf
Disposition: BUG -- not a vulnerability; no CVE; fixed through 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 ==
`JndiManager#getJndiManager(Properties)` accepts an explicit JNDI
environment, but the name under which the manager is cached does not
depend on it. Since managers are cached in a JVM-wide map, the first
`JndiManager` created is reused by every later caller, even one
supplying a different `InitialContextFactory`, provider URL or
credentials, and the second environment is never instantiated. The
reporter demonstrated this with two `LoggerContext` instances, each with
its own configuration and its own JMS appender bound to a different JNDI
provider: a log event emitted in the second application was delivered to
the first application's JMS destination. The reporter presented this as
a cross-application isolation failure that lets one application's
attacker-controlled log content reach another application's trusted
destination.
== PMC assessment ==
This is NOT a vulnerability, but the code is wrong and will be fixed. A
`LoggerContext` is not a security boundary in our threat model. The
model recognizes trusted users, the developers and operators of the
application, and untrusted content; applications sharing one copy of
Log4j Core in one JVM share its trust level, and an adversary who runs
code in the process or configures one of the contexts is out of scope:
https://logging.apache.org/security.html#threat-common-adversary
Both JMS destinations in the scenario are operator-configured sinks of
the same Log4j instance, so an event reaching the wrong one is a
misrouting defect rather than the crossing of a trust boundary. The PMC
took the same position in January 2026 on a report showing the Kotlin
API binding a logger to the wrong `LoggerContext` in a shared class
loader. In practice, the deployments where several logger contexts
coexist, application servers hosting several applications, ship a
separate copy of Log4j Core per application, so the context selection is
rarely exercised.
The threat model is not immutable: a future version could treat logger
contexts as isolation boundaries, but that would require users who need
the separation to justify it and to run it in production. So far the
demand has been nil. A PMC member's project that lets the applications
of a Tomcat instance share a single copy of Log4j Core with a context
per application (https://github.com/copernik-eu/log4j-tomcat/) has
attracted no interest at all.
== Fix ==
The manager name will be derived from the main JNDI parameters (initial
context factory, provider URL, URL package prefixes and principal), so
that distinct environments get distinct managers:
https://github.com/apache/logging-log4j2/issues/4339
== References ==
Threat model:
https://logging.apache.org/security.html
JMS appender documentation:
https://logging.apache.org/log4j/2.x/manual/appenders/message-queue.html#JmsAppender
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]
