CVE-2026-34480: Apache Log4j Core XXE Vulnerability

CVE-2026-34480 Overview

Apache Log4j Core's XmlLayout component, in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification when producing XML output. This Missing Input Sanitization vulnerability (CWE-116) occurs whenever a log message or MDC (Mapped Diagnostic Context) value contains invalid XML characters, resulting in malformed XML documents that downstream log-processing systems cannot parse correctly.

The impact of this vulnerability varies depending on the StAX (Streaming API for XML) implementation in use. When using the JRE built-in StAX implementation, forbidden characters are silently written to the output, producing malformed XML that conforming parsers must reject with a fatal error. This can cause downstream log-processing systems to drop affected records. When using alternative StAX implementations like Woodstox (a transitive dependency of the Jackson XML Dataformat module), an exception is thrown during the logging call, preventing the log event from being delivered to its intended appender.

Critical Impact
Log messages containing forbidden XML characters can cause log record loss, logging system failures, or denial of log processing in downstream systems, potentially hiding malicious activity or disrupting security monitoring.

Affected Products

Apache Log4j Core versions up to and including 2.25.3
Applications using XmlLayout with JRE built-in StAX implementation
Applications using XmlLayout with Woodstox or alternative StAX implementations

Discovery Timeline

April 10, 2026 - CVE-2026-34480 published to NVD
April 13, 2026 - Last updated in NVD database

Technical Details for CVE-2026-34480

Vulnerability Analysis

This vulnerability stems from improper encoding of output (CWE-116) within the XmlLayout component of Apache Log4j Core. The XML 1.0 specification defines a restricted character set that is valid within XML documents. Characters outside this set—such as certain control characters in the ranges U+0000-U+0008, U+000B-U+000C, U+000E-U+001F, and others—must be either escaped, encoded, or removed before inclusion in XML content.

The XmlLayout implementation prior to version 2.25.4 did not perform this necessary sanitization, directly writing log message content and MDC values to the XML output stream without validating character compliance. This creates two distinct failure scenarios based on the underlying StAX implementation's handling of invalid characters.

Root Cause

The root cause is the absence of character validation and sanitization logic in the XmlLayout component. When processing log events, the layout directly serializes string content to XML format without filtering or encoding characters that violate XML 1.0 character restrictions. The XmlLayout class writes log messages and context data through the StAX API without pre-processing the character stream to ensure XML compliance.

Attack Vector

An attacker can exploit this vulnerability through network-accessible attack vectors by injecting forbidden XML characters into log messages. This can be accomplished by:

User Input Injection: Submitting form data, API requests, or other user-controlled input containing forbidden characters that gets logged by the application
MDC Manipulation: In systems where MDC values are derived from external sources (headers, tokens, identifiers), crafting values with invalid XML characters
Protocol Data: Sending network traffic with binary or control characters that gets captured in application logs

The attack requires no authentication or user interaction. When successful, this causes either silent log corruption (with JRE StAX) or logging exceptions (with Woodstox), both of which can obscure malicious activity by disrupting the logging pipeline.

When JRE built-in StAX is used, the malformed XML output will be silently accepted during write but will cause parsing failures in downstream log aggregation systems, SIEM platforms, or analysis tools that consume the XML logs.

When alternative StAX implementations like Woodstox are in use, the exception thrown during the logging call prevents the log event from reaching its intended destination, with the event only appearing in Log4j's internal status logger—which is often not monitored.

Detection Methods for CVE-2026-34480

Indicators of Compromise

XML parsing errors in downstream log processing systems or SIEM platforms consuming Log4j XML output
Missing log entries that correlate with user-controllable input containing special characters
Exceptions in application logs from Woodstox or similar StAX implementations during logging operations
Gaps in log sequences that correspond to requests containing binary or control characters

Detection Strategies

Monitor log aggregation pipelines for XML parsing failures or rejected log batches from applications using Log4j XmlLayout
Implement alerting on Log4j internal status logger entries indicating exceptions during log event processing
Audit applications for Log4j Core versions 2.25.3 or earlier using dependency scanning tools
Review application configurations for XmlLayout usage in log4j2.xml or programmatic configurations

Monitoring Recommendations

Configure monitoring for log processing pipeline health metrics, including rejected or malformed log entries
Implement integrity checks comparing expected versus actual log volume from applications using XmlLayout
Set up alerts for sudden drops in log throughput that could indicate logging failures due to this vulnerability
Enable and monitor Log4j's internal status logger to detect exceptions during logging operations

How to Mitigate CVE-2026-34480

Immediate Actions Required

Upgrade Apache Log4j Core to version 2.25.4 or later, which includes proper sanitization of forbidden XML characters
Audit all applications using Log4j to identify those configured with XmlLayout
Verify log processing pipelines are receiving expected log volumes from affected applications
Review downstream log consumers for accumulated XML parsing errors that may indicate exploitation attempts

Patch Information

Apache has released Log4j Core version 2.25.4 which corrects this issue by sanitizing forbidden characters before XML output. The fix ensures that any characters not permitted by the XML 1.0 specification are properly handled before being written to the output stream. Users should upgrade to this version immediately.

For additional details, refer to the Apache Security Advisory, the GitHub Pull Request #4077 containing the fix, and the Apache Mailing List announcement.

Workarounds

Switch from XmlLayout to an alternative layout format such as JsonLayout or PatternLayout until the upgrade can be completed
Implement input sanitization at the application layer to filter forbidden XML characters before they reach the logging framework
Deploy log processing pipelines with fault-tolerant parsing that can handle and quarantine malformed XML entries
Configure alternative StAX implementations with error handling that logs failures to a monitored location

bash

# Verify current Log4j Core version in Maven projects
mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

# Upgrade Log4j Core in pom.xml to patched version
# Update version to 2.25.4 or later:
# <dependency>
#   <groupId>org.apache.logging.log4j</groupId>
#   <artifactId>log4j-core</artifactId>
#   <version>2.25.4</version>
# </dependency>

# For Gradle projects, check dependencies
gradle dependencies --configuration runtimeClasspath | grep log4j-core