CVE-2026-34479: Apache Log4j XML Output Vulnerability

CVE-2026-34479 Overview

CVE-2026-34479 is an Improper Encoding or Escaping of Output vulnerability (CWE-116) affecting the Apache Log4j 1-to-Log4j 2 bridge component. The Log4j1XmlLayout class fails to properly escape characters that are forbidden by the XML 1.0 standard, resulting in malformed XML output. Conforming XML parsers are required to reject documents containing such forbidden characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected log records.

This vulnerability impacts organizations using the legacy Log4j 1.x compatibility features within modern Log4j 2 deployments, potentially leading to log data loss, incomplete audit trails, and disruption of security monitoring pipelines that depend on properly formatted XML logs.

Critical Impact

Downstream log processing systems may silently drop or fail to index log records containing forbidden XML characters, creating gaps in security monitoring, compliance audit trails, and incident forensics data.

Affected Products

• Apache Log4j 1-to-Log4j 2 bridge (versions prior to 2.25.4)
• Applications using Log4j1XmlLayout directly in Log4j Core 2 configuration files
• Applications using the Log4j 1 configuration compatibility layer with org.apache.log4j.xml.XMLLayout specified as the layout class

Discovery Timeline

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

Technical Details for CVE-2026-34479

Vulnerability Analysis

The root cause of CVE-2026-34479 lies in the Log4j1XmlLayout class's failure to implement proper character encoding when generating XML output. The XML 1.0 standard explicitly prohibits certain characters (including control characters in ranges 0x00-0x08, 0x0B-0x0C, 0x0E-0x1F, and others) from appearing in XML documents, even when escaped. When log messages contain these forbidden characters—which can occur through user input, binary data, or malformed strings—the resulting XML output becomes invalid and unparseable.

Two distinct user groups are affected by this vulnerability. The first group consists of users who directly configure Log4j1XmlLayout in their Log4j Core 2 configuration files. The second group includes those leveraging the Log4j 1 configuration compatibility layer with org.apache.log4j.xml.XMLLayout specified as the layout class, often as part of migration efforts from legacy Log4j 1.x deployments.

Root Cause

The vulnerability stems from improper encoding or escaping of output (CWE-116) in the Log4j1XmlLayout component. The XML generation logic does not filter or encode characters that violate XML 1.0 character restrictions before including them in the output document. This represents a failure to properly sanitize output for the target format, allowing invalid characters to propagate into generated XML documents.

Attack Vector

This vulnerability is exploitable via network-accessible attack vectors. An attacker can inject log messages containing forbidden XML characters through any application input that eventually gets logged using the affected XML layout. When these messages are processed, the resulting malformed XML will cause compliant parsers to reject the entire document or individual records, effectively achieving a denial of service against log processing infrastructure.

The attack does not require authentication or user interaction, and the complexity is low. While the direct impact on the vulnerable system's confidentiality, integrity, and availability is minimal, the downstream impact on log processing systems and security monitoring infrastructure can be significant.

For technical implementation details and the specific fix, refer to the GitHub Pull Request for Log4j2 and the Apache Security Advisory CVE-2026-34479.

Detection Methods for CVE-2026-34479

Indicators of Compromise

• XML parsing errors or fatal errors in log aggregation systems (ELK Stack, Splunk, etc.) when processing Log4j-generated XML logs
• Missing or incomplete log records in downstream systems that rely on XML log ingestion
• Error messages indicating malformed XML or invalid character references in log processing pipelines
• Unexplained gaps in log data timelines that correlate with user input containing control characters

Detection Strategies

• Monitor XML parsing error rates in log aggregation infrastructure for sudden increases or patterns
• Implement validation checks on incoming XML log data to detect and alert on malformed documents before they cause pipeline failures
• Audit application configurations for use of Log4j1XmlLayout or org.apache.log4j.xml.XMLLayout layout classes
• Review software bill of materials (SBOM) using the Apache CycloneDX VDR Document to identify affected components

Monitoring Recommendations

• Enable verbose logging on XML parsers and log aggregators to capture detailed error information when documents are rejected
• Set up alerts for increases in XML parsing failures or log ingestion errors in SIEM platforms
• Monitor for patterns of input containing control characters or other potentially problematic data that could trigger the vulnerability

How to Mitigate CVE-2026-34479

Immediate Actions Required

• Upgrade to Apache Log4j 1-to-Log4j 2 bridge version 2.25.4 or later, which corrects the character encoding issue
• Audit all application configurations for use of Log4j1XmlLayout or org.apache.log4j.xml.XMLLayout layout classes
• Review the Log4j Migration Guide from 1.x to plan migration away from the deprecated bridge component
• Implement input validation to filter or reject log messages containing forbidden XML characters at the application level

Patch Information

Apache has released version 2.25.4 of the Log4j 1-to-Log4j 2 bridge component that properly handles forbidden XML characters. Organizations should prioritize upgrading to this version. The technical details of the fix can be reviewed in the GitHub Pull Request for Log4j2.

It is important to note that the Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Organizations should use this as an opportunity to migrate fully to Log4j 2 native configurations, eliminating reliance on the bridge component entirely.

Workarounds

• Consider switching to a different layout format (such as JSON or Pattern layout) that does not have XML character restrictions
• Implement application-level input sanitization to strip or encode forbidden XML characters before they reach the logging subsystem
• Deploy XML validation at log aggregator ingestion points to gracefully handle malformed documents rather than failing silently
• If upgrading is not immediately possible, consider implementing a custom log filter to sanitize output before XML encoding

# Configuration example: Verify Log4j bridge version
# Check your Maven dependencies for the affected component
mvn dependency:tree | grep log4j-1.2-api

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