CVE-2025-54813: Apache Log4cxx Information Disclosure

CVE-2025-54813 Overview

CVE-2025-54813 is an Improper Output Neutralization for Logs vulnerability affecting Apache Log4cxx, the popular C++ logging framework from the Apache Software Foundation. When using JSONLayout, not all payload bytes are properly escaped. If an attacker-supplied message contains certain non-printable characters, these will be passed along in the message and written out as part of the JSON message. This may prevent applications that consume these logs from correctly interpreting the information within them.

This vulnerability is classified under CWE-117 (Improper Output Neutralization for Logs) and affects Apache Log4cxx versions prior to 1.5.0. Users are strongly recommended to upgrade to version 1.5.0, which addresses this security issue.

Critical Impact

Attackers can inject malicious non-printable characters into log messages, potentially corrupting JSON log output and breaking log analysis pipelines. This could enable log injection attacks, hinder forensic investigations, or mask malicious activity in environments relying on centralized log management systems.

Affected Products

• Apache Log4cxx versions prior to 1.5.0
• Applications using JSONLayout for log formatting
• Systems consuming JSON-formatted logs from affected Log4cxx deployments

Discovery Timeline

• 2025-08-22 - CVE-2025-54813 published to NVD
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2025-54813

Vulnerability Analysis

This vulnerability stems from insufficient output encoding in Apache Log4cxx's JSONLayout component. When log messages containing non-printable characters are processed through JSONLayout, the library fails to properly escape these characters before writing them to the JSON output. This creates malformed JSON that downstream log consumers cannot parse correctly.

The attack surface is accessible over the network, as any input that flows into log messages can potentially carry the malicious payload. The vulnerability requires some prerequisites to be exploited effectively (AT:P), but does not require authentication or user interaction, making it accessible to unauthenticated remote attackers in many scenarios.

While this vulnerability does not directly compromise confidentiality, it poses integrity risks to both the vulnerable system and downstream systems that consume the logs (VI:L, SI:L). Attackers could leverage this flaw to inject false log entries, corrupt audit trails, or cause denial of service in log processing pipelines.

Root Cause

The root cause lies in the incomplete character escaping implementation within the JSONLayout class. JSON specification requires certain control characters and non-printable bytes to be escaped using unicode escape sequences (e.g., \\u0000). The affected versions of Log4cxx fail to escape all such characters, allowing raw byte sequences to pass through into the JSON output.

This represents a classic log injection vulnerability where user-controlled input is written to logs without proper sanitization, violating the principle of output encoding for the target context (JSON format).

Attack Vector

The attack vector operates through network-accessible input channels that eventually flow into log statements. An attacker can craft input containing specific non-printable characters (control characters, null bytes, or other special byte sequences) that the application logs.

When JSONLayout processes these messages, the non-printable characters are written directly into the JSON output without proper escaping. This can result in:

1. Malformed JSON - Downstream log aggregators and SIEM systems fail to parse the corrupted JSON
2. Log injection - Attackers can inject arbitrary content that appears as separate log entries
3. Data exfiltration masking - Malicious activity can be hidden within corrupted log entries
4. Compliance violations - Incomplete or corrupted audit logs may violate regulatory requirements

The vulnerability manifests in the JSONLayout output formatting routines where log message content is serialized to JSON format. For technical implementation details, refer to the GitHub Pull Request #512 which contains the fix.

Detection Methods for CVE-2025-54813

Indicators of Compromise

• Malformed or unparseable JSON entries in application logs using Log4cxx
• Log aggregation systems reporting parsing errors for JSON-formatted logs
• Unexpected control characters or binary data appearing in log files
• SIEM alerts indicating log ingestion failures from affected systems

Detection Strategies

• Implement JSON schema validation on log ingestion pipelines to detect malformed entries
• Monitor log aggregation systems for increased parsing error rates
• Deploy application-level input validation to flag non-printable characters in user input
• Use byte-level inspection tools to identify non-printable characters in log output files

Monitoring Recommendations

• Set up alerts for JSON parsing failures in log processing infrastructure
• Monitor for unusual patterns in log file sizes or entry counts that may indicate injection
• Implement integrity checks on critical audit logs
• Review Log4cxx configuration across your environment to identify systems using JSONLayout

How to Mitigate CVE-2025-54813

Immediate Actions Required

• Inventory all applications using Apache Log4cxx and identify those using JSONLayout
• Prioritize upgrade to Log4cxx version 1.5.0 for systems processing untrusted input
• Implement input validation to sanitize or reject non-printable characters before logging
• Review downstream log consumers to ensure they can handle potential malformed input gracefully

Patch Information

Apache has released version 1.5.0 of Log4cxx which resolves this vulnerability. The fix ensures all non-printable characters are properly escaped when using JSONLayout. Users should upgrade to this version as soon as possible.

For detailed patch information, refer to the Apache Security Advisory and the GitHub Pull Request #512.

Additional security announcements are available through the OpenWall OSS Security mailing list and the Debian LTS Security Announcement.

Workarounds

• Switch from JSONLayout to alternative layout formats (e.g., PatternLayout) until upgrade is possible
• Implement application-level input sanitization to strip non-printable characters before logging
• Add a sanitization layer in front of log aggregators to validate JSON before ingestion
• Use log forwarding proxies that can detect and quarantine malformed log entries

# Configuration example: Verify Log4cxx version and check for JSONLayout usage
# Check installed Log4cxx version
pkg-config --modversion liblog4cxx 2>/dev/null || echo "Log4cxx version check unavailable"

# Search for JSONLayout usage in configuration files
find /etc /opt /var -name "*.xml" -exec grep -l "JSONLayout" {} \; 2>/dev/null

# Review Log4cxx configuration for JSONLayout patterns
grep -r "JSONLayout" /path/to/application/config/