It seems that after an apt update & apt upgrade, websites now display an error 421:
Misdirected Request
The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
If I do make a webrequest, I can see it hits the apache log for that domain, however in the apache errorlog for that domain I also see this:
AH02032: Hostname 10.0.0.120 (default host as no SNI was provided) and hostname xxxxx provided via HTTP have no compatible SSL setup
Because of this SNI message, I tried to edit the nginx configuration for that domain, adding a few lines:
The 421 error is now gone, but I am not getting the website of the host, but the default “success, Your new web server is ready to use” page and I can’t seem to find this request in apache logs.
You can execute these commands to do the change automatically:
for file in $(grep -l proxy_pass /usr/local/hestia/data/templates/web/nginx/*.stpl); do if ! grep -q proxy_ssl_server_name "$file"; then sed -i '/proxy_pass/ i\\t\tproxy_ssl_server_name on;\n\t\tproxy_ssl_name $host;' "$file"; fi; done
for i in $(v-list-users plain | cut -f1); do echo "Rebuilding web domains for user $i"; v-rebuild-web-domains $i yes; done
And for mail domains:
for file in $(grep -l proxy_pass /usr/local/hestia/data/templates/mail/nginx/*.stpl); do if ! grep -q proxy_ssl_server_name "$file"; then sed -i '/proxy_pass/ i\\t\tproxy_ssl_server_name on;\n\t\tproxy_ssl_name $host;' "$file"; fi; done
for i in $(v-list-users plain | cut -f1); do echo "Rebuilding mail domains for user $i"; v-rebuild-mail-domains $i yes >/dev/null; done
Edit2: If you want, you could use this script to fix the templates and rebuild the domains at once.
Fixed in Apache HTTP Server 2.4.64
moderate: Apache HTTP Server: HTTP response splitting (CVE-2024-42516)
HTTP response splitting in the core of Apache HTTP Server allows an attacker who can manipulate the Content-Type response headers of applications hosted or proxied by the server can split the HTTP response.
This vulnerability was described as CVE-2023-38709 but the patch included in Apache HTTP Server 2.4.59 did not address the issue.
Users are recommended to upgrade to version 2.4.64, which fixes this issue.
Reported to security team 2024-07-18
Update 2.4.64 released 2025-07-10
Affects 2.4.0 through 2.4.63
low: Apache HTTP Server: SSRF with mod_headers setting Content-Type header (CVE-2024-43204)
SSRF in Apache HTTP Server with mod_proxy loaded allows an attacker to send outbound proxy requests to a URL controlled by the attacker. Requires an unlikely configuration where mod_headers is configured to modify the Content-Type request or response header with a value provided in the HTTP request.
Users are recommended to upgrade to version 2.4.64 which fixes this issue.
Acknowledgements: finder: xiaojunjie@安恒信息杭州市滨江区技能大师工作室
Reported to security team 2024-08-07
2.4.x revision 2025-07-07
Update 2.4.64 released 2025-07-10
Affects 2.4.0 through 2.4.63
moderate: Apache HTTP Server: SSRF on Windows due to UNC paths (CVE-2024-43394)
Server-Side Request Forgery (SSRF) in Apache HTTP Server on Windows allows to potentially leak NTLM hashes to a malicious server via
mod_rewrite or apache expressions that pass unvalidated request input.
This issue affects Apache HTTP Server: from 2.4.0 through 2.4.63.
Note: The Apache HTTP Server Project will be setting a higher bar for accepting vulnerability reports regarding SSRF via UNC paths.
The server offers limited protection against administrators directing the server to open UNC paths.
Windows servers should limit the hosts they will connect over via SMB based on the nature of NTLM authentication.
Acknowledgements: finder: Kainan Zhang (@4xpl0r3r) from Fortinet
Reported to security team 2024-08-10
Update 2.4.64 released 2025-07-10
Affects 2.4.0 through 2.4.63
low: Apache HTTP Server: mod_ssl error log variable escaping (CVE-2024-47252)
Insufficient escaping of user-supplied data in mod_ssl in Apache HTTP Server 2.4.63 and earlier allows an untrusted SSL/TLS client to insert escape characters into log files in some configurations.
In a logging configuration where CustomLog is used with "%{varname}x" or "%{varname}c" to log variables provided by mod_ssl such as SSL_TLS_SNI, no escaping is performed by either mod_log_config or mod_ssl and unsanitized data provided by the client may appear in log files.
Acknowledgements: finder: John Runyon
Reported to security team 2024-09-18
Update 2.4.64 released 2025-07-10
Affects 2.4 through 2.4.63
moderate: Apache HTTP Server: mod_ssl access control bypass with session resumption (CVE-2025-23048)
In some mod_ssl configurations on Apache HTTP Server 2.4.35 through to 2.4.62, an access control bypass by trusted clients is possible using TLS 1.3 session resumption.
Configurations are affected when mod_ssl is configured for multiple virtual hosts, with each restricted to a different set of trusted client certificates (for example with a different SSLCACertificateFile/Path setting). In such a case, a client trusted to access one virtual host may be able to access another virtual host, if SSLStrictSNIVHostCheck is not enabled in either virtual host.
Acknowledgements: finder: Sven Hebrok, Felix Cramer, Tim Storm, Maximilian Radoy, and Juraj Somorovsky at Paderborn University
Reported to security team 2024-11-25
Update 2.4.64 released 2025-07-10
Affects 2.4.35 through 2.4.63
low: Apache HTTP Server: mod_proxy_http2 denial of service (CVE-2025-49630)
In certain proxy configurations, a denial of service attack against Apache HTTP Server versions 2.4.26 through to 2.4.63 can be triggered by untrusted clients causing an assertion in mod_proxy_http2.
Configurations affected are a reverse proxy is configured for an HTTP/2 backend, with ProxyPreserveHost set to "on".
Acknowledgements: finder: Anthony CORSIEZ
Report received 2025-06-04
Update 2.4.64 released 2025-07-10
Affects 2.4.26 through 2.4.63
moderate: Apache HTTP Server: mod_ssl TLS upgrade attack (CVE-2025-49812)
In some mod_ssl configurations on Apache HTTP Server versions through to 2.4.63, an HTTP desynchronisation attack allows a man-in-the-middle attacker to hijack an HTTP session via a TLS upgrade.
Only configurations using "SSLEngine optional" to enable TLS upgrades are affected. Users are recommended to upgrade to version 2.4.64, which removes support for TLS upgrade.
Acknowledgements:
finder: Robert Merget (Technology Innovation Institute)
finder: Nurullah Erinola (Ruhr University Bochum)
finder: Marcel Maehren (Ruhr University Bochum)
finder: Lukas Knittel (Ruhr University Bochum)
finder: Sven Hebrok (Paderborn University)
finder: Marcus Brinkmann (Ruhr University Bochum)
finder: Juraj Somorovsky (Paderborn University)
finder: Jörg Schwenk (Ruhr University Bochum)
Report received 2025-04-22
Update 2.4.64 released 2025-07-10
Affects through 2.4.63
moderate: Apache HTTP Server: HTTP/2 DoS by Memory Increase (CVE-2025-53020)
Late Release of Memory after Effective Lifetime vulnerability in Apache HTTP Server.
This issue affects Apache HTTP Server: from 2.4.17 up to 2.4.63.
Users are recommended to upgrade to version 2.4.64, which fixes the issue.
Acknowledgements: finder: Gal Bar Nahum
Reported to security team 2025-06-18
fix developed 2025-06-19
Update 2.4.64 released 2025-07-10
Affects 2.4.17 through 2.4.63
Sorry peoples, I am going to correct myself.
The solution stated above is not the right one, there’s is more to it.
More sites suffer from the same problem, p.e. phpmyadmin and all webmail sites.
Instead of changing the template(s) and rebuilding the websites as stated above, there is an other solution that
(a) is much more simpler
(b) also fixes phpmyadmin and the webmail sites
So, please, if you did adjust the template as stated above, revert those changes and if you have rebuild the webdomains please do that again after reverting the changes in the template(s).
This command will
(a) create a textfile /etc/nginx/conf.d/fixssl.conf with the 2 lines for the fix, immediate valid for all existing nginx webtemplates
(b) restart nginx
Use also this to modify mail templates and rebuild mail domains:
for file in $(grep -l proxy_pass /usr/local/hestia/data/templates/mail/nginx/*.stpl); do if ! grep -q proxy_ssl_server_name "$file"; then sed -i '/proxy_pass/ i\\t\tproxy_ssl_server_name on;\n\t\tproxy_ssl_name $host;' "$file"; fi; done
for i in $(v-list-users plain | cut -f1); do echo "Rebuilding mail domains for user $i"; v-rebuild-mail-domains $i yes >/dev/null; done
Kudos to @maurice first for creating topic, second for finding exactly what it was
@sahsanu always such a great guy… Thanks again for your valuable time and knowledged and sharing the script with community. Used this as solution. Now, let me try to read all this fully and try to understand what happend hehe.
This just fixed a Server I was having problems with after updating HestiaCP.
If this is a bug in the latest version just rolled, it needs to be fixed ASAP, else I think this is going to create havoc. Mods and Devs, pls fix this at the earliest.
