CVE-2025-49630 DoS in Apache mod_proxy_http2: Patch Now

A recently disclosed vulnerability, tracked as CVE-2025-49630, allows an untrusted client to trigger an assertion failure inside Apache HTTP Server’s mod_proxy_http2 module in particular reverse-proxy configurations, producing a reliable denial-of-service (DoS) condition against affected servers. The flaw affects Apache HTTP Server 2.4.26 through 2.4.63 and was fixed in the 2.4.64 release; operators running an impacted configuration should treat the issue as urgent and remediate promptly. (httpd.apache.org)

---

Background / Overview​

mod_proxy_http2 is the Apache module that enables HTTP/2 proxying (h2/h2c) and is commonly used when httpd is fronting an HTTP/2-capable backend. When configured as a reverse proxy to an HTTP/2 backend with the directive ProxyPreserveHost on, the server preserves the original Host header for proxied requests rather than replacing it with the backend hostname. That configuration is convenient for backends that expect the original Host, but it interacts with mod_proxy_http2 code paths that, in the vulnerable releases, can trip a reachable assertion when presented with crafted input from an untrusted client. (httpd.apache.org)
The Apache project marked the bug as fixed in the 2.4.64 release published in July 2025; vendor and distribution trackers (Amazon Linux, Debian, Red Hat and others) followed with vendor-specific advisories and package updates. The public CVSS v3.1 score commonly distributed for this issue is 7.5 (High) — driven by network attack vector, low complexity and availability impact only. (httpd.apache.org)

---

What exactly is the problem?​

The technical root cause (in plain language)​

An assertion inside mod_proxy_http2 can be reached when the proxy is configured to forward requests to an HTTP/2 backend while preserving the incoming Host header (ProxyPreserveHost on). An attacker who can send requests to the proxy — i.e., any client that can reach the fronting httpd instance — can craft requests that exercise the vulnerable code path and cause the assertion to fire. When the assertion is hit, the process handling the request may abort, producing a worker crash and resulting in reduced capacity or complete unavailability of the proxied service. (httpd.apache.org)

Conditions required to trigger the issue​

• Apache HTTP Server version between 2.4.26 and 2.4.63 inclusive. (httpd.apache.org)
• mod_proxy + mod_proxy_http2 loaded and in use.
• A reverse proxy configuration where the backend supports HTTP/2 (h2/h2c). (httpd.apache.org)
• ProxyPreserveHost On in scope for the proxied virtual host or server context. (httpd.apache.org)

If your deployment does not match all of these conditions, the risk is reduced; however, because the configuration combination is commonly used in modern deployments, many operators must still verify inventory and apply fixes. Distribution maintainers and third-party vendors confirmed affected ranges and published fixes and advisories.

---

How severe is the risk?​

• Attack vector: Network — a remote client can attempt exploitation.
• Attack complexity: Low — no complex preconditions beyond reaching the proxy.
• Privileges required: None — no authentication required.
• Impact: Availability only — successful triggers crash/abort worker processes, producing DoS. No confidentiality or integrity impacts are described. (httpd.apache.org)

Multiple CVE trackers (NVD, vendor advisories, distribution security trackers) converge on the same high-level conclusion: the vulnerability is a reachable assertion with a high availability cost and a high priority for any server acting as a reverse proxy to HTTP/2 backends with ProxyPreserveHost enabled. That said, the issue is limited to a specific configuration; environments that don't proxy HTTP/2 backends or that have disabled ProxyPreserveHost are not impacted. (httpd.apache.org)

---

Has a public exploit or PoC been released?​

Some vulnerability aggregators and trackers report references to public proof-of-concept code or demonstrations, but authoritative vendor advisories and the Apache announcement do not point to a broadly trusted, weaponized exploit kit at the time of the initial disclosure. Treat claims of a public PoC cautiously: several data feeds flag there may be public code on third-party code hosting sites, but this reporting is uneven and often unverified. Until PoC code is validated by trusted sources, defenders should assume that practical exploitation is straightforward (network access + correct config) and act accordingly. Always assume exploitation is possible in production-facing proxies and remediate without waiting for confirmed exploit activity.

---

Who and what is affected (inventory guidance)​

• Apache HTTP Server upstream versions 2.4.26 → 2.4.63 are the stated affected range. Distributors and downstream products that package or embed these versions are potentially affected. Confirm the package version and whether mod_proxy_http2 is enabled. (httpd.apache.org)
• Container images, appliance images, and OS packages that include the affected httpd binaries can carry the vulnerability into production images — scanning registries and images is essential.
• Not every installation of 2.4.x is exploitable: you must have an HTTP/2 backend proxy setup with ProxyPreserveHost on and mod_proxy_http2 active. Still, many modern front-ends and platform images use this setup by default; do not assume immunity.

Operational checklist (quick inventory checks):

• Identify all httpd instances and distribution package versions (rpm -q httpd, dpkg -l | grep apache2, or container image inspection).
• Check whether mod_proxy and mod_proxy_http2 are loaded (apachectl -M or httpd -M).
• Inspect configuration files for ProxyPreserveHost directives and proxied backends configured to use HTTP/2.
• Include cloud and marketplace images, managed platform stacks, and third‑party appliances in your inventory sweep — many vendors published advisories and firmware updates referencing this CVE.

---

Immediate mitigations and recommended actions​

The only definitive fix is to install a patched httpd build — upgrade to Apache HTTP Server 2.4.64 or later (or apply your distribution vendor’s equivalent security update). Vendor trackers list fixed package versions and advisories for common distributions; follow your OS vendor guidance for patch packages and image rebuilds. (httpd.apache.org)
Short-term (fast, reversible) mitigations if immediate patching is impossible:

• Disable or set ProxyPreserveHost Off for affected vhosts where feasible. This removes the particular interaction that leads to the assertion. Test for application behavior changes before broad rollout since some backends rely on the original Host header. (httpd.apache.org)
• Restrict access to the reverse proxy from untrusted networks — use network ACLs, firewalls, or WAF rules to limit which clients can reach the proxied vhosts. Reducing exposure decreases the chance of exploitation.
• If you do not require HTTP/2 as a backend transport, consider proxying to HTTP/1.1 backends (i.e., avoid mod_proxy_http2) until a patch is applied. This may be an acceptable short-term change for some environments.

Important operational caveats:

• Disabling ProxyPreserveHost or disabling mod_proxy_http2 may change application behavior; validate in staging and coordinate with application teams.
• Network-level mitigations are stopgaps — attackers in the same trusted network, or insiders, could still reach the proxy and exploit it. Prioritize the patch.

---

Step-by-step remediation plan (recommended)​

• Inventory: run package and image scans to identify all Apache httpd instances and versions across VMs, containers, appliances and cloud images. Use automated image-scanning tools where available.
• Prioritize: mark as highest priority any front-end proxies that:
• Terminate public traffic, or
• Are exposed to untrusted networks, or
• Proxy to HTTP/2 backends with ProxyPreserveHost on.
• Patch: apply vendor-supplied httpd updates that include the 2.4.64 upstream fix, or upgrade to 2.4.64+ in a controlled maintenance window. For container workloads, rebuild images from patched base layers and redeploy via CI/CD. (httpd.apache.org)
• Temporary configuration controls: if patching is delayed, disable ProxyPreserveHost or disable mod_proxy_http2; restrict access at the network perimeter and apply WAF rules to detect anomalous patterns.
• Verify: after patching, run functional tests that exercise proxying to your HTTP/2 backends to ensure requests flow correctly and that crashing behavior no longer occurs. Consider a controlled reproduction test in a sandboxed environment to confirm mitigation. (httpd.apache.org)
• Monitor: increase logging and correlate Apache error logs and system-level process restarts for signs of assertion failures or worker aborts. Hunt for HTTP/2 proxy anomalies.

Example commands and checks (adapt to your distro):

• Check Apache version: apachectl -v or httpd -v
• List loaded modules: apachectl -M | grep proxy
• Find ProxyPreserveHost usage: grep -R "ProxyPreserveHost" /etc/httpd /etc/apache2 || true
• For RPM-based systems: rpm -q httpd ; for Debian: dpkg -l | grep apache2

---

Detection and monitoring guidance​

Detecting attempted exploitation or successful triggers focuses on logs and process behavior:

• Apache error log signatures: look for assertion messages, stack traces, “worker aborted”, or abrupt child process terminations around mod_proxy_http2. The official apachectl and systemd logs will surface these events. (httpd.apache.org)
• Process lifecycle: repeated httpd child crashes, core dumps, or service restarts correlated with incoming traffic patterns indicate exploitation attempts. Monitor error rate baselines.
• Network traffic: anomalous request patterns to proxied endpoints, especially from single client IPs or crafted HTTP/2 sequences, can be meaningfully suspicious. Consider adding targeted WAF signatures or rate-limiting on proxied vhosts.

Hunting checklist:

• Inventory and correlate which fronting hosts use mod_proxy_http2.
• Search logs for “assert” or module identifiers referencing mod_proxy_http2.
• Correlate spikes in 5xx responses, child process deaths, and systemd restarts with inbound request times.
• If you capture packet traces, analyze HTTP/2 frames near crash events to identify malicious sequences.

---

Vendor and distribution responses​

Apache fixed the bug in the 2.4.64 release and published the advisory in the 2.4 vulnerabilities list. Major Linux distributions and downstream vendors released corresponding security updates or backports; check your vendor security advisories for the correct package and release date. Amazon Linux, Oracle Linux, Debian and others published advisories and fixed packages after the upstream release. Some appliance vendors issued firmware updates for devices embedding the vulnerable httpd. (httpd.apache.org)
Cross-vendor confirmation is strong here: the upstream fix is available and widely packaged by OS vendors, which makes remediation straightforward in most production environments. Still, the operational challenge is rebuilding and redeploying containers and updating firmware/images for appliances, which can take longer and require coordination.

---

Risk analysis — strengths, weaknesses, and practical impact​

Notable strengths in the response​

• Upstream patch availability. The Apache Project released a fix (2.4.64) rapidly after responsible disclosure, allowing downstream vendors to respond. (httpd.apache.org)
• Broad cross-vendor acknowledgment. Distributors and vulnerability databases concur on the affected range and remediation path — consistent guidance accelerates triage.

Practical operational risks​

• Configuration-dependency creates inventory friction. Many organizations track package versions but not specific module usage or per-vhost directives like ProxyPreserveHost; blind upgrades risk missing exposed hosts. Inventory must include config-level checks.
• Container and appliance lag. Embedded systems, marketplace VM images and container images may not be patched on the same cadence as OS packages; these artifacts require rebuilds and redeploys.
• Mitigations have tradeoffs. Disabling ProxyPreserveHost is an effective stopgap but may break backends that depend on the original Host header. Similarly, disabling mod_proxy_http2 removes HTTP/2 backend performance benefits. Balance risk vs. functionality.

---

Practical examples (what to do this week)​

• Run an inventory sweep to list all Apache instances and identify those with mod_proxy_http2 enabled. Use centralized CMDB, image registry scans, or simple package checks.
• For exposed proxies that meet the vulnerable criteria, schedule immediate patching to 2.4.64+ or deploy vendor-provided patched packages. If you cannot patch within 24–72 hours, apply configuration mitigations (ProxyPreserveHost off) and network access controls. (httpd.apache.org)
• Rebuild and redeploy container images from patched base images; do not rely on in-container runtime upgrades as a long-term fix.
• Add detection: increase the verbosity of Apache error logs for a limited window and monitor for assertion failures or mod_proxy_http2-related errors. Correlate with WAF and firewall logs.

---

Verification and post-patch validation​

After upgrading to a patched Apache build or applying a mitigation:

• Confirm httpd binary version and verify the presence/absence of mod_proxy_http2 as intended (apachectl -v ; apachectl -M).
• Re-run any functional proxy tests that your applications depend on — ensure expected Host header semantics remain correct if you changed ProxyPreserveHost.
• Monitor for repeat occurrences of child process crashes and check that error logs no longer show assertion traces tied to mod_proxy_http2. (httpd.apache.org)

---

Caveats and unverifiable claims​

• Several third-party trackers report a public PoC; however, the presence and reliability of public exploit code vary across feeds and are not universally validated. Treat third-party PoC claims with caution, and do not wait for weaponized exploits to appear before patching.
• Because the vulnerability is triggered only under a specific configuration, blanket statements like “all Apache 2.4.x instances are exploitable” are incorrect. Operators must confirm module usage and per‑vhost configuration to determine true exposure. (httpd.apache.org)

---

Conclusion — the short, actionable message​

CVE-2025-49630 is a configuration-dependent but practically significant denial-of-service vulnerability in mod_proxy_http2 that affects Apache 2.4.26 → 2.4.63. The fix is available in 2.4.64; operators should prioritize inventory, patching, and configuration review for any front-end proxies that forward to HTTP/2 backends while preserving the Host header. If immediate patching is not feasible, disable ProxyPreserveHost for affected vhosts and restrict access from untrusted networks as a stopgap — but treat these only as temporary measures. Verify remediation by testing proxied flows and watching logs for assertion-related errors. (httpd.apache.org)
Act now: build an inventory, apply upstream or vendor patches, update images and appliances, and verify that resumed traffic does not lead to worker aborts. The upstream fix and vendor packages exist — the remaining work is operational: find the affected artifacts and apply the update. (httpd.apache.org)

---

Summary of the most important facts (one-liners):

• Vulnerability: CVE-2025-49630 — mod_proxy_http2 reachable assertion causing DoS. (httpd.apache.org)
• Affected: Apache HTTP Server 2.4.26 — 2.4.63 (only when proxying to HTTP/2 backends with ProxyPreserveHost on). (httpd.apache.org)
• Fixed in: 2.4.64 — upgrade or apply vendor patches. (httpd.apache.org)
• CVSS (v3.1): 7.5 (High) — network reachable, low complexity, availability impact.
• Immediate mitigation: patch; if not possible, set ProxyPreserveHost Off and restrict access. (httpd.apache.org)

Take inventory, patch promptly, and validate — that combination eliminates the risk and restores normal availability. (httpd.apache.org)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center