Apache HTTP Server EUVD-2026-90893

Exploitation requires the optional mod_charset_lite module to be loaded AND actively configured for character-set translation (e.g. via CharsetSourceEnc, CharsetDefault, and an associated output/input filter on the content path); this module is not enabled in default Apache HTTP Server installations, so the overwhelming majority of deployments are not exposed. Exploitation is limited to Apache HTTP Server versions 2.4.0 through 2.4.68 where this configuration is present. Authentication and user-interaction requirements cannot be confirmed because no CVSS vector was provided.

Signals are sparse: no CVSS vector, no EPSS score, no CISA KEV listing, and no public POC were provided, so most severity signals are missing rather than conflicting. The only hard facts are the CWE-787 out-of-bounds write classification, the affected version range (2.4.0-2.4.68), and the vendor (Apache) as reporter via the official httpd security page. The critical mitigating factor is the affected component: mod_charset_lite is NOT a default-loaded Apache module - it must be explicitly compiled/enabled and configured with charset-translation directives (e.g. CharsetSourceEnc/CharsetDefault) to be in the request path. Therefore, despite Apache HTTP Server being ubiquitous, the real exposed population is a small subset of deployments that actively use charset translation. This looks like a genuine memory-corruption bug worth patching on affected hosts, but it is lower practical priority than its 'Apache HTTP Server' branding suggests, because the vulnerable code only executes under a non-default configuration. Authentication requirements cannot be confirmed: no CVSS vector was supplied, so whether a request must be authenticated is unknown from the available data. There is no evidence of active exploitation.

On a server where an administrator has enabled and configured mod_charset_lite for on-the-fly character-set translation, a remote attacker sends a crafted request (or triggers a response) whose content is routed through the translation filter, driving the out-of-bounds write. No public exploit code has been identified, so this scenario is theoretical and based on the CWE-787 classification rather than a demonstrated PoC.