CVE-2026-34479

What it actually does

This flaw affects Apache Log4j deployments that use the Log4j 1-to-Log4j 2 bridge with XML-style layouts, specifically direct use of Log4j1XmlLayout or the Log4j 1 compatibility layout class org.apache.log4j.xml.XMLLayout. The layout fails to escape characters that are forbidden by XML 1.0. If attacker-controlled or untrusted data is written to logs, those characters can make the emitted XML log document malformed. Standards-compliant XML parsers must reject malformed XML as a fatal error, so downstream log collectors, SIEM pipelines, parsers, or indexing systems may drop records, fail ingestion, or stop processing affected log files. This is primarily a log integrity and observability weakness rather than code execution or data disclosure.

Why it matters to the business

Organizations relying on XML-formatted Log4j output may lose visibility into application activity, security events, audit trails, or operational errors if malformed records disrupt log ingestion. An attacker who can influence logged input may be able to hide activity, interfere with investigations, trigger alerting gaps, or degrade monitoring reliability. The issue is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score with no recent upward trend, but Log4j is widely deployed and the operational impact can be significant where XML logs are part of compliance, incident response, fraud detection, or production monitoring workflows.

How an attack unfolds

An attacker first identifies an application path where their input is recorded in logs, such as HTTP headers, URL parameters, form fields, API payload fields, usernames, user-agent strings, correlation IDs, or error messages. If the application uses the deprecated Log4j 1-to-Log4j 2 bridge with Log4j1XmlLayout or the Log4j 1 XMLLayout compatibility class, the attacker submits input containing XML 1.0-forbidden characters. When the application logs that value, the vulnerable layout writes malformed XML instead of safely escaping or removing the invalid characters. A downstream XML parser, log shipper, SIEM connector, or indexing pipeline then rejects the document or record with a fatal parse error. The practical outcome is that selected events may fail to ingest, entire files or batches may be dropped, and monitoring or audit evidence may become incomplete. There are no named threat actors or ransomware campaigns currently associated with this vulnerability, and this is not an RCE-style exploitation path.

How to fix it

Upgrade the Apache Log4j 1-to-Log4j 2 bridge to version 2.25.4 or later, which corrects the escaping behavior. Because the bridge is deprecated and will not be present in Log4j 3, prioritize migration away from Log4j 1 compatibility features and replace org.apache.log4j.xml.XMLLayout or Log4j1XmlLayout usage with supported Log4j 2 layouts. Review configuration files for XML layout usage, including Log4j 1 compatibility configurations. If immediate upgrade is not possible, mitigate by switching to a non-XML layout, sanitizing or filtering control characters before logging, configuring log shippers to tolerate or quarantine malformed records without stopping entire pipelines, and adding monitoring for XML parser failures or ingestion drops.

How to confirm the fix worked

Confirm that runtime dependencies include Apache Log4j 1-to-Log4j 2 bridge version 2.25.4 or later and that no older bridge JAR remains on the application classpath. Inspect logging configuration for direct references to Log4j1XmlLayout or org.apache.log4j.xml.XMLLayout and verify they have been removed or replaced. Generate a controlled test log event containing XML-forbidden control characters in a non-production environment and verify that produced logs remain parseable and are successfully ingested by downstream tooling. Validate end-to-end ingestion by checking log shipper, parser, indexer, and SIEM dashboards for parse failures, rejected documents, or missing records after the upgrade or configuration change.

Typical attack path

1. Find an internet-facing or otherwise reachable application that logs user-controlled input.
2. Confirm or infer that the application emits XML logs using the Log4j 1-to-Log4j 2 bridge, Log4j1XmlLayout, or org.apache.log4j.xml.XMLLayout.
3. Send crafted input containing XML 1.0-forbidden characters through a field that is likely to be logged.
4. Cause the vulnerable layout to write malformed XML log output.
5. Rely on downstream XML parsers, log collectors, or SIEM ingestion jobs to reject, drop, or fail to index the malformed log records.
6. Use the resulting visibility gap to obscure activity, disrupt monitoring, or reduce the reliability of audit and forensic data.

How to detect it

To determine whether this was already exploited or caused operational impact, review application logs, log shipper logs, XML parser errors, SIEM ingestion diagnostics, and indexing pipeline health metrics for malformed XML failures, rejected documents, ingestion pauses, or sudden drops in event volume. Correlate parser errors with inbound requests or user-controlled fields containing unusual control characters, binary data, encoded null bytes, or malformed Unicode. Examine time windows where XML ingestion failed for suspicious authentication attempts, web requests, API calls, privilege changes, or error bursts that may not have been indexed. Also inspect build artifacts and configuration repositories for use of Log4j1XmlLayout or org.apache.log4j.xml.XMLLayout to determine exposure. Because exploitation may manifest as missing logs rather than a clear payload, compare raw log files on disk with records received by the SIEM or log indexer and look for discrepancies around XML fatal errors.

• Log4j1XmlLayout
• org.apache.log4j.xml.XMLLayout
• log4j-1.2-api
• SAXParseException
• XMLStreamException
• An invalid XML character (Unicode: 0x
• Character reference "&#x0
• not well-formed (invalid token)
• Content is not allowed in prolog
• The content of elements must consist of well-formed character data or markup
• Fatal Error
• Failed to parse XML
• malformed XML
• rejected document
• failed to index document

What your security team should do

• Inventory Java applications and services using Apache Log4j, with special focus on deployments that include the Log4j 1-to-Log4j 2 bridge.
• Prioritize systems that emit XML logs consumed by SIEM, compliance, audit, fraud, or incident response pipelines.
• Upgrade the bridge to Apache Log4j 2.25.4 or later and remove older Log4j bridge artifacts from build outputs, containers, and runtime classpaths.
• Search application and logging configurations for Log4j1XmlLayout and org.apache.log4j.xml.XMLLayout, then migrate to supported Log4j 2 layouts.
• Add detection for XML parse failures, log ingestion drops, and rejected events in log collection and SIEM infrastructure.
• Treat unexplained gaps in application logs around suspicious requests as potentially relevant until ingestion integrity is confirmed.
• Plan migration away from the deprecated Log4j 1 compatibility bridge because it will not be available in Log4j 3.