CVE-2026-49844 in Log4j API
Summary
by MITRE • 07/10/2026
Improper encoding of non-finite floating-point values during MapMessage JSON serialization in Apache Log4j API produces output that is not valid JSON. This issue affects Apache Log4j API versions 2.13.1 through 2.25.4 and version 2.26.0.
The fix for CVE-2026-34481 did not cover all code paths: when a MapMessage contains a non-finite IEEE 754 value (NaN, Infinity, or -Infinity), MapMessage.asJson() emits the corresponding bare token. RFC 8259 does not permit these tokens, so a conformant parser rejects the resulting document.
The defect is reachable only when both of the following conditions hold:
* The application uses the message resolver https://logging.apache.org/log4j/2.x/manual/json-template-layout.html#event-template-resolver-message of JsonTemplateLayout or any other layout that relies on MapMessage.asJson() or MapMessage.getFormattedMessage(new String[]{"JSON"}).
* The application logs a MapMessage that contains an attacker-controlled floating-point value.
An attacker who can supply a non-finite value can cause the affected layout to emit malformed JSON, which may corrupt the enclosing log record or disrupt downstream log ingestion and parsing.
Users are advised to upgrade to Apache Log4j API 2.25.5 or 2.26.1, both of which emit RFC 8259-compliant JSON for non-finite values.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/11/2026
The vulnerability described in CVE-2026-34481 represents a critical flaw in Apache Log4j API's handling of floating-point values during JSON serialization within MapMessage objects. This issue stems from improper encoding of non-finite IEEE 754 values including NaN (Not a Number), positive infinity, and negative infinity, which when processed through the MapMessage.asJson() method produce invalid JSON output that violates RFC 8259 standards. The vulnerability affects a substantial range of Apache Log4j API versions from 2.13.1 through 2.25.4 and includes version 2.26.0, making it particularly concerning given the widespread adoption of this logging framework across enterprise environments.
The technical implementation flaw occurs specifically within the MapMessage serialization logic where non-finite floating-point values are emitted as bare tokens rather than properly encoded according to JSON specifications. This regression represents a failure in the fix for CVE-2026-34481, which did not account for all code paths that could trigger the problematic behavior. The vulnerability manifests when applications utilize message resolvers from JsonTemplateLayout or other layouts that depend on MapMessage.asJson() or MapMessage.getFormattedMessage(new String[]{"JSON"}), creating a precise attack vector where an attacker can control floating-point values in log messages. The flaw operates under specific dual conditions that must be met simultaneously, making it both targeted and potentially exploitable in scenarios where applications process untrusted data through logging mechanisms.
The operational impact of this vulnerability extends beyond simple JSON parsing failures to potentially compromise entire logging pipelines and downstream systems. When malformed JSON is generated by the affected layouts, it can corrupt log records that contain these invalid values, leading to data integrity issues that may go undetected until analysis occurs. More critically, the malformed output disrupts automated log ingestion and parsing processes that rely on valid JSON structures, potentially causing complete failure of log processing pipelines or injection of malicious content into systems that consume these logs. This vulnerability directly impacts the security posture of organizations relying on Apache Log4j for their logging infrastructure, as it creates opportunities for attackers to exploit log processing systems through carefully crafted floating-point values.
Organizations can mitigate this vulnerability by upgrading to Apache Log4j API versions 2.25.5 or 2.26.1, which properly encode non-finite values according to RFC 8259 standards. These fixed versions ensure that NaN, infinity, and negative infinity values are correctly serialized as null values in JSON output rather than bare tokens, maintaining compliance with JSON specification requirements. The mitigation strategy aligns with industry best practices for vulnerability remediation and follows the principle of least privilege by ensuring that logging operations produce valid output regardless of input data characteristics. Security teams should prioritize this upgrade across all systems utilizing affected Log4j versions while also considering additional controls such as log validation checks and monitoring for malformed JSON patterns in their logging infrastructure to detect potential exploitation attempts.
This vulnerability demonstrates a classic example of how seemingly minor implementation details in security-critical libraries can create significant risks, particularly when dealing with data serialization formats that must maintain strict compliance with standards. The issue falls under CWE-248, Improper Control of a Resource Through Time-of-Use, and aligns with ATT&CK techniques involving log injection and data corruption through manipulation of logging systems. The vulnerability's impact is amplified by the widespread use of Log4j in enterprise environments, where logging frameworks often serve as critical infrastructure components that must maintain reliable operation under all conditions.