Apache HTTP Server 2.4.69: 20 Security Fixes and Key Changes

Apache HTTP Server 2.4.69 was released on October 1, bringing 20 security fixes together with changes to HTTP/2 handling, Digest authentication, OpenSSL 4 compatibility and the project's testing system. The release affects the stable 2.4 branch and fixes vulnerabilities in versions going back as far as 2.4.0. For administrators, the interesting part is not just the number of security fixes but the way several long-standing server behaviors have been tightened at the same time.

Apache HTTP Server 2.4.69 closes 20 vulnerabilities from the 2.4 branch

The Apache project's security tracker lists 20 vulnerabilities fixed in 2.4.69, covering components such as HTTP/2, WebDAV, authentication, proxy modules and Windows path handling. The severity ratings assigned by Apache range from low to moderate, but the practical impact varies considerably by configuration because many affected modules are optional or require specific features to be enabled. Several flaws affect every 2.4.x release back to 2.4.0, while others begin with later versions such as 2.4.60 or 2.4.67. That means the upgrade is relevant even for installations that have been running an older 2.4 release for years.

The HTTP/2 fix prevents an already-started response from disappearing

One of the most useful behavioral changes is in mod_http2, Apache's module for HTTP/2 support. HTTP/2 allows multiple streams to share one connection, so several requests and responses can be active at the same time. Previously, when a client sent a graceful GOAWAY signal while streams were still being processed, Apache could tear down the session and drop an in-flight response. Version 2.4.69 instead drains the open streams before closing the session, matching the behavior required by RFC 9113, the current HTTP/2 specification.

The distinction matters most for servers handling many concurrent HTTP/2 requests, particularly those sitting behind reverse proxies or serving applications that keep several requests active on the same connection. A graceful shutdown should tell the server to stop accepting new work while allowing existing work to finish; dropping an already-running response defeats that expectation. Apache's change therefore addresses a specific correctness problem rather than promising a general performance increase. There is no verified benchmark in the release material showing that 2.4.69 makes HTTP/2 faster, so the safer interpretation is that it makes this shutdown path behave more predictably.

Digest authentication drops an older protocol behavior

Apache's mod_auth_digest module handles HTTP Digest authentication, a challenge-response authentication mechanism that avoids sending a password directly in the request. Version 2.4.69 removes support for the original RFC 2069 form of Digest authentication as part of a broader rewrite of the module. RFC 2069 predates the later RFC 2617 specification, so this is effectively a cleanup of legacy authentication behavior rather than a new login feature. Sites that explicitly depend on old Digest authentication behavior should therefore test authentication before replacing an existing server build.

Some of the fixed vulnerabilities only matter under specific configurations

The 20 security fixes are not 20 identical threats to every Apache installation. For example, one moderate issue in mod_vhost_alias involves a stack-based buffer overflow when a particular virtual-host configuration uses an expanded hostname format and permits unusually large Host headers. Another issue in mod_dav_fs requires an authenticated WebDAV client with write access, while the mod_proxy_uwsgi flaw depends on a proxy configuration involving a crafted response. These conditions reduce the number of installations directly exposed to each individual bug, but they also make configuration review important because administrators cannot judge applicability from the Apache version number alone.

The fixed set also includes problems involving authentication state, information disclosure, denial of service, memory errors and malformed protocol handling. Apache's own tracker records affected versions for every issue, making it possible to compare an installation's version and enabled modules with the relevant fixes. That is more useful than treating the release as a single generic security event because a server using only static files has a very different exposure from one running WebDAV, proxying application traffic and using several authentication modules. The release still provides a single upgrade path for all of those cases.

OpenSSL 4 support arrives through the certificate-management stack

Apache 2.4.69 also adds OpenSSL 4 compatibility to mod_md, the module used for managing certificates through automated certificate authorities. OpenSSL is the widely used cryptographic library that provides encryption and certificate functionality to software such as web servers. The change is relevant to administrators preparing systems for newer OpenSSL releases, but it should not be read as Apache requiring OpenSSL 4 everywhere: the project's release announcement still lists Apache Portable Runtime, or APR, and APR-Util version 1.5.x as the minimum dependencies, with some features requiring the 1.6.x series.

The same area also changes the default behavior of MDServerStatus, which exposes status information for managed domains and certificates. In 2.4.69 that status facility is disabled by default, reducing information exposed through the server-status mechanism unless an administrator deliberately enables it. This is a configuration-hardening change rather than a performance feature, and existing deployments that rely on that status information should check their configuration after upgrading.

Apache's own test system has moved from Perl to Python and pytest

One of the least visible changes could have the longest effect on future releases. Apache has ported its older Perl-based test framework to Python and pytest, a popular Python testing framework, and the new test material is included in the source tree under the test directory. The test infrastructure exercises areas including HTTP behavior, modules, security regressions, SSL and TLS, and HTTP/2. This does not change how an installed Apache server handles requests, but it changes how contributors and maintainers can reproduce bugs and prevent them from returning.

That matters because several of the 2.4.69 fixes are regression-style problems: a crash in a directory-processing path, malformed protocol handling and subtle HTTP/2 behavior are difficult to protect against with manual testing alone. A test suite that can reproduce those cases gives maintainers a repeatable check whenever related code changes. Apache's move from a decades-old Perl test environment to Python and pytest therefore belongs in the release story even though normal server operators will never see it in the interface. It is infrastructure for making later maintenance less dependent on the exact conditions that exposed a bug the first time.

Upgrading Apache 2.4.69 still requires configuration testing

The Apache project recommends 2.4.69 as the current stable 2.4 release, but an upgrade should still be treated as a configuration change rather than a simple file replacement. Administrators using custom modules need to account for Apache's documented module compatibility requirements, while installations using threaded Multi-Processing Modules, or MPMs, need to ensure their modules and dependent libraries are thread-safe. The release also requires APR and APR-Util at version 1.5.x or newer, with some features requiring 1.6.x.

The most useful pre-production test is therefore specific to the server's actual configuration: exercise HTTP/2 traffic, authentication, reverse proxy rules, WebDAV, certificate automation and any third-party modules that are enabled. Pay particular attention to Digest authentication and managed-domain status if those features were configured explicitly, because 2.4.69 changes their behavior. For installations exposed directly to the internet, the 20 fixed vulnerabilities add a concrete reason to move the patched build through the normal staging process rather than leaving an older 2.4 release indefinitely. The new version is already the project's current stable release, so the next step is validating the configuration that will run on it.