[GHSA-3pxv-7cmr-fjr4] Apache Log4j Core's XmlLayout fails to sanitize characters

[ppkarwasz]

Updates

• Affected products
• Description
• Summary

Comments

• Fixed formatting, based on the HTML version in the CVE record: https://www.cve.org/CVERecord?id=CVE-2026-34480
• Fixed affected ranges: it is lessThanOrEqual, not lessThan version 3.0.0-beta3.

[Copilot]

Pull request overview

Updates the GHSA advisory text for CVE-2026-34480 (Log4j Core XmlLayout) to better reflect the CVE record formatting and correct the affected version range semantics.

Changes:

• Rewrites the advisory summary and details with improved formatting (Markdown links/bullets) aligned to the CVE HTML record.
• Adjusts the affected 3.x pre-release range to use last_affected: 3.0.0-beta3 instead of fixed: 3.0.0-beta3.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The summary says "unescaped XML 1.0 forbidden characters", but XML 1.0 forbidden characters generally can’t be made valid via escaping—Log4j needs to sanitize/remove/replace them. Consider rewording to "unsanitized"/"unsanitized forbidden characters" to avoid implying escaping is a viable fix.

Suggested change

	"summary": "Apache Log4j Core: Silent log event loss in XmlLayout due to unescaped XML 1.0 forbidden characters",
	"summary": "Apache Log4j Core: Silent log event loss in XmlLayout due to unsanitized XML 1.0 forbidden characters",

[ppkarwasz]

This is the original summary we submitted, but the suggestion makes sense.

[Copilot]

Minor grammar: add punctuation after the XML 1.0 specification link (e.g., ") , producing…" or rephrase) so the opening sentence reads cleanly.

Suggested change

"details": "Apache Log4j Core's [`XmlLayout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout), in versions up to and including 2.25.3, fails to sanitize characters forbidden by the [XML 1.0 specification](https://www.w3.org/TR/xml/#charsets) producing invalid XML output whenever a log message or MDC value contains such characters.\n\nThe impact depends on the StAX implementation in use:\n\n * **JRE built-in StAX**: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records.\n * **Alternative StAX implementations** (e.g., [Woodstox](https://github.com/FasterXML/woodstox), a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.",

"details": "Apache Log4j Core's [`XmlLayout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout), in versions up to and including 2.25.3, fails to sanitize characters forbidden by the [XML 1.0 specification](https://www.w3.org/TR/xml/#charsets), producing invalid XML output whenever a log message or MDC value contains such characters.\n\nThe impact depends on the StAX implementation in use:\n\n * **JRE built-in StAX**: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records.\n * **Alternative StAX implementations** (e.g., [Woodstox](https://github.com/FasterXML/woodstox), a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.",

[ppkarwasz]

Makes sense