By Greg Nowak. Updated September 22, 2026.
Apache HTTP Server 2.4.68 was released on June 8, 2026 and remains the latest general availability release. Apache recommends it over previous versions. For teams running Apache as a reverse proxy, the release also provides a useful reason to examine the configuration that has accumulated around the server.
The fixes cover several parts of a typical production edge: proxy response rewriting, cookie rewriting, HTTP/2, TLS certificate checks, WebDAV, LDAP and privileges granted to local .htaccess authors. Some proxy flaws involve an untrusted or malicious backend. That matters because internal applications are often treated as implicitly safe even when they are maintained by another team, supplied by a vendor or running an older software stack.
Why the configuration deserves attention
Installing 2.4.68 closes the vulnerabilities fixed in that release. It does not tell you whether every loaded module is needed, whether requests reach the intended backend or whether inherited access rules still express the current policy.
Older Apache estates commonly contain several generations of configuration: broad proxy routes followed by exceptions, rewrite rules added during migrations, cookie mappings for retired domains and compatibility directives retained from Apache 2.2. Each line may have made sense when it was introduced. Their combined behaviour is harder to reason about, especially when directives live across the main configuration, virtual hosts and included files.
Treat the upgrade as a short, evidence-led review. The objective is a current release plus a configuration that the team can explain, test and support.
| Audit question | Evidence to collect | Decision |
|---|---|---|
| Which features are active? | Version, loaded modules, MPM and virtual-host map | Remove modules with no documented use |
| Where does each public path go? | ProxyPass, exclusions, rewrites and backend ownership | Keep one clear route for each path |
| Who controls access? | Require rules, legacy directives and .htaccess permissions | Move policy into reviewed server configuration where practical |
| How will failure appear? | Tests for unavailable backends, redirects, cookies and HTTP/2 | Define monitoring and rollback before release |
Start with an inventory you can reproduce
Run the following commands in the same environment and with the same configuration used by the service. Package layouts vary, so Debian-family systems may expose apache2ctl where another installation uses apachectl.
apachectl -v
apachectl -M
apachectl -S
apachectl -tThe output records the running version, static and shared modules, parsed virtual hosts and basic configuration validity. Save it with the change ticket or operational notes. A successful syntax test is only the entry point; it cannot confirm that a request matches the intended route or that authorization behaves correctly.
Next, locate the directives that shape proxying and access. Adjust the paths for your system:
grep -RniE 'ProxyPass|ProxyPassReverse|ProxyPassReverseCookie|ProxyRequests|AllowOverride|Order|Allow|Deny|Satisfy|Require' /etc/apache2 /etc/httpd 2>/dev/nullFor every public hostname and path, record the backend, protocol, owning team and reason for any response, cookie or HTML rewriting. Flag unused modules such as mod_proxy_ftp or mod_proxy_html. Disabling an unnecessary module reduces the configuration and the amount of software exposed to future defects.
Review rule order and trust boundaries
Apache evaluates server-level ProxyPass and ProxyPassMatch rules in configuration order, and the first match wins. More specific paths generally need to appear before broader paths. Proxy exclusions must also precede the general rule they exclude. Apache warns that mixing ProxyPass rules across contexts can produce unexpected results, so consolidate them when the current layout obscures precedence.
Review backend trust at the same time. Response rewriting means Apache parses or changes content supplied by another system. Cookie rewriting can alter domain and path attributes before they reach a browser. Confirm that these features remain necessary, restrict which systems can reach the backend port and assign an owner for the application behind every route.
Access control deserves the same treatment. Apache discourages mixing the deprecated Order, Allow and Deny directives with modern Require rules. Translate old blocks deliberately and test the result. Where applications still need .htaccess, use AllowOverrideList to permit named directives rather than granting a broad class of overrides.
Test behaviour before changing production
Build a staging checklist from real routes. Cover successful requests, authentication, redirects, WebSocket or other protocol upgrades, large uploads, backend timeouts and unavailable backends. Test both HTTP/1.1 and HTTP/2 where clients use them. Check that cookies retain the intended domain, path, security and SameSite behaviour after passing through Apache.
Prepare the rollback alongside the deployment: preserve the previous package version where your platform supports it, keep a reviewed configuration diff and identify the monitoring signals that would stop the rollout. After deployment, verify representative public paths and watch error rates, upstream latency, process restarts and file-descriptor pressure.
Make the audit useful to the business
A good outcome is easy to explain: supported software, fewer exposed modules, an explicit route map, tested access rules and named owners for each backend. Agency teams also gain a cleaner handover document and a safer basis for estimating future migrations.
If your Apache edge has passed through several teams or application generations, Greg can help scope the review, map the routes, test the upgrade and turn the findings into an ordered remediation plan. Get in touch to discuss an Apache and reverse-proxy audit.
Related on GrN.dk
- Apache 2.4.67: Why Legacy Reverse Proxies Belong Back on the Risk List
- Apache 2.4.68 Isn’t the Only Number That Proves You’re Patched
- WordPress Supports Old PHP; Your Production Server Shouldn’t
Need help with this kind of work?
Discuss an Apache and reverse-proxy audit Get in touch with Greg.
