Apache Log4j Core: Improper Encoding or Escaping of Output
CVE-2026-34480 is a high-severity improper encoding or escaping of output vulnerability in Apache Log4j Core from Apache, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists version 2.25.4 as the first without the flaw, so updating Apache Log4j Core to that release or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 1.06% chance of exploitation within 30 days, higher than 65% of scored CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Apache Log4j Core to 2.25.4 or a later version.
- Update Log4j to 2.25.4 or a later version.
- Read the advisory on lists.apache.org for workarounds and exact fixed builds.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Apache | Apache Log4j Core | 2.0-alpha1 up to, but not including, 2.25.4; 3.0.0-alpha1 through 3.0.0-beta3 | 2.25.4 |
| Apache | Log4j | 2.0 up to, but not including, 2.25.4; 3.0.0 | 2.25.4 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- NoneNo data is disclosed.
- Integrity
- HighData or code can be modified at will.
- Availability
- NoneAvailability is not affected.
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. Scored by NVD.
| Scoring system | Score | Severity | Scored by |
|---|---|---|---|
| CVSS 4.0 | 6.9 | Medium | CNA (apache.org) |
| CVSS 3.1 | 7.5 | High | NVD |
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Improper Encoding or Escaping of Output
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.
How developers prevent this class of flaw
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using the ESAPI Encoding control or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error. Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.
- If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.
- Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
More Improper Encoding or Escaping of Output vulnerabilities (CWE-116)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: partial).
- Record last changed materially (score, affected products, status or references).
References
Advisories
Patches and release notes
- github.com/apache/logging-log4j2/pull/4077Issue Tracking
Third-party and government advisories
- openwall.com/lists/oss-security/2026/04/10/9Mailing List, Third Party Advisory
Other references
- logging.apache.org/cyclonedx/vdr.xmlProduct
- logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayoutTechnical Description
Other vulnerabilities in Apache Log4j Core
- 7.5 High severity
Recent Improper Encoding or Escaping of Output vulnerabilities
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 8.1 High severity
- 9.1 Critical severity
Spotted an error? Tell us.