Apache 2.4.67 Put Legacy Reverse Proxies Back on the Risk List

By Greg Nowak. Last updated 2026-07-13.

Apache 2.4.67, released on 4 May 2026, was not an ordinary maintenance release. It fixed an important HTTP/2 double-free with possible remote code execution in 2.4.66, several AJP parsing flaws, a .htaccess privilege issue and weaknesses in how proxy modules handled hostile backend responses. That combination was a useful warning for businesses with an Apache server nobody thinks about until traffic stops.

It was not a version to settle on. As of 13 July 2026, Apache 2.4.68 is the latest upstream release and is recommended over previous 2.4.x versions. It fixes additional vulnerabilities affecting 2.4.67, including problems in mod_proxy_html, ProxyPassReverseCookie*, delegated .htaccess expressions and mod_http2. If 2.4.67 triggered your review, that was useful. The supported destination should now be 2.4.68, or a maintained distribution package that explicitly includes the same fixes.

The risk is the server’s role, not just its version

A legacy reverse proxy may terminate TLS, redirect old domains, enforce access rules, forward authentication headers and connect public requests to an ERP, CMS or Java application. Its configuration is therefore part security boundary, part routing table and part business history. A compromised backend may be able to exercise vulnerable proxy code, while an over-permissive .htaccess policy can give local content maintainers more power than intended.

Prioritise by exposure and function rather than counting Apache installations:

Signal	Recommended decision	Why it matters
2.4.67 or earlier handles public traffic	Patch through the supported package channel now, restart and verify the running service.	2.4.68 fixes vulnerabilities still present in 2.4.67.
`Protocols h2` is enabled	Patch, then test concurrency and check thread, memory and file-descriptor headroom.	`mod_http2` has its own workers and was affected by further 2.4.68 security fixes.
AJP or content-rewriting proxy modules are loaded	Remove unused modules; restrict and document required backend connections.	Several issues involve malicious or compromised upstream services.
Teams can edit `.htaccess`	Identify every writer and narrow the permitted directives.	Delegated configuration is a security decision, not merely a convenience.
`ProxyRequests On` appears	Confirm that a controlled forward proxy is intentional and properly restricted.	A normal reverse proxy should not accidentally accept arbitrary proxy requests.

A practical triage matrix for deciding which Apache hosts need attention first.

Inventory the proxy before changing it

Start on the host, or on an accurate staging copy, with a small evidence pack:

apachectl -v
apachectl -M
apachectl -S
apachectl -t
grep -RniE 'Protocols|ProxyRequests|ProxyPass|AllowOverride|AllowOverrideList|ajp://' /etc/apache2 /etc/httpd 2>/dev/null

These commands show the executable version, loaded modules, virtual-host map, basic configuration validity and likely HTTP/2, proxy and delegation rules. The grep output is only triage: it can include comments, inactive files or miss configuration stored elsewhere.

Do not use the version banner alone as proof of patch status. Linux vendors may backport fixes without changing the upstream version in the way you expect. Compare the complete installed package revision with the vendor’s security channel, and confirm that Apache was restarted after the update. Record which public hostname reaches which backend, who owns it, how health is checked and what the rollback path is.

Treat the patch as a controlled business change

The package installation is usually the shortest part of the job. The useful work is proving that the business paths still behave correctly:

Capture the installed package versions, configuration backup and rollback procedure before the maintenance window.
Test canonical redirects, authentication, uploads, API calls, WebSockets where used, admin routes and upstream TLS—not just the home page.
Exercise both HTTP/1.1 and HTTP/2. Shared-certificate virtual hosts using HTTP/2 need consistent TLS settings, or clients may receive 421 Misdirected Request.
Check behavior when a backend is slow or unavailable. Confirm that timeouts and error pages do not expose internal hosts or create retry storms.
After deployment, verify the running process, inspect error and access logs, watch resource use and keep the rollback decision time-boxed.

Use the window to reduce the next patch’s cost

Do not disable HTTP/2 or replace AJP automatically because a vulnerability mentioned the module. First establish whether the feature is required and whether the host has capacity and appropriate backend controls. If AJP exists only because an old application once required it, give its retirement plan an owner and date.

Where administrators control the main Apache configuration, Apache recommends preferring it over .htaccess. If delegation is genuinely needed, AllowOverrideList can permit named directives instead of broad categories. Keep major cleanup separate from the urgent security patch when combining them would make testing or rollback ambiguous.

What a useful maintenance review should leave behind

Evidence of the patched package and restarted process
A concise module, virtual-host and backend inventory
Recorded pre-change and post-change test results
A rollback runbook and prioritised cleanup backlog with owners

That turns an emergency update into a repeatable operating task. If an inherited Apache proxy sits between your customers and systems your team cannot confidently map, Greg can help scope the review, coordinate the technical work and leave the next team with a usable runbook.

Related on GrN.dk

Need help with this kind of work?

Discuss your Apache maintenance plan Get in touch with Greg.

Sources

Last modified

2026-07-31