Apache HTTP Server Release History: NCSA httpd to 2.4 and Security

The Apache HTTP Server began in February 1995 as a shared set of patches to NCSA httpd, shipped its first public release (0.6.2) in April 1995 and reached 1.0 on 1 December 1995. Today only the 2.4 branch is maintained: 2.4.69, released on 1 October 2026, is the current release, and 1.3, 2.0 and 2.2 are all end of life.

Security fixes ship only as new 2.4.x releases, listed on a per branch vulnerabilities page with affected and fixed versions. Every date and version below was checked against httpd.apache.org, the project's change log, the Apache archive or the Apache Software Foundation's own pages.

Key takeaways

• Origin: eight webmasters patched NCSA httpd 1.3 in early 1995; the Apache Software Foundation (ASF) followed in 1999.
• One live branch: 2.4 is the only maintained branch. 2.2 ended with 2.2.34 in July 2017, 2.0 with 2.0.65 in July 2013 and 1.3 with 1.3.42 in February 2010.
• Odd and even numbers: since 2.1, odd minor versions (2.1, 2.3) are alpha and beta development lines and the next even number (2.2, 2.4) is the general availability branch.
• New features land in 2.4 patch releases. mod_http2 arrived in 2.4.17 (October 2015), mod_md in the 2.4.30 change set (first shipped in the 2.4.33 tarball, March 2018), and TLS 1.3 support in the 2.4.36 change set (first shipped in 2.4.37, October 2018).
• MPMs decide the process model. prefork runs one request per process, worker and event use threads, and event hands idle keep alive connections to a listener thread. On modern systems the build default is almost always event.
• Security process: private reports to the ASF security team (a CVE Numbering Authority), fixes in a voted 2.4.x release, and a vulnerabilities page with affected and fixed versions.
• 2026 has been busy: 11, 13 and 20 CVEs fixed in 2.4.67, 2.4.68 and 2.4.69.
• Banners lie about patch level. Distributions backport fixes into older version numbers, so check the package changelog, not the Server header.

How did the Apache HTTP Server begin?

NCSA httpd stalls

The project's own About page sets the scene precisely. In February 1995 the most popular web server software was the public domain HTTP daemon written by Rob McCool at the National Center for Supercomputing Applications (NCSA) at the University of Illinois, Urbana-Champaign. Development of that daemon had stalled after McCool left NCSA in mid 1994. Webmasters who ran it had written their own bug fixes and extensions, and nobody was collecting them into one distribution.

A small group of those webmasters started coordinating by private email. Brian Behlendorf and Cliff Skolnick set up a mailing list, a shared information space and logins on a machine in the California Bay Area, with bandwidth donated by HotWired.

Eight core contributors and the first release

By the end of February 1995 eight people formed the original Apache Group: Brian Behlendorf, Roy T. Fielding, Rob Hartill, David Robinson, Cliff Skolnick, Randy Terbush, Robert S. Thau and Andrew Wilson, with further contributions from Eric Hagberg, Frank Peters and Nicolas Pioch. They took NCSA httpd 1.3 as the base, added every published bug fix and worthwhile enhancement they could find, tested the result on their own servers and published the first official public release, Apache 0.6.2, in April 1995.

NCSA restarted its own development in the same period, and two of its server developers joined the Apache list in March 1995 as honorary members so the projects could share fixes. Apache started as a downstream patch set, the same position many teams are in today when they carry local fixes on top of an upstream component.

Shambhala: modules, pools and pre-forking

The patch set was popular, but the group knew the code base needed a redesign. In May and June 1995, while Rob Hartill and others built features for the 0.7.x line (including pre-forked child processes), Robert Thau designed a new architecture code-named Shambhala. It introduced three ideas that still define httpd:

• a modular structure with an API for extensions,
• pool-based memory allocation, where memory is tied to the lifetime of a request or connection and released in one step,
• an adaptive pre-forking process model.

The group switched to the Shambhala base in July 1995, merged the 0.7.x features and shipped Apache 0.8.8 in August. After beta testing, ports to many platforms and a new documentation set written by David Robinson, Apache 1.0 was released on 1 December 1995. The About page notes that less than a year after the group formed, Apache had passed NCSA httpd as the most used server on the internet according to a 1996 web server survey.

From the Apache Group to the Apache Software Foundation

In 1999 members of the Apache Group formed the Apache Software Foundation to provide organisational, legal and financial support for the server. The ASF describes itself as a US 501(c)(3) charitable organisation, funded by individual donations and corporate sponsors and run almost entirely by volunteers, supporting hundreds of projects since 1999.

The governance model that came out of the Apache Group still runs httpd:

• Committers have write access to the repositories; everyone has read access.
• The Project Management Committee (PMC) decides committers, direction and releases. "Apache Group" and "Apache Core" are no longer used.
• Changes are voted. During a release cycle a code change needs three +1 votes and no vetoes, and a veto needs a convincing technical justification.
• New PMC members are nominated by a member and approved unanimously, usually after six months or more of contribution.

If you track the governance of your open source dependencies, httpd is a useful reference point. Our post on ASF license categories A, B and X covers the licensing side of the same foundation.

Timeline: Apache httpd releases and milestones

The dates below come from the project's About page, the per branch vulnerabilities pages and the file dates in the Apache release archive (archive.apache.org/dist/httpd). Archive file dates are when the tarball was placed in the archive, which is normally the release day or a day or two before the announcement.

Not every version number becomes a release. The 2.4 change log marks 2.4.8, 2.4.11, 2.4.13 to 2.4.15, 2.4.30 and 2.4.31 as "not released", and the archive has no 2.4.36 tarball, so the TLS 1.3 change logged under 2.4.36 first shipped in 2.4.37.

How do Apache httpd version numbers work?

The odd and even rule

The project's release guidelines describe an odd and even strategy adopted with 2.1. Development happens in alpha and beta releases with an odd minor number, and the general availability release takes the next even minor number. The guidelines' example is 2.1.0-alpha through 2.1.9-beta, ending in 2.2.0. For 2.4, the archive holds 2.3.4-alpha (December 2009) through 2.3.16-beta (December 2011), followed by 2.4.1 in February 2012.

That makes httpd different from projects that cut a new stable branch every year. There has been no 2.6 general availability release. Development happens on trunk, and changes reach the 2.4.x branch only after they are proposed and voted on by the project's active members, as the About page describes for code changes during a release cycle. That is why so much of what people think of as "modern Apache" (HTTP/2, ACME certificates, TLS 1.3) arrived as a 2.4 patch release rather than a new minor version.

Who can make a release, and how it is approved

The release guidelines say that a release manager builds a candidate tarball from the repository, and that for the ASF to release it, at least three PMC members must vote +1 and there must be more positive than negative votes. There is no veto on a release vote. The guidelines also describe the habit of running a candidate in production for roughly 48 to 72 hours before voting, and note that some committers will not vote until they have tested it themselves.

For anyone building httpd from source, the download page adds the last step of the chain: you must verify the integrity of downloaded files using the signatures from the main distribution directory, checked against the project's KEYS file. Only current recommended releases stay on the main distribution site; 1.3, 2.0 and 2.2 live on the archive site.

What changed in each major branch?

1.3 (1998 to 2010)

Apache 1.3.0 reached the archive on 5 June 1998, and the series lasted until 1.3.42 in February 2010. Its vulnerabilities page lists 20 releases with security fixes and notes that 1.3 issues are no longer investigated. On Unix it used pre-forked processes, and TLS was not in the core distribution; mod_ssl became a bundled module only with 2.0.

2.0 (2002 to 2013): MPMs, APR and threads

The 2.0 "new features" document lists the architectural changes that still shape the server:

• Multi-Processing Modules (MPMs) moved the process and threading model out of the core, so each platform uses a model that suits it.
• Unix threading: a hybrid multi-process, multi-threaded mode that the document says improves scalability for many, but not all, configurations.
• The Apache Portable Runtime (APR) separated platform code, so Windows and other non-Unix platforms use native APIs instead of POSIX emulation.
• IPv6 listening sockets by default, filters, a new module API and a new build system.
• mod_ssl bundled as an interface to OpenSSL's SSL/TLS protocols, plus mod_dav for WebDAV.

The first 2.0 general availability release was 2.0.35 (archive date 6 April 2002), and the line ended with 2.0.65 (archive date 2 July 2013).

2.2 (2005 to 2017): authentication, caching and proxies

2.2.0 reached the archive on 30 November 2005. The 2.2 new features document highlights a refactored set of authentication and authorisation modules (the split into authn and authz providers), caching modules that were declared ready for production, and proxy load balancing.

2.2 ran for nearly twelve years. The project home page states that it is end of life, with 2.2.34 in July 2017 as the final release and no further patches or security updates.

2.4 (2012 onward): the long-lived branch

2.4.1, the first 2.4 general availability release, reached the archive on 19 February 2012. The 2.4 vulnerabilities page says 2.4.1 included fixes for every vulnerability resolved in 2.2.22 and older releases. The 2.4 new features document lists, among many items:

• Run-time loadable MPMs, chosen with LoadModule instead of at compile time.
• The event MPM, no longer experimental and fully supported.
• A general purpose expression parser for directives such as RewriteCond and Header, plus If, ElseIf and Else sections.
• mod_proxy_fcgi, a FastCGI backend for mod_proxy, the usual way to connect httpd to PHP-FPM.
• Lower memory use than 2.2.

The upgrading guide for 2.2 to 2.4 is required reading for anyone still holding an old configuration: the access control syntax changed (the old Order, Allow and Deny directives moved to the mod_access_compat module, replaced by Require), and several defaults changed.

What makes 2.4 unusual is how much arrived after 2.4.1. The table below shows the features that came in patch releases.

Branch summary: first release, end of life and key security change

How do the prefork, worker and event MPMs differ?

An MPM decides how httpd turns connections into work: whether it uses processes, threads or both, and what happens to a connection while it waits. The MPM documentation says exactly one MPM must be loaded at any time.

The three Unix MPMs

prefork is described in its documentation as a non-threaded, pre-forking web server. A parent process manages a pool of child processes, and each child answers one request at a time. The docs say it suits sites that must avoid threading for compatibility with non-thread-safe libraries, and that it is the best MPM for isolating each request, so a problem with one request does not affect another. The main tuning rule is that MaxRequestWorkers must be big enough for your peak concurrency but small enough that all processes fit in physical RAM.

worker implements a hybrid multi-process, multi-threaded server. Each child process runs many threads, and each thread serves one connection. Its documentation says that using threads lets it serve a large number of requests with fewer system resources than a process-based server, while keeping much of the stability of a process-based server by running several processes. Threads in one process share memory, though, so a fault in one thread can affect the other threads in that process.

event is based on worker but fixes what its documentation calls the "keep alive problem". With prefork or worker, a client that keeps its connection open after a request ties up a whole process or thread while it decides whether to send another request. Event uses a dedicated listener thread in each process to handle the listening sockets, every socket in a keep alive state, and sockets where the handler has finished and only the sending of data remains. Worker threads are only used while there is real work to do. The docs say the total number of connections a single process can handle is regulated by the AsyncRequestWorkerFactor directive.

How the default is chosen

The MPM documentation gives the rule for Unix builds. If the system supports threads and thread-safe polling (epoll or kqueue), the default is event. If it supports threads but not thread-safe polling, the default is worker. If it supports neither, the default is prefork. The docs add that in practice the default will almost always be event, because modern operating systems support both. Windows uses mpm_winnt.

Since 2.4, MPMs can be built as loadable modules and switched with LoadModule. If an MPM is built statically, the server must be rebuilt to change it, using the --with-mpm=NAME option to configure. Distributions differ in which MPM they enable by default, so check yours rather than assuming.

Why the choice matters for PHP, TLS and resource limits

PHP. The prefork documentation's warning about non-thread-safe libraries is the reason so many older stacks run prefork: an in-process PHP module built without thread safety must not run under a threaded MPM. The 2.4 branch added mod_proxy_fcgi, which lets httpd hand PHP requests to a separate FastCGI process manager. That separates the PHP runtime from the web server process, lets you use event, and means the PHP runtime and the web server can be patched and restarted on separate schedules. When a PHP security release lands, it changes what you restart.

TLS and keep alive. TLS handshakes are expensive, so clients keep connections open and reuse them. Under prefork, every idle keep alive connection holds a whole process. Under event, the listener thread holds it and the worker thread is free. HTTP/2 makes this stronger still, since a browser opens one long-lived connection and multiplexes requests over it. The mod_http2 documentation adds that HTTP/2 requests are processed by the module's own worker threads, separate from the MPM's workers, which matters when you size thread and memory limits.

Resource limits as a security control. The project's security report page says it aims to avoid attacks that make the server consume resources out of proportion to its inputs, but cannot promise workarounds for generic problems such as a client streaming lots of data; those are configuration problems, not bugs. MPM limits (MaxRequestWorkers, ThreadsPerChild) and core request limits (LimitRequestFieldSize, LimitRequestBody) decide how a server behaves past normal load, so set them from measured peaks and review changes to them.

How did TLS support evolve in Apache httpd?

mod_ssl and its dependence on OpenSSL

TLS became a bundled part of httpd with 2.0, when mod_ssl was added as an interface to the SSL/TLS protocols provided by OpenSSL. That dependency is the most important fact about TLS in httpd: the protocol versions, ciphers and many TLS fixes available to your server depend on the OpenSSL version it is built against, not only on the httpd version. Our OpenSSL release history covers that library's branches and support periods.

The mod_ssl documentation records how the defaults moved. The SSLProtocol default is now all -SSLv3, and the docs note that up to 2.4.16 the default was all. The same page explains that TLS 1.1 and 1.2 need OpenSSL 1.0.1 or later.

TLS 1.3

The 2.4 change log entry for 2.4.36 adds support for OpenSSL 1.1.1 and TLS 1.3. It warns that TLS 1.3 brings behavioural changes compared with 1.2, that client and configuration changes should be expected, and that SSLCipherSuite gained support for TLS 1.3 ciphers at the virtual host level only. Since 2.4.36 was never released as a tarball, 2.4.37 (October 2018) was the first download with this change. The project home page now states that 2.4.43 or newer is required to operate a TLS 1.3 server with OpenSSL 1.1.1, so treat 2.4.43 as the practical minimum. Our guide to TLS 1.3 versus TLS 1.2 and what to disable covers the protocol side.

HTTP/2 and modern TLS

mod_http2 arrived in 2.4.17 as an HTTP/2 implementation donated to the project and merged as a core module. Its documentation notes that HTTP/2 does not itself require encryption, so two schemes exist: h2 (HTTP/2 over TLS, negotiated with ALPN) and h2c (HTTP/2 over plain TCP). For public sites h2 is the one that matters, so HTTP/2 and TLS configuration are tied together. The 2.4.18 change log added H2ModernTLSOnly, which refuses HTTP/2 on connections that do not meet modern TLS requirements. You enable HTTP/2 with the Protocols directive, for example Protocols h2 http/1.1.

The 2.4 vulnerabilities page shows why HTTP/2 deserves its own line in your inventory. Several entries for mod_http2 record the affected range as starting at 2.4.17, the version that introduced the module. If you do not serve HTTP/2, not loading mod_http2 removes that code from the running server entirely.

mod_md: ACME certificates inside httpd

mod_md manages the properties of domains across virtual hosts and provisions certificates through the ACME protocol. Its documentation says it is available in version 2.4.30 and later, and its status is still listed as "Experimental" in the 2.4 docs. The original change log entry describes it implementing ACMEv1 with a public ACME certificate authority; the current documentation covers the http-01, tls-alpn-01 and dns-01 challenge types. For tls-alpn-01, the server must listen on port 443 and add acme-tls/1 to the Protocols directive.

mod_md removes a separate renewal job, but renewal then depends on httpd reaching the certificate authority. Monitor certificate expiry independently either way.

How does the httpd security process work?

Reporting

The httpd security report page asks reporters to use the ASF Security Team's private list before any public disclosure. The ASF security page gives the general address, security@apache.org, describes it as a private list, and asks for one plain text, unencrypted email per vulnerability. Regular bug reports sent there are ignored; they go to the bug tracker.

The ASF Security Team coordinates the handling of all vulnerabilities. The ASF page states that it is a CVE Numbering Authority covering all Apache projects and is the only group able to allocate CVE IDs for ASF project issues. Advisories are published per project.

Fixing and releasing

The ASF page summarises the flow at concept level:

1. A reporter tells the project privately.
2. The project's security team works privately with the reporter to resolve the vulnerability.
3. The project creates a new release of the affected package to deliver the fix.
4. The project publicly announces the vulnerability and describes how to apply the fix.

For httpd, step 3 is a normal 2.4.x release, which goes through the release vote described earlier (at least three PMC +1 votes and more positive than negative votes). There is no separate security-only branch and no patch for 2.2 or older.

Reading the vulnerabilities page

The 2.4 vulnerabilities page lists every vulnerability fixed in a released 2.4 version. Each entry carries:

• the CVE ID, a short title and a description,
• an impact rating from the Apache security team, which the page notes may vary by platform,
• the date the report was received, the fixing source revision and the release that shipped it,
• the affected range, for example "Affects 2.4.0 through 2.4.68", with a question mark on versions not verified.

An entry shown as fixed in a "-dev" release means the fix is in the development tree but not yet in a downloadable release.

The top of the page is also a quick measure of activity. As of 25 October 2026 it lists 43 releases with security fixes. The most recent are 2.4.65 (July 2025, 1 CVE), 2.4.66 (December 2025, 5 CVEs), 2.4.67 (May 2026, 11 CVEs), 2.4.68 (June 2026, 13 CVEs) and 2.4.69 (October 2026, 20 CVEs, of which 5 are rated moderate and 15 low). Twenty fixes in one release is high for httpd: for comparison, most 2.4 security releases before 2026 listed between one and eight. Because 2.4 is the only branch, the practical answer to all of them is the same: move to 2.4.69 or apply your distribution's backport.

How do distributions ship httpd, and why is the banner a poor guide?

Backports keep the old version number

Most production httpd servers do not run a build from httpd.apache.org. They run a package from a Linux distribution, a container base image or an appliance vendor. Stable distributions generally do not move to a new upstream version during a release's life. The Debian security FAQ explains why: changing a package's interface, even slightly, can break the systems that depend on it, so the relevant security changes are backported into the version already shipped. Only when a backport is impractical, for example when a large amount of code would need to be rewritten, does the distribution move to a new upstream version, and then in coordination with its security team.

The FAQ has a question that captures the problem directly: the version number of a package suggests it is still vulnerable. The answer is that the version number reflects the upstream base, while the distribution's own revision suffix and changelog show which fixes have been applied.

What this means for the Server header

By default the ServerTokens directive is set to Full, which sends a header such as Server: Apache/2.4.2 (Unix) PHP/4.2.2 MyMod/1.2 (the example in the core documentation). Three problems follow:

1. On a distribution build, the version is the upstream base, not the patch level. A package based on an older 2.4 release can contain fixes from 2.4.69. A scanner that compares the banner with the upstream vulnerabilities page will report findings that are already fixed.
2. The banner can be changed or hidden. ServerTokens Prod reduces it to Server: Apache. A reverse proxy or load balancer in front can replace it entirely. Absence of a version tells you nothing.
3. The banner says nothing about modules or OpenSSL. The TLS library, mod_http2 and mod_md are where many fixes land, and none of them appear reliably in the header.

The reliable sources are on the host or in the image: the package manager's installed version and changelog, the distribution's security tracker, and httpd -V for build details. For a container image, the image's package database tells you the same thing.

Appliances and bundled builds

Appliances and commercial products that embed httpd are patched by their vendor on the vendor's schedule. Apply the vendor's updates, restrict network access to management interfaces, and record the product and its embedded components in your inventory so the next advisory can be matched against it.

Step by step: check what you run and plan the upgrade

These steps are read-only until step 5. Run them on a staging copy first if you can. Binary names differ by platform: upstream builds and Red Hat family systems use httpd and apachectl, while Debian family systems use apache2 and apache2ctl, and set environment variables through /etc/apache2/envvars.

1. Find the version and build details

# Version only
httpd -v            # Debian/Ubuntu: apache2 -v

# Build details: MPM, APR version, compile-time options and paths
httpd -V            # Debian/Ubuntu: apache2ctl -V

httpd -V prints the server version, build date, the MPM in use and whether it is threaded, the APR and APR-util versions, and the compile settings including the configuration file path.

2. List the loaded modules

# Static and shared modules currently loaded
httpd -M            # or: apachectl -M ; Debian/Ubuntu: apache2ctl -M

# Which OpenSSL the TLS module links against (Linux)
ldd "$(httpd -V | awk -F'"' '/HTTPD_ROOT/{print $2}')/modules/mod_ssl.so" 2>/dev/null | grep -i ssl

Module paths vary by distribution (for example /usr/lib64/httpd/modules/ or /usr/lib/apache2/modules/), so adjust the path if the second command prints nothing. Note in particular mod_ssl, mod_http2, mod_proxy and its sub-modules, mod_md, mod_dav, mod_status, mod_info, mod_cgi or mod_cgid, and any third party module.

3. Find out where the binary came from

# Red Hat family
rpm -qf "$(command -v httpd)"
rpm -q --changelog httpd | head -50

# Debian family
dpkg -S "$(command -v apache2)"
apt changelog apache2 | head -50

If a package owns the binary, its changelog and the distribution's tracker are the authority on fixes; if not, the build is local and you compare with upstream directly.

4. Compare with the vulnerabilities page

For an upstream build, open the 2.4 vulnerabilities page and read every entry whose affected range includes your version. For each one, note which module it concerns and check it against your module list from step 2. A finding in a module you do not load is still worth fixing by upgrade, but it changes the urgency. For a distribution package, look up the same CVE IDs in the distribution's tracker to see which package revision fixed them.

5. Disable modules you do not use

# Debian/Ubuntu
sudo a2dismod status info autoindex   # example only: pick from your own list

# Red Hat family and upstream builds: comment out the LoadModule line, for example
#   LoadModule status_module modules/mod_status.so
# in /etc/httpd/conf.modules.d/*.conf or httpd.conf

Every module you remove is code no request can reach. Common candidates on a static or proxy-only server are mod_status, mod_info, mod_autoindex, mod_userdir, mod_cgi or mod_cgid, mod_dav and mod_dav_fs, and mod_http2 if you do not serve HTTP/2.

6. Reduce what the server advertises

# In the main server configuration (not in .htaccess)
ServerTokens Prod
ServerSignature Off
TraceEnable Off

ServerTokens Prod reduces the Server header to Apache. ServerSignature Off (the default) removes the version footer from error pages and directory listings. This hides information; it does not fix anything. If mod_status must stay, restrict it to an administrative network:

<Location "/server-status">
    SetHandler server-status
    Require ip 10.0.0.0/8
</Location>

The mod_status documentation warns that if the module is loaded, its handler is available in every configuration file, including .htaccess files, which may have security ramifications. The project's security tips recommend AllowOverride None for the root directory so .htaccess files are ignored except where you enable them; that has been the default since 2.3.9, so check that no later configuration turns it back on.

7. Test the configuration before any reload

apachectl configtest      # Debian/Ubuntu: apache2ctl configtest
# Expected output: Syntax OK

Run it after every change in steps 5 and 6.

8. Reload, then plan the upgrade

# Graceful restart: children finish current requests first
apachectl -k graceful     # or: systemctl reload httpd / systemctl reload apache2

# Then upgrade through your package manager, for example
sudo dnf upgrade httpd mod_ssl        # Red Hat family
sudo apt-get install --only-upgrade apache2   # Debian family

For an upstream source build, download the current release, verify its signature against the project's KEYS file as the download page requires, and read the CHANGES entries between your version and the target. Upgrading OpenSSL also needs a restart of httpd, because the running processes keep the old library loaded until they are replaced. For a container, rebuild the image on a refreshed base and redeploy; patching a running container is lost on the next deploy.

Common mistakes

Running 2.2 on an old appliance or a forgotten VM. 2.2 has had no fixes of any kind since 2.2.34 in July 2017. A server still reporting 2.2 is either an unpatched build or a distribution or vendor package with its own support policy. Find out which, and if neither applies, plan its replacement.

Leaving mod_status reachable from the internet. The server-status page shows the hosts and requests currently being processed, and since 2.3.6 loading mod_status turns ExtendedStatus on by default. Restrict it with Require ip to an administrative range, or unload it.

Letting .htaccess files sprawl. The .htaccess guide gives two reasons to prefer the main configuration file: performance, because when overrides are allowed httpd looks for .htaccess files in every directory, and security, because anyone who can write to a directory can change server behaviour there. Per directory files also make the effective configuration hard to review. Keep AllowOverride None (the default since 2.3.9) wherever you can, and move the rules into the main configuration.

Copying cipher lists from old guides. A cipher string written for 2.2 and OpenSSL 1.0 may re-enable old protocols or weak ciphers, and in 2.4.36 and later TLS 1.3 cipher suites are configured separately. Start from the current mod_ssl defaults and an up-to-date TLS guide.

Trusting banner versions in scans. A scan that reads Server: Apache/2.4.x and maps it to upstream CVEs is wrong in both directions: it flags backported fixes as missing and misses vulnerable builds that hide their version. Use authenticated checks of package versions.

Assuming the MPM. Tuning advice for prefork is wrong for event, and vice versa. Check httpd -V before you change MaxRequestWorkers or thread settings.

Treating mod_md as fire and forget. If httpd cannot reach the certificate authority, or a challenge fails, renewal fails. Monitor expiry outside the web server.

FAQ

When was the Apache HTTP Server first released?

The first official public release, Apache 0.6.2, came out in April 1995, based on NCSA httpd 1.3 plus collected patches. Apache 1.0 was released on 1 December 1995. The project's About page gives both dates.

What is the latest version of Apache httpd?

As of 25 October 2026 the latest release is 2.4.69, released on 1 October 2026.

Is Apache 2.2 still supported?

No. The project states that 2.2 is end of life, that its final release was 2.2.34 in July 2017 and that no further patches, bug fixes or security updates will be provided. Distribution or vendor packages follow their own policies.

Which MPM should I use with PHP?

If PHP runs inside httpd as a module that is not thread safe, you need prefork. If PHP runs as a separate FastCGI process manager connected through mod_proxy_fcgi, you can use event, which is the default on modern systems and handles keep alive and HTTP/2 traffic with less memory.

When did Apache add HTTP/2 support?

mod_http2 was added in 2.4.17, released in October 2015.

Does Apache httpd support TLS 1.3?

Yes, with OpenSSL 1.1.1 or later. The change was recorded in the 2.4.36 change set and first shipped in 2.4.37 in October 2018, and the project home page says 2.4.43 or newer is required to operate a TLS 1.3 server with OpenSSL 1.1.1.

How do I report a security vulnerability in Apache httpd?

Send it privately to the ASF security team at security@apache.org, one plain text email per issue, before any public disclosure. The team coordinates with the httpd project and allocates the CVE ID.

Why does my scanner say my Apache is vulnerable when it is patched?

Most likely because your distribution backported the fix into an older version number, and the scanner only read the Server header. Check the package changelog or the distribution's security tracker for the CVE.

Where Safeguard fits

The fit here is partial. httpd usually reaches production as a distribution package, a container base image or part of an appliance, not as a library inside your code. Safeguard does not patch the httpd binary on a host you manage, does not replace your distribution's backports, and does not update an appliance's embedded web server; those fixes still come from the Apache project, your distribution or the vendor.

Where Safeguard helps is the inventory and the gate around the parts you build. Scanning a container image with safeguard scan --image <name> builds an inventory of the packages in it, so you can find every image that still carries an old httpd, mod_ssl or OpenSSL package, and the platform shows which projects contain a given component and version. Policies and gates in CI can stop images with known vulnerable versions from shipping. Where httpd sits in front of application code you build, the same scans cover that code's open source dependencies, and reachability analysis helps rank which findings your application actually calls; how much that narrows the list depends on the codebase and should be measured during evaluation. For quick lookups, Gold Open Source at gold.safeguard.sh gives free CVE intelligence with affected and fixed versions for open source components.

An httpd server rarely runs alone: the image it ships in, the TLS library it links and the application behind it all pull in open source packages that need the same version tracking. The section below applies to those dependencies and images you build, while fixes for httpd itself still come from the Apache project or your distribution.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It shows the assistant reading a finding and its advisory in a repository, asking before any command that changes something, editing a dependency version and running the install and tests. The same flow applies when the fix for an httpd related finding is a change you own, such as moving a Dockerfile to a refreshed base image or bumping a pinned httpd or OpenSSL package, and you want a reviewed, tested change rather than a ticket.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That is a natural place to scan the images that carry httpd and its modules in your build environment, before they reach a registry.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. With that connection, a question such as "which of our projects contain this component and version" can be answered from your own Safeguard data when a new httpd release lands.

Click through it at your own pace, or open it full screen.

To try it on your own images and repositories, download Safeguard or read the CLI documentation.

Quick check

Sources

• About the Apache HTTP Server Project
• Apache HTTP Server Project home page (2.4.69 release, 2.2 end of life)
• Apache HTTP Server 2.4 vulnerabilities
• Apache HTTP Server 2.2 vulnerabilities
• Apache HTTP Server 2.0 vulnerabilities
• Apache HTTP Server 1.3 vulnerabilities
• Reporting Security Problems with Apache
• ASF Security Team
• The Apache Software Foundation: overview
• httpd release guidelines
• CHANGES for Apache httpd 2.4
• Apache httpd release archive
• Downloading the Apache HTTP Server
• Multi-Processing Modules (MPMs)
• Apache MPM prefork
• Apache MPM worker
• Apache MPM event
• mod_http2
• mod_md
• mod_ssl
• Apache core features (ServerTokens, ServerSignature)
• mod_status
• Overview of new features in Apache HTTP Server 2.4
• Overview of new features in Apache HTTP Server 2.2
• Overview of new features in Apache HTTP Server 2.0
• Upgrading to 2.4 from 2.2
• httpd program reference
• apachectl program reference
• Security tips
• Apache .htaccess files
• Debian security FAQ (backported fixes and version numbers)

Last reviewed: 25 October 2026. httpd 2.4 releases irregularly; check the httpd.apache.org home page and the 2.4 vulnerabilities page for the latest version.