Apache log4net CVE-2026-105242

Exploitation requires a specific stack: (1) the application runs on ASP.NET for .NET Framework (the vulnerable code path depends on System.Web, which netstandard/.NET Core lacks per the vendor test guard NET462_OR_GREATER); (2) log4net version in the range 1.2.11 up to but not including 3.5.0; (3) the log4net layout pattern explicitly uses the %aspnet-request converter; and (4) ASP.NET request validation is active (default on .NET Framework) so that a parameter such as <script> raises HttpRequestValidationException on first access to HttpRequest.Params. LIMITING FACTORS: the affected configuration is narrow (Framework-only plus an opt-in layout converter), no authentication or user interaction is needed, and crucially the impact is confined to suppressing the logging of the attacker's own request - it cannot delete other users' logs, read data, or crash the service, so realistic risk is limited to log evasion aiding a separate attack.

This is a genuine but low-priority medium-severity issue (CVSS 5.3), and the signals should be read carefully. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N correctly scores a remote, unauthenticated, low-complexity vector with NO confidentiality or availability impact and only LOW integrity impact - that integrity impact is loss/suppression of a log record, i.e. an anti-forensics/log-evasion weakness, not data compromise or code execution. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so exploitation status is: no public exploit identified at time of analysis. SSVC-style reasoning: technical impact is partial (log integrity only), automatable is plausible (a scripted request can trigger it) but the payoff is merely suppressing the attacker's own request log, which limits practical value to covering tracks for a separate attack. CONFLICTING SIGNAL: the input Tag 'Information Disclosure' is inconsistent with the CVSS (C:N) and the described behavior - nothing is disclosed; a log event is dropped. Real-world priority is low: exploitation requires a narrow configuration, and the worst outcome is a missing log entry rather than a compromised system.

An attacker sends an HTTP request containing markup such as <script> in a query-string or form parameter to a vulnerable ASP.NET-on-.NET-Framework application whose log4net layout uses %aspnet-request. When the layout reads the request parameters, ASP.NET request validation throws, log4net's appender discards the entire log event, and the attacker's request leaves no trace in the logs - useful anti-forensics to mask other malicious activity. No public proof-of-concept was identified in the provided data, though the vendor's own regression tests demonstrate the behavior.