Apache log4net CVE-2026-105239

Requires a Windows application running log4net 1.2.9 to before 3.5.0 AND configured to use EventLogAppender; applications on non-Windows platforms or using any other appender are not affected. The attacker must be able to get attacker-controlled data containing a NUL (\0) character into a value that the configured layout renders into the event text. Limiting factors: impact is confined to silently truncating/hiding the remainder of that single Windows Event Log record (exception text and trailing fields) - there is no code execution, confidentiality loss, or availability impact, and no error is raised, so the effect is log/audit suppression rather than system compromise.

This is a genuinely medium/low-priority issue, not a high-urgency flaw despite the AV:N network vector. The provided CVSS is 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N), with the only impact being low integrity (C:N/A:N) - specifically log-record integrity, i.e. an anti-forensics/log-tampering weakness (CWE-158), not data theft, privilege escalation, or code execution. No EPSS score, CISA KEV listing, or SSVC decision data was supplied, and there is no public exploit identified at time of analysis - the referenced GitHub commit and unit tests are the vendor fix, not weaponized exploit code, and must not be conflated with exploitation. The AV:N rating reflects that attacker-controlled input can traverse the network to eventually land in a logged field, but real exploitation also depends on narrow deployment conditions (Windows-only, EventLogAppender configured) and only lets an attacker silently truncate the tail of one Event Log entry. Note a nuance: the 'Information Disclosure' tag mischaracterizes the effect - the flaw HIDES data from the log rather than disclosing it to the attacker, so the practical risk is evidence suppression/audit evasion by an already-active attacker, not confidentiality loss. Net: treat as a defense-in-depth/log-integrity fix to schedule, not an emergency.

An attacker who can influence any value that log4net renders into a Windows Event Log entry (for example a username, HTTP header, or search term) embeds a NUL (\0) byte in that value. Because ReportEventW treats the string as null-terminated, everything the layout renders after the NUL - including exception text and trailing audit fields - is silently dropped from the stored record, letting the attacker conceal evidence of their activity. No public exploit code is identified at time of analysis; the attack requires only the ability to get crafted data into a logged message on an affected Windows deployment.