CVE-2026-49975

What it actually does

This vulnerability is a network-reachable denial-of-service flaw in Apache HTTP Server's HTTP handling path, associated with memory allocation using an excessively large size value. An unauthenticated remote attacker can send specially crafted HTTP requests that cause vulnerable Apache versions 2.4.17 through 2.4.67 to attempt abnormal memory allocation, potentially exhausting process or system memory, killing worker processes, causing request handling failures, or making the web service unavailable. The flaw does not indicate confidentiality or integrity impact; the primary technical consequence is loss of availability.

Why it matters to the business

Successful exploitation can make websites, APIs, reverse proxies, or web-facing applications served by vulnerable Apache HTTP Server instances unavailable. For organizations using Apache as an internet-facing web server or as a front end to critical applications, this can result in customer-facing outages, failed transactions, service degradation, incident response costs, and potential SLA impact. The CVSS score indicates high availability risk, and the EPSS score suggests a meaningful probability of exploitation activity even though the issue is not currently listed in CISA KEV and no mature public exploit is indicated in the provided data.

How an attack unfolds

An attacker identifies an Apache HTTP Server instance running an affected version between 2.4.17 and 2.4.67. Because exploitation is unauthenticated and network-accessible, the attacker only needs the ability to send HTTP requests to the service. The attacker then sends maliciously constructed HTTP traffic intended to trigger excessive memory allocation in Apache's mod_http request-processing path. If the server accepts and processes the request in the vulnerable code path, Apache may allocate unusually large memory buffers or otherwise consume memory until worker processes fail, the operating system kills processes, or the server becomes unable to respond reliably. Repeated requests can sustain the denial of service and may also amplify impact on shared hosts, reverse proxies, or application stacks behind Apache.

How to fix it

Upgrade Apache HTTP Server to a vendor-provided version that fixes this vulnerability as soon as one is available for the deployed distribution or packaging channel. The affected range is Apache HTTP Server 2.4.17 through 2.4.67, so systems in that range should be treated as vulnerable unless the operating system vendor has backported a fix. For Debian-based systems, apply the relevant security update from the Debian security repository rather than relying only on upstream version strings, because distributions may backport fixes without changing to the latest upstream release. If immediate upgrade is not possible, reduce exposure by restricting access to trusted networks, placing the service behind a protective reverse proxy or WAF capable of enforcing strict HTTP request size and header limits, lowering maximum accepted request sizes where operationally safe, applying rate limits, and ensuring process supervision restarts failed Apache workers. These mitigations reduce risk but should not be considered a substitute for patching.

How to confirm the fix worked

Inventory all Apache HTTP Server deployments and confirm whether any run versions 2.4.17 through 2.4.67 or distribution packages that have not received the vendor fix. Validate remediation by checking the installed package version and vendor changelog or security advisory, not only the Apache banner. On Linux, use package-manager queries such as dpkg -l, apt-cache policy, rpm -q, dnf info, or yum info as appropriate, and compare against the vendor-fixed package. Confirm that running processes were restarted after patching, because an upgraded package does not protect a still-running old httpd/apache2 process. From an exposure perspective, verify that internet-facing Apache services are either patched or protected by request-size controls and rate limits. Avoid destructive proof-of-concept testing in production; use vendor-safe test procedures or a controlled staging environment if exploit validation is required.

Typical attack path

1. Scan for internet-facing or internally reachable Apache HTTP Server instances.
2. Fingerprint Apache version or infer vulnerable exposure from banners, package metadata, headers, or behavior.
3. Send crafted HTTP requests designed to trigger excessive memory allocation in the vulnerable HTTP handling path.
4. Repeat or parallelize requests to increase memory pressure and exhaust Apache worker processes or host memory.
5. Maintain traffic until the service becomes slow, returns errors, drops connections, or becomes unavailable.

How to detect it

To determine whether exploitation may already have occurred, review Apache access logs, error logs, system logs, and host resource telemetry around periods of web service slowdown, HTTP 5xx spikes, connection resets, or Apache restarts. Focus on bursts of unusual HTTP requests from the same source or small set of sources immediately preceding high memory consumption, worker crashes, OOM killer events, or service unavailability. Useful log sources include Apache access.log and error.log, journald or syslog, kernel logs, process accounting, EDR telemetry, reverse-proxy/WAF logs, load balancer health-check logs, and infrastructure monitoring for memory, swap, process count, and restart events. Look for requests with unusually large request lines, excessive headers, abnormal Content-Length values, malformed HTTP syntax, repeated failed requests, or traffic patterns that correlate with Apache memory growth. Because the provided data does not include a unique exploit payload or actor-specific signature, detection should emphasize behavioral correlation: suspicious HTTP request bursts followed by Apache memory exhaustion, worker termination, OOM events, or availability loss.

• AH00161: server reached MaxRequestWorkers setting
• AH00484: server reached MaxRequestWorkers setting
• AH00052: child pid
• seg fault or similar nasty error detected
• Cannot allocate memory
• Out of memory
• oom-killer
• httpd invoked oom-killer
• apache2 invoked oom-killer
• apache2.service: Main process exited
• apache2.service: Failed with result
• httpd.service: Main process exited
• httpd.service: Failed with result
• AH00045: child process
• AH00428: Parent: child process exited with status

What your security team should do

• Prioritize inventory of all internet-facing Apache HTTP Server instances and identify versions 2.4.17 through 2.4.67 or unpatched vendor builds.
• Patch or upgrade affected Apache packages using official vendor repositories, then restart Apache and validate the running binary/package state.
• Apply compensating controls immediately for exposed systems that cannot be patched, including request-size limits, rate limiting, access restrictions, and WAF or reverse-proxy filtering.
• Increase monitoring for Apache memory exhaustion, abnormal request volume, worker crashes, 5xx spikes, and operating-system OOM killer events.
• Review recent web access logs and system logs for signs of repeated malformed or unusually large HTTP requests followed by service instability.
• Ensure Apache is managed by a service supervisor and has sane resource limits to prevent one web service from destabilizing the entire host.
• Track vendor advisories for exact fixed package versions, especially for Debian and other downstream distributions that may backport the fix.