Skip to main content

Apache Log4J Core CVE-2026-34480

| EUVDEUVD-2026-21410 MEDIUM
Improper Encoding or Escaping of Output (CWE-116)
2026-04-10 apache GHSA-3pxv-7cmr-fjr4
6.9
CVSS 4.0 · Vendor: apache
View

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding for downstream
Impact

The CVSS 4.0 score of 6.9 reflects low attack complexity (AC:L), no authentication required (PR:N), and network-accessible scope (AV:N), but limited security impact: no confidentiality loss (VC:N), low integrity impact (VI:L), and no availability loss in the primary system (VA:N). However, the scope impact (SI:L) indicates downstream systems are affected. The real-world risk depends on operational context: organizations using Log4j for security-critical audit logging or compliance-sensitive systems face moderate risk if log processing infrastructure silently drops records due to malformed XML-this could obscure security events or violate regulatory requirements (e.g., financial audit trails). Conversely, deployments using Woodstox or similar strict parsers will experience immediate exceptions, making the issue visible rather than silent, which may be preferable for detection but worse for log availability. No public exploit code exists and no active exploitation has been reported; this is not an attack vector but rather a data quality and system reliability issue. EPSS score not provided, but exploitation probability is low (this requires specific StAX implementations and log content containing forbidden characters-not a remotely exploitable vulnerability in the classical sense). Priority should be elevated for environments with strict log processing requirements or regulatory obligations.

Exploit ScenarioDerived

An application using Log4j 2.25.3 with XmlLayout receives a user-submitted input or processes data containing XML-forbidden control characters (e.g., U+0000 or U+0008). When this input is logged via Log4j, XmlLayout writes it directly into the XML output without sanitization. If the environment uses the JRE's standard StAX parser, downstream XML processing tools (e.g., log aggregation systems) attempt to parse the malformed XML and fail with a validation error, silently discarding the log record. If a stricter StAX implementation like Woodstox is in use, Log4j's logging call raises an exception, preventing the event from being appended to the configured output, though internal status logging captures the error. In either case, security-relevant events may be lost from the audit trail, compromising log integrity and visibility.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Apr 10, 2026

Apache Log4j Core's XmlLayout in versions up to 2.25.3 fails to sanitize XML-forbidden characters, producing malformed XML output when log messages or MDC values contain such characters. The impact varies by StAX implementation: JRE's built-in StAX silently writes invalid XML that conforming parsers reject, potentially causing downstream log-processing systems to drop records; alternative StAX implementations like Woodstox throw exceptions during logging calls, preventing event delivery to the intended appender. No public exploit code or active exploitation has been identified; this is a data integrity and log availability issue rather than a confidentiality or authentication bypass. Patch version 2.25.4 is available from Apache.

RemediationAI

Vendor-released patch: Apache Log4j Core 2.25.4. Upgrade to version 2.25.4 or later, which implements proper sanitization of forbidden XML characters before XML output generation. For environments unable to upgrade immediately, use alternative layouts such as JsonLayout or PatternLayout instead of XmlLayout, provided downstream systems can accommodate the format change. Additionally, implement input validation or filtering at the application level to prevent forbidden characters from entering log messages or MDC values, though this is a defense-in-depth measure and not a substitute for patching. For patch details and verification, consult the official Apache Log4j security advisory at https://logging.apache.org/security.html#CVE-2026-34480 and the corresponding fix pull request at https://github.com/apache/logging-log4j2/pull/4077.

Affected VersionsENISA

Apache Log4j Core 2.0-alpha1 <2.25.4
Apache Log4j Core 3.0.0-alpha1 ≤3.0.0-beta3

Affected Packages

maven org.apache.logging.log4j:log4j-core fix: 2.25.4
euvd apache_log4j_core fix: 2.25.4

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in maven, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Apache Log4j Core's XmlLayout component handles serialization of log events to XML format using the StAX (Streaming API for XML) interface. The XML 1.0 specification strictly defines allowed character ranges; characters outside these ranges (such as certain control characters and undefined Unicode sequences) are forbidden. Log4j's XmlLayout processes log message content and mapped diagnostic context (MDC) values-user-supplied or application-derived data-directly into XML output without first validating compliance with XML 1.0 character restrictions. When forbidden characters are present, the behavior depends on the underlying StAX implementation: the JRE's reference implementation tolerates them and writes malformed XML (violating the specification but continuing execution), whereas alternative implementations like Woodstox (a transitive dependency of Jackson XML Dataformat) enforce strict XML validation and raise exceptions. This is a character encoding and input sanitization issue (CWE-116: Improper Encoding or Escaping of Output).

Know when Apache Log4J Core gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (apache) PRIMARY 6.9 MEDIUM
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
SUSE 6.5 MEDIUM
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Red Hat 5.3 MEDIUM

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
None
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
Low
Subsequent system: Availability
None

Lifecycle Timeline

2
Patch released
Apr 10, 2026 - 16:00 nvd
Patch available
CVE Published
Apr 10, 2026 - 15:42 nvd
MEDIUM 6.9

DescriptionCVE.org

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.

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 4 maven packages depend on org.apache.logging.log4j:log4j-core (4 direct, 0 indirect)

Ecosystem-wide dependent count for version 2.0-alpha1.

Threat Intelligence Overview

EPSS Score
0.1%
Top 69% exploitable
Threat Intel
1
1 source
Social Media
1
Sightings
Data Quality
8 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA Vendor CIRCL GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

34
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +34
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Related Vulnerabilities in Apache Log4j Multiple XML Injection and Escaping

View all 4

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Module for Basesystem 15 SP7 Affected
SUSE Linux Enterprise Server 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Server for SAP Applications 15 SP7 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy