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/7mo7lwngw4ld9w0gy0dbfsdxfff8xgf4
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 ==
Since Log4j Core 2.25.0, the Pattern Layout options
`%rEx{short.className}`, `%rEx{short.methodName}`,
`%rEx{short.lineNumber}` and `%rEx{short.fileName}` are rendered by
`ThrowableInvertedPropertyRendererFactory`, which reads the first stack
frame of the root cause without checking that the stack trace is
non-empty. When it is empty, an `ArrayIndexOutOfBoundsException` is
thrown during rendering; with the default `ignoreExceptions="true"` the
event is dropped by the appender, with `ignoreExceptions="false"` an
`AppenderLoggingException` propagates to the caller. The non-inverted
`%ex{short.*}` renderer has the missing guard. The reporter argued that
empty stack traces are attacker-influenceable, because HotSpot's default
`-XX:+OmitStackTraceInFastThrow` strips the stack trace of implicit
exceptions thrown repeatedly at the same site, so an attacker who can
trigger tens of thousands of such exceptions could suppress subsequent
log events on the affected pattern, and that the loss is silent.
== PMC assessment ==
This is NOT a vulnerability, but the code is wrong and will be fixed.
Under our threat model, the in-scope adversary reaches the logging
framework exclusively through log content: messages, the string
representation of parameters, and thread context values. The trigger
here is the shape of a `Throwable` object, which is chosen by the
application and trusted like any other object passed to a log statement:
https://logging.apache.org/security.html#threat-common-adversary
Driving the JVM into its fast-throw state at a given exception site
manipulates application state, not log content; whether that is
reachable depends on the application, and an application that lets a
client trigger tens of thousands of identical exceptions has a problem
well beyond logging. This differs from CVE-2026-34480, where forbidden
characters in the logged content caused the loss.
The loss is also not silent: the exception is routed to the appender's
error handler, and the default handler reports it to the status logger
at ERROR level, rate-limited to three occurrences and then one every
five minutes.
== Fix ==
The inverted renderer will get the same guard as its non-inverted
counterpart, rendering an empty value when the root cause has no stack
frames:
https://github.com/apache/logging-log4j2/issues/4334
Users of the affected patterns who log exceptions with programmatically
emptied stack traces, or who run with `-XX:+OmitStackTraceInFastThrow`
on hot exception paths, may want to use `%ex{short.*}` until the fix is
released.
== References ==
Threat model:
https://logging.apache.org/security.html
Pattern Layout exception converters:
https://logging.apache.org/log4j/2.x/manual/pattern-layout.html#converter-exception-property
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]
