CVE-2026-34480

What it actually does

Apache Log4j Core XmlLayout versions up to and including 2.25.3 do not sanitize characters that are forbidden by XML 1.0 before writing log events as XML. If attacker-controlled or otherwise untrusted data is logged in a message, marker, throwable text, or MDC/thread-context value, the resulting XML log can become malformed. With the JRE built-in StAX writer, invalid characters may be written into the log file and later cause XML parsers or log-processing pipelines to reject the document or affected records. With alternative StAX implementations such as Woodstox, the logging call can throw an exception and the event may not be delivered to the intended appender, leaving only Log4j internal status logger evidence. The primary security impact is loss or degradation of log integrity and auditability rather than direct code execution.

Why it matters to the business

Organizations using Log4j Core XmlLayout may lose security, audit, application, or compliance-relevant events when malformed XML logs are dropped or when logging fails during processing. This can reduce incident visibility, disrupt monitoring and alerting, and create gaps in forensic evidence. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no reported public exploit maturity, but it is still operationally important for systems that depend on XML-formatted logs for detection, compliance reporting, or audit trails.

How an attack unfolds

An attacker first identifies an application endpoint, protocol field, header, username, form value, API parameter, or other input that the application records through Log4j Core using XmlLayout. The attacker then submits data containing XML 1.0-forbidden control characters, commonly delivered as raw bytes or percent-encoded values such as null or other low ASCII control characters. When the application logs that value, affected Log4j versions pass the invalid characters to the XML writer without sanitization. Depending on the StAX implementation, the log file may contain malformed XML that downstream parsers reject, or the logging operation may raise an exception and skip delivery to the configured appender. The attacker’s goal is typically to suppress, corrupt, or break processing of selected log records, potentially hiding malicious activity that occurs in the same request or time window.

How to fix it

Upgrade Apache Log4j Core to version 2.25.4 or later wherever XmlLayout is used. The fix sanitizes XML 1.0-forbidden characters before XML output. If immediate upgrade is not possible, reduce exposure by switching affected appenders away from XmlLayout, using a layout that safely escapes or encodes untrusted content, preventing untrusted control characters from entering MDC/thread-context and log messages, and configuring log pipelines to quarantine rather than silently drop malformed records. Treat dependency-managed and transitive uses of log4j-core as in scope; verify both direct application dependencies and packaged vendor components. Do not rely only on input validation at application boundaries, because log data can originate from multiple protocols, libraries, exception messages, identity fields, and internal context values.

How to confirm the fix worked

Confirm that runtime artifacts and dependency manifests no longer include log4j-core versions up to and including 2.25.3 where XmlLayout is configured. Validate that the effective version is Apache Log4j Core 2.25.4 or later, including shaded, bundled, or container-layer copies. Review Log4j configuration files for XmlLayout usage in appenders. In a non-production test environment, submit representative inputs containing XML-forbidden control characters and verify that XML logs remain well-formed, parsers accept the output, and no Log4j StatusLogger or StAX writer exceptions are generated. Also verify that downstream collectors, SIEM parsers, and XML ingestion jobs continue to receive and parse the affected events after upgrade.

Typical attack path

1. Find an externally reachable input that is reflected into application logs, such as HTTP parameters, headers, request bodies, usernames, API fields, or MDC/thread-context values.
2. Send input containing XML 1.0-forbidden characters, often as raw control bytes or encoded sequences such as %00, %01, %02, or other low ASCII controls.
3. Trigger application code that logs the attacker-controlled value through Apache Log4j Core configured with XmlLayout.
4. Cause XmlLayout in Log4j Core 2.25.3 or earlier to emit malformed XML or encounter a StAX writer exception.
5. Rely on downstream XML parsers, SIEM collectors, ETL jobs, or appenders to reject, drop, truncate, or fail to ingest affected log records.
6. Use the resulting visibility gap to obscure associated probing, authentication attempts, API misuse, or other malicious activity.

How to detect it

To determine whether this was already exploited or triggered, correlate application access logs, API gateway logs, WAF logs, message broker logs, application logs, Log4j StatusLogger output, and downstream log-processing or SIEM ingestion errors. Look for requests, headers, parameters, usernames, JSON/XML fields, or message payloads containing raw or encoded control characters, especially near times when XML log parsers reported fatal errors, collectors dropped records, or expected events are missing. On systems using Woodstox or other non-JRE StAX implementations, search application stderr/stdout, service logs, and Log4j status logs for XML writer exceptions during logging. On systems using the JRE built-in StAX implementation, search downstream parser, ETL, SIEM, and collector logs for malformed XML errors, invalid character errors, premature document termination, or rejected XML batches. Investigate any time windows where log volume drops abruptly after requests containing control-character payloads, because the attacker objective may be log suppression rather than application compromise.

• %00
• %01
• %02
• %03
• %04
• %05
• %06
• %07
• %08
• %0B
• %0C
• %0E
• %0F
• %10
• %11
• %12
• %13
• %14
• %15
• %16
• %17
• %18
• %19
• %1A
• %1B
• %1C
• %1D
• %1E
• %1F
• Invalid white space character
• Invalid XML character
• An invalid XML character
• MalformedByteSequenceException
• SAXParseException
• Content is not allowed in prolog
• XML document structures must start and end within the same entity
• com.ctc.wstx.exc.WstxOutputException
• com.ctc.wstx.exc.WstxIOException
• org.apache.logging.log4j.core.layout.XmlLayout
• StatusLogger
• Unable to write to stream
• Error writing XML
• XMLStreamException

What your security team should do

• Inventory applications and services using Apache Log4j Core and prioritize those configured with XmlLayout for upgrade to 2.25.4 or later.
• Search dependency manifests, container images, fat JARs, and vendor packages for log4j-core versions 2.25.3 and earlier.
• Identify security-critical systems where XML logs feed SIEM, audit, compliance, fraud, authentication, or incident-response workflows and patch those first.
• Review Log4j StatusLogger output and log-ingestion error dashboards for signs of malformed XML, StAX exceptions, parsing failures, or unexplained log drops.
• Add detection logic for requests or messages containing encoded control characters in fields that are commonly logged.
• Ensure log pipelines quarantine malformed XML and alert operators instead of silently discarding records.
• If patching is delayed, replace XmlLayout with a safer layout or add sanitization at logging boundaries for message and MDC/thread-context values.