Log4j patches XmlLayout XML-sanitization bug causing log loss

TL;DR — Log4j’s XmlLayout can emit invalid XML when untrusted data hits logs, causing downstream XML log pipelines to reject records or Log4j to drop events depending on the StAX implementation.

What happened

Apache Log4j is a widely deployed Java logging framework used in application servers, services, and platform components across JVM stacks. A GitHub-reviewed advisory for Log4j Core reports that XmlLayout fails to sanitize characters forbidden by the XML 1.0 specification, generating invalid XML output when a log message or MDC value includes those characters.

The practical impact depends on the StAX implementation:

• With the JRE built-in StAX, forbidden characters can be written to output, producing malformed XML that conforming parsers must reject — potentially causing downstream log processors to drop records.
• With alternative StAX implementations (e.g., Woodstox, commonly present transitively via Jackson XML), the logging call can throw an exception and the event may not reach its intended appender (only Log4j’s internal status logger).

This is not a classic RCE-style issue, but it’s operationally security-relevant: attackers frequently control strings that end up in logs (headers, usernames, IDs, request bodies), and “log pipeline reliability” failures can directly reduce detection and post-incident forensics quality.

Who is impacted

• Services that depend on org.apache.logging.log4j:log4j-core and use XmlLayout for any appender output.
• Systems where untrusted/attacker-controlled input is logged (directly or via MDC / Thread Context), since forbidden XML characters in those fields can trigger malformed output.
• Platforms that ingest Log4j XML logs into strict XML parsers or indexing pipelines (SIEM/observability ETL), where invalid XML can cause record rejection.
• Deployments using StAX stacks that throw during logging (e.g., Woodstox in the classpath), where exceptions can prevent delivery to the intended appender.

What to do now

• Follow vendor remediation guidance and apply the vendor’s fixed release.

  "Users are advised to upgrade to Apache Log4j Core version 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output."

• Inventory JVM services that carry org.apache.logging.log4j:log4j-core and identify where XmlLayout is configured (including shared logging config templates).
• Validate behavior in your logging pipeline after upgrading: ensure XML log ingestion/indexing no longer drops events when presented with problematic characters.
• If you cannot upgrade immediately, reduce exposure by avoiding XmlLayout for logs that include untrusted fields, or by sanitizing/normalizing those fields before they reach logging (treat this as a temporary containment step, not a substitute for the fix).