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/05gzh2k9f9y4zhor2bp0tr0z50kkbq4x
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 ==
`Rfc5424Layout#appendMessageId` writes the `type` of a
`StructuredDataMessage` into the `MSGID` header field without character
validation, and the `SD-ID` field is emitted the same way. A `type`
containing a newline therefore terminates the syslog record, and the
remainder is read as a second, forged record by a newline-framed
consumer such as a file or an RFC 6587 TCP relay. The reporter presented
this as a residual of GHSA-445c-vh5m-36rj (CVE-2026-34478), whose fix in
2.25.4 sanitized structured-data parameter names and values but not
`MSGID` or `SD-ID`, noted that no configuration option escapes `MSGID`,
and proposed applying the parameter-name sanitization and the RFC 5424
PRINTUSASCII constraints to both fields at emission time.
== PMC assessment ==
This is NOT a vulnerability. `MSGID` and `SD-ID` are named explicitly in
our threat model as structural identifiers: developer-controlled inputs,
expected to be compile-time constants like logger names or format
strings, that the framework trusts. Populating them from untrusted data
is application misuse and out of scope:
https://logging.apache.org/security.html#threat-common-sources-structural
The premise of an incomplete fix does not hold either. CVE-2026-34478
was not about missing sanitization of the record: two configuration
attributes of `Rfc5424Layout` had been silently renamed, so the newline
escaping and TLS framing that operators had explicitly enabled stopped
working, and the fix restored them. Parameter names were sanitized on
that occasion because they may carry thread context keys, whose
classification is an open question in the threat model
(https://github.com/apache/logging-log4j2/discussions/4132). `MSGID` and
`SD-ID` were left alone on purpose.
This report is the sixth on the same two fields since December 2025, and
every one received the same answer. In chronological order: a YesWeHack
report of 19 December 2025, closed as informative on 23 January 2026 and
turned into the public issue below; a YesWeHack report of 30 March 2026,
closed as out of scope the same day; an e-mail report of 28 May 2026,
answered on 30 June 2026, which prompted the threat model revision that
names `MSGID` and `SD-ID` explicitly
(https://github.com/apache/logging-site/pull/32, merged 25 June 2026); a
pull request of 3 August 2026 proposing exactly this sanitization,
closed on 27 August 2026 on the grounds above; an e-mail report of 4
August 2026, answered the same day; and the present report.
https://github.com/apache/logging-log4j2/pull/4235
The threat model allows the framework to reject a malformed structural
identifier rather than silently alter it. Rather than mutating output at
emission time, we prefer fail-fast validation in the constructors of
`StructuredDataId` and `StructuredDataMessage`, with clearer
documentation of the expected syntax, which is tracked in:
https://github.com/apache/logging-log4j2/issues/4051
== References ==
Threat model:
https://logging.apache.org/security.html
Security FAQ, syslog and RFC 5424 layouts:
https://logging.apache.org/security/faq.html#crlf-injection-rfc5424-layout
CVE-2026-34478:
https://logging.apache.org/security.html#CVE-2026-34478
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]
