Apache Log4j Core up to 2.25.3/3.0.0-beta3 Conforming Parser escape output

Summaryinfo

A vulnerability described as problematic has been identified in Apache Log4j Core up to 2.25.3/3.0.0-beta3. This issue affects some unknown processing of the component Conforming Parser. The manipulation results in escape output. This vulnerability is cataloged as CVE-2026-34480. The attack may be launched remotely. There is no exploit available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability, which was classified as problematic, was found in Apache Log4j Core up to 2.25.3/3.0.0-beta3. Affected is an unknown code block of the component Conforming Parser. The manipulation with an unknown input leads to a escape output vulnerability. CWE is classifying the issue as CWE-116. The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved. This is going to have an impact on integrity. CVE summarizes:

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 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.

The weakness was shared by Ap4Sh. The advisory is shared for download at github.com. This vulnerability is traded as CVE-2026-34480 since 03/28/2026. The exploitability is told to be easy. It is possible to launch the attack remotely. The exploitation doesn't require any form of authentication. There are neither technical details nor an exploit publicly available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 06/24/2026).

The vulnerability scanner Nessus provides a plugin with the ID 306043 (Linux Distros Unpatched Vulnerability : CVE-2026-34480), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 2.25.4 eliminates this vulnerability. Applying a patch is able to eliminate this problem. The bugfix is ready for download at github.com. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (306043) and CERT Bund (WID-SEC-2026-1067). Once again VulDB remains the best source for vulnerability data.

Affected

• Google Cloud Platform
• Red Hat Enterprise Linux
• SUSE Linux
• IBM SPSS
• SUSE openSUSE
• IBM Tivoli Network Manager
• IBM DB2
• Microsoft Azure Linux
• Apache log4j
• IBM App Connect Enterprise
• IBM Tivoli Netcool/OMNIbus
• Splunk Splunk Enterprise
• IBM License Metric Tool

Productinfo

Vendor

• Apache

Name

• Log4j Core

Version

• 2.25.0
• 2.25.1
• 2.25.2
• 2.25.3
• 3.0.0-beta1
• 3.0.0-beta2
• 3.0.0-beta3

License

• open-source

Website

• Vendor: https://www.apache.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion