Apache log4net CVE-2026-105240

Exploitation requires ALL of the following concrete preconditions: (1) the application runs on Windows; (2) log4net is explicitly configured to use OutputDebugStringAppender (a non-default, niche appender that calls the Windows OutputDebugStringW API); and (3) the attacker can influence content that reaches a logged message and insert a NUL (U+0000) character into it. Limiting factors that reduce realistic risk: the issue does not affect non-Windows deployments or any other appender, impact is confined to log-record integrity (concealing trailing log content such as exception text) with no confidentiality, availability, or code-execution effect, and the vulnerable OutputDebugStringAppender configuration is uncommon in production.

This is a genuinely low-to-moderate real-world risk despite the CVSS:3.1 base score of 5.3 (MEDIUM). The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N shows the only impact is a LOW integrity effect - there is no confidentiality (C:N) or availability (A:N) impact, no code execution, and no disclosure of system data. The 'integrity' impact is purely log-record integrity: an attacker who can inject a NUL byte into content that gets logged can truncate the debug record and silently hide everything the layout rendered after it (exception text, trailing fields), making this fundamentally a log-tampering / anti-forensics evasion issue rather than a system compromise. No EPSS score was provided in the input, there is no CISA KEV listing, and no public POC was supplied, so there is no public exploit identified at time of analysis - all exploitation signals point to low urgency. The AV:N (network) rating is defensible only insofar as the tainted NUL-bearing data typically arrives over the network, but exploitation is strictly gated by a non-default deployment: the application must run on Windows AND be configured with OutputDebugStringAppender, which is a narrow and uncommon configuration - this real-world precondition is not captured in the AV:N/AC:L/PR:N metrics and substantially lowers practical risk below what the 5.3 base score suggests. Treat as a low-priority defense-in-depth fix, prioritized only where log integrity for Windows debug output is security-relevant.

An attacker supplies input containing a NUL byte into a field the application later logs (for example a username, header, or request parameter) on a Windows host whose log4net is configured with OutputDebugStringAppender. Because OutputDebugStringW treats the string as NUL-terminated, the debug record is cut off at the NUL and all following content - including any exception text or trailing audit fields - is silently dropped, letting the attacker conceal the remainder of the log entry. No public exploit code is available, and the attack produces no code execution or data disclosure, only suppression of log content.