CVE-2026-105241 in log4net
Summary
by MITRE • 10/06/2026
Improper Handling of Unicode Encoding vulnerability in the SmtpPickupDirAppender of Apache log4net.
Content that the mail file writer cannot encode, such as an unpaired UTF-16 surrogate, made the write throw. Every buffered event in the batch was discarded, not only the one carrying the content, and a truncated mail could be left in the pickup directory. A party whose data reaches a log message could suppress the records of other events. Only applications that use SmtpPickupDirAppender are affected.
This issue affects Apache log4net: from 1.2.9 before 3.5.0.
Users are recommended to upgrade to version 3.5.0, which fixes the issue.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in Apache log4net specifically impacts the SmtpPickupDirAppender component, representing a critical flaw in how the application handles Unicode encoding during email generation processes. This security defect arises from improper validation and sanitization of character data before it is written to disk files intended for SMTP pickup directories. The core technical issue involves the failure to properly handle unpaired UTF-16 surrogate pairs or other invalid Unicode sequences that cannot be encoded by the underlying mail file writer. In standard .NET environments, such malformed characters often trigger encoding exceptions when the system attempts to convert them into a byte stream suitable for transmission or storage. Instead of gracefully handling these errors through sanitization or fallback mechanisms, the application allows the exception to propagate unhandled within the logging pipeline.
From an operational perspective, this flaw leads to significant data integrity and availability issues. When an event containing invalid Unicode content is processed by the SmtpPickupDirAppender, the resulting encoding error causes the entire batch of buffered log events to be discarded rather than just the single problematic entry. This behavior results in a denial-of-service condition for logging capabilities, where legitimate security-relevant logs are lost alongside the malicious or malformed data. Furthermore, because the application may leave behind truncated mail files in the pickup directory before failing, it creates an inconsistent state that can confuse downstream email processing systems. An attacker who controls input data destined for log messages could exploit this behavior to suppress records of other critical events, effectively obscuring their activities from security monitoring and audit trails while potentially leaving corrupted artifacts on the file system.
This vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to adequately validate or sanitize user-supplied data before processing it for output generation. Additionally, the ability of an attacker to suppress log entries through this mechanism relates to CWE-778 Insufficient Logging, which undermines the effectiveness of security monitoring and incident response capabilities. In terms of attack vectors, this could be leveraged in scenarios where external inputs are directly or indirectly written to logs without proper encoding checks, potentially facilitating data exfiltration concealment or audit trail tampering. The impact is particularly severe for organizations relying on automated email-based alerting systems powered by log4net, as the reliability of these alerts is compromised when logging fails silently or partially.
The vulnerability affects Apache log4net versions ranging from 1.2.9 up to but not including version 3.5.0. Applications that do not utilize the SmtpPickupDirAppender are unaffected by this specific flaw, highlighting the importance of component-level risk assessment during remediation efforts. To mitigate this issue and restore robust logging functionality, users must upgrade their log4net dependencies to version 3.5.0 or later. This release incorporates fixes for Unicode handling within the mail writer components, ensuring that invalid characters are either sanitized or handled without causing batch failures. Organizations should also implement input validation at application entry points where possible to reduce the likelihood of malformed data reaching logging subsystems, thereby adding a layer of defense-in-depth against encoding-related vulnerabilities.