Author Topic: HTTP/2 Bomb — Remote DoS Exploit Hits nginx, Apache, IIS, Envoy, and Cloudflare  (Read 534 times)

0 Members and 2 Guests are viewing this topic.

Offline
*****
https://cybersecuritynews.com/http-2-bomb-remote-dos-exploit/

If you are running Apache <2.4.67 or Nginx <1.29.7, Please update ASAP.

Offline
*****
Maybe that's what hit our datacenter last Sunday afternoon/evening. Knocked everything out for hours with a major DDoS.

Offline
**
F*ck CWP use all major services with outdated versions. It's incredible.

Offline
*
Hello admins, only if someone screams and threatens, one step forward and of course 2 back, it seems that cwp advances like this, 1 forward 2 back. Even now the cwp installation script has not been corrected, still with the outdated packages and services to install. So that after installation you have to update Apache, Roundcube, Nginx, MariaDB, PhP ... so on ... Who is the admin of this forum and if he is from the CWP team, can he tell here what is the status of the new version (which comes with a never-before-seen interface) and the changelog of the latest versions?

"If you are running Apache <2.4.67 or Nginx <1.29.7, Please update ASAP."
Starburst - and what are the correct steps to update Apache - without breaking anything in cwp?
Same for NGINX, same for Roundcube! MariaDB?

I've been watching the HestiaCP forum these days, incredible, a problem appeared, you automatically have a solution .... here even when I open a ticket, for paid servers with a license, you get a response like "I'm sick of you".

Too bad, if the team was more serious, cwp would be an incredible control panel!


Offline
*
Unfortunately, as many users can see, only Starburst and Overseer seem to be actively helping on the forum, and they do their best to support the community. I appreciate their efforts.

However, I am disappointed by the lack of communication from the CWP team. I currently maintain 20 active CWP PRO servers. Three of them are running AlmaLinux 8, while the rest are still on CentOS 7 because I do not yet consider the AlmaLinux 9 version ready for production use.

I would genuinely like to be proven wrong, but with solid technical arguments.

Starburst and Overseer, please do not take this personally. I have always tried to contribute constructively on this forum.

My concern is simple: the AlmaLinux 9 branch of CWP remained in BETA for more than a year. Now that it has been officially released and promoted as a supported platform, why does a fresh installation still deploy outdated packages and service versions? After such a long beta period, many of us expected a more modern, secure, and production-ready software stack by default.

I have deployed CWP solutions for multiple clients in addition to my own VPS infrastructure. The reality is that we cannot continue operating indefinitely with outdated components while new CVEs are published every few days and remain unresolved.

On AlmaLinux 8, I was forced to manually update Nginx, Apache, MariaDB, and Roundcube. This process generated several operational issues, which I eventually resolved using a combination of Starburst’s forum posts and solutions from the AlphaGNU forum. While acceptable on a single server, this approach does not scale when managing dozens of production VPS instances and client environments.

In CWP, I have repeatedly faced inconsistencies in managing core stack components such as Nginx, Apache, MariaDB, PHP (including multiple versions and updates), Roundcube, and Varnish. Support for newer versions appears inconsistent across panel releases, and in practice installation or upgrade processes frequently lead to dependency conflicts, broken configurations, or service instability.

This creates a serious challenge in maintaining stable production environments across multiple servers.

What many of us are asking for is not another temporary patch, but a clear direction and active communication from the CWP development team. At the moment, the official administrators and support channels appear largely silent, and this creates uncertainty for users who rely on CWP in production environments.

I believe many long-term CWP PRO customers would appreciate greater transparency on these points.

This message does not come from someone testing CWP in a lab environment. It comes from a paying customer who manages 20 active CWP PRO servers and has deployed CWP solutions for multiple clients over the years. The intention is not criticism for its own sake, but a request for clarity, consistency, and more reliable long-term platform maintenance.

Offline
**
Hello admins, only if someone screams and threatens, one step forward and of course 2 back, it seems that cwp advances like this, 1 forward 2 back. Even now the cwp installation script has not been corrected, still with the outdated packages and services to install. So that after installation you have to update Apache, Roundcube, Nginx, MariaDB, PhP ... so on ... Who is the admin of this forum and if he is from the CWP team, can he tell here what is the status of the new version (which comes with a never-before-seen interface) and the changelog of the latest versions?

"If you are running Apache <2.4.67 or Nginx <1.29.7, Please update ASAP."
Starburst - and what are the correct steps to update Apache - without breaking anything in cwp?
Same for NGINX, same for Roundcube! MariaDB?

I've been watching the HestiaCP forum these days, incredible, a problem appeared, you automatically have a solution .... here even when I open a ticket, for paid servers with a license, you get a response like "I'm sick of you".

Too bad, if the team was more serious, cwp would be an incredible control panel!


This is what prompted me to create this topic: https://forum.centos-webpanel.com/updates/security-what-should-we-update-after-a-fresh-cwp-install/

What exactly should we update on a fresh installation, or even on older installations that haven't been updated with the latest security fixes?

Offline
*****
Update: Apache, Nginx, MariaDB, Roundcube, Mod Security, OWASP ruleset, CSF (Aetherinox).

Offline
****
Guys, check if the protocol http/2 is enabled in Nginx and/or Apache before panic :)

Code: [Select]
grep ' h2 ' /usr/local/apache/conf* -R
grep 'http2' /etc/nginx/conf* -R

If you get nothing or commented lines then http/2 is disabled.

Seems Sandeep provided with the instructions how to update Nginx.

My version of CWP doesn't use mod_http2 for Apache by default. At least I don't see it in the folder used to store the apache modules:
/usr/local/apache/modules/

Anyway, if you need to update mod_http2 for Apache follow the instructions listed below to perform the update:


Code: [Select]
dnf install libnghttp2-devel.x86_64
cd /usr/local/src/
wget -O mod_http2.zip https://github.com/icing/mod_h2/archive/refs/heads/master.zip
unzip mod_http2.zip
cd mod_h2-master
autoreconf -i
automake
autoconf
./configure --with-apxs=/usr/local/apache/bin/apxs
make
make sure there are no messages containing "error". If all is ok:

Code: [Select]
#make backup of the original http2 libs to /root/
cp -p /usr/local/apache/modules/*http2.so /root/
cp -fp mod_http2/.libs/*.so /usr/local/apache/modules/
service httpd restart
« Last Edit: June 05, 2026, 10:19:10 PM by cyberspace »

Offline
**
Update: Apache, Nginx, MariaDB, Roundcube, Mod Security, OWASP ruleset, CSF (Aetherinox).
We need a topic qith the instructions for each service.

Offline
*****
Between https://starburst.help and https://www.alphagnu.com, all the instructions are there to update.

Offline
*****
So:
Code: [Select]
grep ' h2 ' /usr/local/apache/conf* -RShows if you are running HTTP/2 or not.

And
Code: [Select]
/usr/local/apache/bin/apachectl -vShows you the Apache version.

@overseer @cyberspace
Is there a command I'm missing to show the mod_http2 version?

Offline
*****

Offline
*****
Yea, it shows the Apache version.

But I was looking for a way to see the mod_http2 version.
Currently at 2.0.42

https://github.com/icing/mod_h2

Offline
*****
I wouldn't run the GitHub version in production; I prefer the version from the Apache Foundation for stable, production use:
Quote
It [GitHub version] servers as early access to features and fixes before being shipped in the next Apache release. Both modules can be considered production ready and stable as shipped by the Apache project.