The Apache Logging Services PMC has received the security report
referenced below. After analysis, we classified it as INVALID (works as
designed). 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/qj1p37sgjm5sbj1fwwy9819d6zyw2k08
Disposition: INVALID -- works as designed; no CVE
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 ==
`MapMessageJsonFormatter#formatNumber` handles `BigDecimal`, `Double`,
`Float` and the integral primitive wrappers explicitly, but has no
branch for `BigInteger`, which falls through to a generic conversion
through `longValue()` and `doubleValue()`. In an object-valued
`MapMessage`, the values 2^63 and 2^63+1 are therefore both rendered as
`9.223372036854776E18`, and 10^400 is rendered as the string
`"Infinity"`. The `map` resolver of `JsonTemplateLayout` renders the
same values exactly. The reporter argued that distinct attacker-supplied
identifiers collapsing to one serialized value, or changing type,
affects the integrity of structured audit logs, and proposed an explicit
`BigInteger` branch.
== PMC assessment ==
This is NOT a vulnerability. Our commitment for structured layouts
concerns the structure of the document: untrusted content must not break
it. Every output in the report is well-formed JSON. The value beyond the
`long` range is a JSON number in floating-point notation, and the value
beyond the `double` range is the string `"Infinity"`, which is the
representation introduced by the fix for CVE-2026-49844 so that the
document remains valid. Loss of precision inside a JSON number is not a
structural defect: JSON does not guarantee numeric precision, and most
consumers parse numbers as IEEE 754 doubles.
This guarantee covers our layouts, not the output of `MapMessage`
methods such as `asJson()` or `asXml()`. CVE-2026-49844 was disclosed
because the JSON Template Layout relies on `MapMessage.asJson()`;
`asXml()`, which none of our layouts uses, is the responsibility of the
applications calling it.
`MapMessage` does not advertise support for `BigInteger`. Its JSON
formatter covers the numeric types of the Java language and
`BigDecimal`; any other `Number` is converted through the methods the
`Number` contract provides. The `map` resolver of `JsonTemplateLayout`
uses a general-purpose JSON writer, which is a feature of that layout,
not a guarantee of `MapMessage`.
Exact rendering of `BigInteger` in `MapMessage` would be a feature. We
will consider it if users deploying Log4j ask for it through the public
issue tracker; absent such demand, it would only add code.
== References ==
Threat model:
https://logging.apache.org/security.html
MapMessage documentation:
https://logging.apache.org/log4j/2.x/manual/messages.html#MapMessage
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]
