By Greg Nowak. Updated 1 October 2026.
An old Apache reverse proxy can be easy to overlook. It may quietly serve a former domain, pass customer traffic to a newer application, or connect an agency-managed site to an internal system. When it needs a security update, the difficult question is often not how to install the package. It is who knows what the proxy does and how to prove it still works afterward.
Apache 2.4.67 made that question urgent. It fixed an important HTTP/2 double-free affecting 2.4.66, along with flaws involving AJP, delegated .htaccess configuration and responses from untrusted backends. But 2.4.67 is no longer the upstream destination: as of 1 October 2026, Apache lists 2.4.68 as its latest release. That release fixes additional issues affecting 2.4.67, including flaws in mod_proxy_html, cookie rewriting and mod_http2.
Start with the routes that matter to the business
A version number tells you where to investigate; it does not tell you what will break. A proxy may terminate TLS, enforce access rules, rewrite redirects or route requests to several backends. Before scheduling a change, identify the public hostnames it serves and the journeys those routes support: purchases, sign-ins, uploads, API calls and administrative access.
| What you find | First response | What to confirm |
|---|---|---|
| A public proxy with no evidence of current security fixes | Verify urgently | Check the installed package revision against the vendor advisory and schedule the supported update. |
| HTTP/2 enabled on an affected, unpatched build | Prioritise patching | Test representative HTTP/2 traffic and watch memory, threads and file descriptors. |
| AJP, FTP, HTML rewriting or cookie rewriting in use | Review the actual route | Confirm the module is needed, who controls the backend and whether connectivity is restricted. |
Other teams can edit .htaccess |
Review delegation | Identify writers and the directives they genuinely need. |
ProxyRequests On |
Inspect immediately | Confirm a restricted forward proxy is intentional; reverse proxying does not require this setting. |
| No route owner or rollback instructions | Assign ownership | Record the backend, application contact and a way to restore service. |
Collect evidence before editing the configuration
Run these read-only checks on the host, adapting paths and the apachectl name for your distribution:
apachectl -v
apachectl -V
apachectl -M
apachectl -S
apachectl -t
grep -RniE 'Protocols|ProxyRequests|ProxyPass|ProxyPassReverse|RewriteRule.*\[P|AllowOverride|AllowOverrideList|ajp://' /etc/apache2 /etc/httpd 2>/dev/nullThe output shows the installed executable version, build settings, loaded modules, virtual hosts and syntax status. The search highlights likely proxy and delegation rules. It is a lead, not a complete map: files may be included from elsewhere, and matches may be comments or inactive configuration. Check the effective virtual hosts, then trace each important route to its backend and owner.
Do not treat apachectl -v alone as proof that a server is vulnerable or fixed. Linux vendors can backport security patches while keeping an older upstream version string. Record the full installed package revision and compare it with your distribution’s security notice. For a source-built installation, use the current upstream release and its security advisories instead.
Upgrade as a controlled service change
Keep the first change small enough to test and reverse. Save the active configuration and package details, choose a maintenance window, and agree who will decide whether to roll back. Apply the supported security update, run apachectl -t, restart the service and confirm the updated package is the one now running. A successful syntax check only proves that Apache can parse the configuration.
Test the routes people actually use. Check redirects and canonical hostnames; sign-in and sign-out; uploads; API responses; admin access; WebSockets where present; and upstream TLS. Exercise HTTP/1.1 and HTTP/2 if both are offered. Include a controlled test of a slow or unavailable backend so you know what customers see when the application fails.
After deployment, review access and error logs for unexpected redirects, authentication failures, and 502, 503 or 504 responses. Watch resource use under representative traffic, especially if HTTP/2 is enabled. Record what passed, what failed and the time by which the team will decide whether to keep the change or roll back.
Make the next update easier
Once the security update is stable, clean up what the audit exposed. Remove unused proxy modules after confirming no route depends on them. If AJP is still required, document the application and restrict who can reach its backend. Where administrators control the main configuration, move rules out of broadly writable .htaccess files; if delegation is necessary, AllowOverrideList can permit named directives instead of broad override categories.
Leave behind a one-page route map: public hostname, backend, protocol, business owner, technical contact, health check and expected failure behaviour. Add the package evidence, test results and rollback steps. That is enough to give the next person a reliable starting point without turning an urgent patch into an uncontrolled redesign.
If an inherited proxy sits between your customers and systems nobody can confidently map, Greg can help scope the review, coordinate the upgrade and leave your team with a usable runbook.
Related on GrN.dk
- Apache 2.4.68: Patch First, Then Audit Your Proxy Rules
- Nginx 1.30 Changed Upstream Connections: What to Test Before You Upgrade
- A Voice Agent Is Only Ready When the Human Handoff Works
Need help with this kind of work?
Discuss your Apache proxy review with Greg Get in touch with Greg.
