The Apache Software Foundation released HTTP Server 2.4.69 on October 1, 2026 with fixes for twenty vulnerabilities. Five are rated moderate and the rest low. There are no criticals. That is unusual for an Apache release, and it changes the shape of the response: this is not a patch-everything-in-panic release, it is a release where almost everything depends on how your server is configured.
The most severe item, CVE-2026-63292 in mod_vhost_alias, allows a stack overflow via an oversized Host header and ASF says it may allow arbitrary code execution — but only if you use VirtualDocumentRoot with a hostname format specifier and have raised LimitRequestFieldSize above its default. Two other moderates are Windows-only or WebDAV-specific. Meanwhile one of the low-rated items, CVE-2026-73636, is a genuine cryptographic failure: a nonce lifetime of zero turns digest authentication into something replayable. Rank that one higher than its label suggests if you rely on digest auth.
Key takeaways:
- Patch to 2.4.69 regardless. The work is deciding what else you need to change, not whether to upgrade.
- Only five of the twenty are rated moderate by ASF, and every “code execution” claim is conditional on non-default configuration.
- ASF explicitly warns that impact varies by platform, so do not read another vendor’s rating as contradicting theirs.
- CVE-2026-73636 is a credential-replay problem, not a memory-safety one, and its low rating understates it for digest-auth deployments.
- Two moderation-relevant items only apply on Windows, and two only apply if WebDAV is enabled. Check before you escalate them internally.
The five moderate issues
| CVE | Module | Condition ASF states |
|---|---|---|
| CVE-2026-63292 | mod_vhost_alias | Stack overflow from a Host header over 8192 bytes; denial of service or “potentially execute arbitrary code”. Requires VirtualDocumentRoot with a hostname format specifier and LimitRequestFieldSize raised above default |
| CVE-2026-57941 | mod_http2 | Use-after-free through re-entrancy on a shared session->bbtmp, described as a memory write |
| CVE-2026-93546 | mod_dav_fs | Integer overflow via a PROPPATCH declaring many XML namespaces; worker crash plus persistent corruption of the directory property database |
| CVE-2026-42528 | mod_dav | Shared-lock memory calculation overflow; crash. Affects 2.4.67 and earlier |
| CVE-2026-59685 | core, Windows only | Out-of-bounds write in ap_directory_walk() during 8.3 short-name expansion when CASE_BLIND_FILESYSTEM is set |
Read CVE-2026-63292 carefully rather than skimming the severity. It is the only one with a code-execution statement, and both of its preconditions are configurations people do run and then forget about. A VirtualDocumentRoot with a hostname placeholder is a normal multi-tenant setup, and raising LimitRequestFieldSize is something people do to accommodate large cookies or bearer headers without realising they have also enlarged the attacker’s budget.
If you meet both conditions, treat this as urgent regardless of the “moderate” label. If you meet neither, it does not apply to you at all.
CVE-2026-59685 deserves an explicit note: it is Windows-only and requires CASE_BLIND_FILESYSTEM. On a Linux deployment it is noise. On a Windows Apache host with 8.3 short-name expansion enabled, it is an out-of-bounds write in the core request path.
Two WebDAV items worth understanding
If you run WebDAV, two entries matter more than their ratings imply.
CVE-2026-93546 is a persistent corruption issue, not just a crash. An integer overflow triggered by a PROPPATCH request that declares a large number of XML namespaces can damage the on-disk property database. A worker crashing is an availability problem you notice; a property database left corrupted is a data-integrity problem you might not notice until restore fails.
CVE-2026-58415 is rated low and is an information disclosure: reading the .DAV state directory exposes dead properties of resources the requesting user is not authorised to author. In a shared-hosting or multi-tenant WebDAV arrangement, that is a metadata leak across a trust boundary.
The one that is not a memory-safety bug
CVE-2026-73636 affects mod_auth_digest and is described as capture-replay of digest credentials by a man-in-the-middle when AuthDigestNonceLifetime is set to 0. Two companion items in the same module are memory-safety bugs: CVE-2026-48005, a forced re-authentication denial of service when AuthDigestNcCheck is set, and CVE-2026-73637, a use-after-free causing auth state corruption under concurrent digest requests.
Setting a nonce lifetime to zero means nonces never age out. That converts a property digest authentication is designed around — that a captured response is only replayable within a narrow window — into something that can be replayed indefinitely. If you use digest auth anywhere, this is worth checking independently of your patch decision, because the fix is a configuration change, not just an upgrade.
Two broader auth notes from the same release: CVE-2026-59797 notes that SSLRequire allows .htaccess ap_expr file functions, and CVE-2026-79768 is a path-equivalence information disclosure in mod_userdir via /./ in the absolute non-wildcard form.
Reverse proxy items
If Apache is a reverse proxy rather than an origin server, three entries are worth reading, and one of them is a request-smuggling primitive:
- CVE-2026-63718 —
mod_proxy_uwsgi, Transfer-Encoding response smuggling, affecting 2.4.30 through 2.4.68 - CVE-2026-63045 —
mod_proxy_ftp, a malicious PASV reply can redirect the proxy’s data connection to an arbitrary third party - CVE-2026-56449 —
mod_proxy_html, out-of-bounds write indump_contenton a crafted response body
Response smuggling deserves a moment. When a proxy and an upstream disagree about where a response ends, requests can be smuggled past access controls. If Apache sits in front of anything, that is a class of bug worth prioritising above a same-severity memory-safety issue in a module you do not load.
Two rating caveats
First, ASF states that “security impact can vary between platform to platform.” If another scanner gives you a higher CVSS for the same CVE, that is not necessarily an error — the base score is platform-neutral and your deployment is not.
Second, the low/modere split here is not the same distribution as a typical Apache release, and that is a signal rather than an anomaly to apologise for. Most of these require a specific module, a specific configuration, or a specific platform. A count of twenty will read as alarming in a dashboard; a count of what actually applies to your server is usually much smaller.
What to actually do
- Upgrade to 2.4.69. Every fixed item is resolved by the release regardless of whether you were exposed.
- Search your configuration for
VirtualDocumentRootandLimitRequestFieldSize. If both are present, treat CVE-2026-63292 as high priority. - Search for
AuthDigestNonceLifetimeandAuthDigestNcCheck. A zero nonce lifetime is a configuration weakness independent of the patch. - Confirm whether
mod_dav/mod_dav_fsandmod_proxy_uwsgiare loaded. Several entries are inert otherwise. - On Windows hosts, check
CASE_BLIND_FILESYSTEMand 8.3 name generation. - Back up your WebDAV
.DAVproperty databases before upgrading if you run WebDAV. Persistent corruption is harder to recover from than a crash.
Related reading on DevStackIO
If you need to establish current exposure before you patch, how to check if a website or internet service is down covers the diagnostic side, and the HTTP status code reference is useful when you are walking a response by hand rather than reading a scanner table.
References
- Apache HTTP Server 2.4.x vulnerabilities — ASF security page, “Fixed in Apache HTTP Server 2.4.69” section, 1 October 2026
- Apache HTTP Server — release download and changelog
- MITRE ATT&CK T1190 — Exploit Public-Facing Application
Related Tools
Try these companion tools on DevStackIO Tools:
- CSP generator — build Content Security Policy headers to harden Apache against XSS attacks.
