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/9byto6yy10djfhgs11lv4cvrmffy69l0
Reporter: Yu Bao from PayPal Cybersecurity Team
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 ==
`HtmlLayout` escapes every field through `Transform.escapeHtmlTags()`,
which neutralizes the HTML metacharacters and replaces code points that
are not valid in XML 1.0, but passes Unicode bidirectional control
characters such as U+202E (RIGHT-TO-LEFT OVERRIDE) through unchanged. A
browser rendering the page applies the Unicode Bidirectional Algorithm,
so a logged value such as a file name can be made to display in a
different visual order than the characters actually written to the page,
in the manner of the 2021 "Trojan Source" disclosure. The reporter
argued that this misdirects a human reviewer of the HTML output and
therefore falls under CWE-117, that it differs from the ANSI escape
sequence class because bidi controls are Unicode code points rather than
a terminal side channel, and proposed stripping the Bidi_Control set or
replacing it with numeric character references.
== PMC assessment ==
This is NOT a vulnerability. Our log-injection commitment for structured
layouts concerns the structure of the document we emit: untrusted
content must not break out of the element it is written into.
`HtmlLayout` honors that commitment here. The row is well-formed HTML,
the message stays inside its cell, and the characters in the file are
exactly the characters that were logged. What the report describes is
how a browser displays valid text, which is the active-sink situation
the threat model places out of scope:
https://logging.apache.org/security.html#threat-common-sinks-passive-active
We understand why this class of issue gets reported: other projects
treat it as a vulnerability, as Apache Tomcat did for ANSI escape
sequences in console logs
(https://www.cve.org/CVERecord?id=CVE-2025-55754). We do not, which is
why our threat model spells out the distinction between passive and
active sinks explicitly rather than leaving it to case-by-case judgement.
The distinction drawn from ANSI escape sequences does not hold: an
escape sequence is also a sequence of ordinary characters in the same
string and encoding. In both cases a downstream renderer gives
well-formed output a meaning of its own. The Trojan Source disclosure
reached the same conclusion in practice: the mitigations landed in the
tools that display text, such as editors, diff viewers and code hosting
platforms, not in the tools that produce it. The equivalent for an HTML
log page is the browser or a style sheet using `unicode-bidi: isolate`
or `plaintext`.
Filtering would also have no defensible boundary. Visual spoofing is not
specific to bidi controls: homoglyphs, zero-width characters, combining
characters and look-alike punctuation achieve the same effect, and the
Unicode repertoire cannot be neutralized. The marks U+200E/U+200F and
the isolate controls are used legitimately in mixed Arabic, Hebrew and
Persian text, so stripping them would corrupt correct log messages. The
threat model states that content is not validated and must not be
rejected; the layouts replace only code points the output format cannot
represent.
The proposed replacement with numeric character references such as
`‮` would not change the rendered page at all, since a browser
decodes the reference to the same code point.
== References ==
Threat model:
https://logging.apache.org/security.html
Unicode Bidirectional Algorithm (UAX #9):
https://www.unicode.org/reports/tr9/
Unicode Security Considerations (UTR #36):
https://www.unicode.org/reports/tr36/
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]
