CVE-2026-34480
Apache Log4J 2.0 – 2.25.4
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-34480 is a medium-severity Improper Encoding or Escaping of Output (CWE-116) vulnerability in Apache Log4J. Its CVSS base score is 6.9 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Content Injection (T1659); ranked in the top 45% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
Apache Log4j Core's XmlLayout, in versions up to and including 2.25.3, contains a vulnerability (CVE-2026-34480) where it fails to sanitize characters forbidden by the XML 1.0 specification in log messages or Mapped Diagnostic Context (MDC) values. This results in invalid XML output when such characters are present. The issue affects applications using Log4j Core with XmlLayout for logging, particularly those relying on downstream XML processing.
Attackers with the ability to control log message content or MDC values—such as through user inputs that are logged—can exploit this remotely with low complexity and no privileges required (CVSS 7.5: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N; CWE-116). Depending on the StAX implementation, exploitation produces either malformed XML that conforming parsers reject, potentially causing downstream log-processing systems to drop affected records, or throws an exception (e.g., with Woodstox, a transitive dependency of Jackson XML Dataformat), preventing delivery to the intended appender and routing only to Log4j's internal status logger. This leads to log record loss or integrity violations.
Apache advisories recommend upgrading to Log4j Core 2.25.4, which addresses the issue by sanitizing forbidden characters before XML output. Relevant resources include the official security advisory at https://logging.apache.org/security.html#CVE-2026-34480, the fixing pull request at https://github.com/apache/logging-log4j2/pull/4077, and the XmlLayout documentation at https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-21410
Vulnerability Data
Apache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout , in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets producing invalid XML output whenever a log message or MDC value contains such characters. The impact…
more
depends on the StAX implementation in use: * JRE built-in StAX: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records. * Alternative StAX implementations (e.g., Woodstox https://github.com/FasterXML/woodstox , a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.1.2V1.2.1V1.2.3
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Validating that output matches expected content directly mitigates failures to properly encode or escape data for its destination context.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require proper output encoding to prevent injection and message malformation.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure coding standards explicitly require correct output encoding and escaping to preserve message structure.
Security testing can detect missing or incorrect encoding but does not itself implement the control.
Secure development life cycle mandates output encoding/escaping practices that directly prevent improper encoding.
Application security requirements include explicit rules for safe output handling and encoding.
Secure architecture principles reduce the likelihood of missing encoding but do not prescribe the actual technique.