A workaround can be to switch to plain http proxying or set disablereuse on the proxy worker or to set smax=0 with a ttl that is smaller than the backend destination's typical keepalive timeout so httpd will initiate connection closes before the backend (that may avoid most issue occurrences but there may still be some retry occurrences reaching this issue if a connection is closed out by the backend for some other reason prior to the ttl/keepalive timeout): ProxyPass /foobar h2c: //127.0.0.1:81/ smax=0 ttl=1

1. Set up a simple h2 proxy pass with a destination using a short KeepAliveTimeout. This can be self referential in a single httpd config: Protocols h2 h2c http/1.1 KeepAlive On KeepAliveTimeout 2 ProxyPass /foobar h2c: //127.0.0.1:81/ Listen 81 <VirtualHost *:81> </VirtualHost> 2. This will reproduce most consistently if you also use an mpm config with a single process: LoadModule mpm_worker_module modules/mod_mpm_worker.so <IfModule mpm_worker_module> ThreadLimit 30 ServerLimit 1 StartServers 1 MinSpareThreads 5 MaxSpareThreads 30 ThreadsPerChild 30 MaxRequestWorkers 30 MaxConnectionsPerChild 0 </IfModule> 3. Send a request that will be proxied, wait for the backend destination keepalive timeout to pass then send another request. A simple one liner testing the above config: $ curl localhost/foobar; sleep 3; curl localhost/foobar 4. Both should return the default welcome page but the second will return a 503 due to the following error added by the CVE fix: [Wed Sep 11 13:14:30.931281 2024] [proxy:error] [pid 33692:tid 33741] [client 127.0.0.1:36400] AH00898: URI has no hostname: / returned by /foobar