Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« on: June 16, 2026, 10:23:24 AM »Not all users are sysadmin, this type of panel should handle the basic stuff, keep everyting updated it one of the basic features of every panel
If you're not a Sys Admin, I would recommend hiring one to take care of the technical backend.
Or maybe stick with a Managed VPS or Shared Reseller web hosting account, where the backend is handled for you.
No panel keeps everything updated, except maybe cPanel, and from the CVE's I've seen lately, they may not even keep everything updated.
But that's also what's good about CWP, it's let you have some customization.
CWP should handle the basics. The default installation is several versions behind the current ones.
While we can do manual updates, if CWP later updates its default version, it can break things because we are no longer running a default CWP installation.
2
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« on: June 15, 2026, 02:32:20 PM »This issue has been resolved on all CWP servers since last week, thank you for reporting it as well.
All issues? Apache, Ngnix, Roundcube?
CWP can be slow in new features but not slow on security fixes
3
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« on: June 15, 2026, 06:59:13 AM »
Not all users are sysadmin, this type of panel should handle the basic stuff, keep everyting updated it one of the basic features of every panel
4
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« on: June 14, 2026, 11:21:58 AM »
CWP team must release a urgent update that fix all the current services with issues, RoundCube, Nginx, Apache, etc.
This is urgent!
We are paying for something that its full of security issues
This is urgent!
We are paying for something that its full of security issues
6
Apache / Re: HTTP/2 Bomb — Remote DoS Exploit Hits nginx, Apache, IIS, Envoy, and Cloudflare
« on: June 07, 2026, 07:27:16 AM »Update: Apache, Nginx, MariaDB, Roundcube, Mod Security, OWASP ruleset, CSF (Aetherinox).We need a topic qith the instructions for each service.
7
Apache / Re: HTTP/2 Bomb — Remote DoS Exploit Hits nginx, Apache, IIS, Envoy, and Cloudflare
« on: June 05, 2026, 08:20:19 AM »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?
8
Apache / Re: HTTP/2 Bomb — Remote DoS Exploit Hits nginx, Apache, IIS, Envoy, and Cloudflare
« on: June 04, 2026, 08:19:37 AM »
F*ck CWP use all major services with outdated versions. It's incredible.
9
CentOS-WebPanel Bugs / Crontab module: JS error when command contains > (client area only, admin area w
« on: May 28, 2026, 08:08:06 AM »
When creating a cron job that includes a > redirection (for example > /dev/null 2>&1), the crontab module throws a JavaScript error and the table fails to render.
Key detail: this only happens in the client area (user panel). When the exact same cron is created directly from the admin area, it works perfectly. The cron syntax is identical in both cases.
The console shows:
The redirection (> /dev/null 2>&1) is the standard way to suppress output and avoid cron emails, and the commands work fine via crontab -e over SSH. So this looks like a parsing issue in the client area frontend (cronTable) when handling commands containing >, rather than a problem with the cron itself. It also used to work correctly in older versions, so something seems to have regressed.
Questions:
Has anyone else hit this in the client area and found a workaround?
Could the CWP team look into why cronTable in the client area fails on commands containing > / 2>&1, while the admin area handles them fine?
Key detail: this only happens in the client area (user panel). When the exact same cron is created directly from the admin area, it works perfectly. The cron syntax is identical in both cases.
The console shows:
Code: [Select]
Uncaught TypeError: Cannot read properties of undefined (reading 'length')
at cronTable (?module=crontab:3340:16)
at Object.complete (?module=crontab:3022:11)
...
at createCron (?module=crontab:3016)The redirection (> /dev/null 2>&1) is the standard way to suppress output and avoid cron emails, and the commands work fine via crontab -e over SSH. So this looks like a parsing issue in the client area frontend (cronTable) when handling commands containing >, rather than a problem with the cron itself. It also used to work correctly in older versions, so something seems to have regressed.
Questions:
Has anyone else hit this in the client area and found a workaround?
Could the CWP team look into why cronTable in the client area fails on commands containing > / 2>&1, while the admin area handles them fine?
10
SSL / Re: Recommended acme.sh cron for CWP AutoSSL renewals?
« on: May 28, 2026, 07:50:22 AM »
In some of my servers I have exactly the same but in others I have only "bash /root/.acme.sh/acme.sh --cron --home /root/.acme.sh" this is automatically managed by cwp and I want to know which one is correct
11
SSL / Recommended acme.sh cron for CWP AutoSSL renewals?
« on: May 26, 2026, 08:49:55 AM »
I noticed that on some CWP servers the acme.sh cron is configured like this:
bash /root/.acme.sh/acme.sh --cron --home /root/.acme.sh
But on other CWP servers it is configured like this:
bash /root/.acme.sh/acme.sh --cron --home /root/.acme.sh/cwp_certs
Since CWP seems to store AutoSSL certificates under:
bash /root/.acme.sh/cwp_certs/
I would like to confirm which cron is currently the correct/recommended one for CWP AutoSSL renewals.
Should we use:
bash /root/.acme.sh/acme.sh --cron --home /root/.acme.sh/cwp_certs
or should CWP handle this differently?
I recently had a case where the cron using /root/.acme.sh was running daily, but it did not seem to process the certificates inside cwp_certs, so some SSL certificates were not renewed automatically.
Can someone from the CWP team or the community clarify the recommended setup?
bash /root/.acme.sh/acme.sh --cron --home /root/.acme.sh
But on other CWP servers it is configured like this:
bash /root/.acme.sh/acme.sh --cron --home /root/.acme.sh/cwp_certs
Since CWP seems to store AutoSSL certificates under:
bash /root/.acme.sh/cwp_certs/
I would like to confirm which cron is currently the correct/recommended one for CWP AutoSSL renewals.
Should we use:
bash /root/.acme.sh/acme.sh --cron --home /root/.acme.sh/cwp_certs
or should CWP handle this differently?
I recently had a case where the cron using /root/.acme.sh was running daily, but it did not seem to process the certificates inside cwp_certs, so some SSL certificates were not renewed automatically.
Can someone from the CWP team or the community clarify the recommended setup?
12
Nginx / Re: Nginx uploads fail after every package update on CWP / AlmaLinux 8
« on: May 22, 2026, 05:34:15 PM »try to add the custom "chown", "chmod" commands to:
/etc/cron.daily/cwp
right after:Code: [Select]/usr/local/cwp/php71/bin/php -d max_execution_time=1000000 -q /usr/local/cwpsrv/htdocs/resources/admin/include/cron.phpto fix the permissions after the daily cwp update.
I prefer my approach but yours also works.
But this issue happens to someone else? I have it on all my servers.
13
Nginx / Re: Nginx uploads fail after every package update on CWP / AlmaLinux 8
« on: May 19, 2026, 02:30:18 PM »
Thanks for chiming in. Good to know I'm not the only one running the AppStream nginx under CWP.
Quick note on your point: even when you "accommodate permissions" on /var/lib/nginx, the fix doesn't stick across package updates. The RPM ships /var/lib/nginx and /var/lib/nginx/tmp with explicit %attr(0770, nginx, root) in the spec, and dnf reapplies those attributes on every upgrade automatically, without any postinstall scriptlet. That's why a one-shot chown isn't enough if you keep user=nobody in nginx.conf. The temp paths really do need to move out of /var/lib/nginx (or you switch user to nginx, which has its own implications for CWP integrations).
Still hoping someone from the CWP team can weigh in on whether the shipped default should set explicit *_temp_path or move to user=nginx.
Quick note on your point: even when you "accommodate permissions" on /var/lib/nginx, the fix doesn't stick across package updates. The RPM ships /var/lib/nginx and /var/lib/nginx/tmp with explicit %attr(0770, nginx, root) in the spec, and dnf reapplies those attributes on every upgrade automatically, without any postinstall scriptlet. That's why a one-shot chown isn't enough if you keep user=nobody in nginx.conf. The temp paths really do need to move out of /var/lib/nginx (or you switch user to nginx, which has its own implications for CWP integrations).
Still hoping someone from the CWP team can weigh in on whether the shipped default should set explicit *_temp_path or move to user=nginx.
14
Nginx / Nginx uploads fail after every package update on CWP / AlmaLinux 8
« on: May 19, 2026, 10:41:38 AM »
Setup: CWP on AlmaLinux 8.10, nginx 1.24.0 from appstream, default config with "user nobody;".
After every nginx package update, uploads larger than client_body_buffer_size start failing. The RPM resets /var/lib/nginx and /var/lib/nginx/tmp to "nginx:root 0770", so the nobody worker can't traverse into them to write client body temp files. SELinux is off, this is just DAC.
Confirm with:
rpm -q --queryformat "[%{FILEMODES:perms} %{FILEUSERNAME}:%{FILEGROUPNAME} %{FILENAMES}\n]" nginx | grep /var/lib/nginx
The usual chown fix works until the next update.
Permanent fix that survives updates: move the temp paths out of /var/lib/nginx into /var/cache/nginx (not owned by any RPM) and add them to nginx.conf:
client_body_temp_path /var/cache/nginx/client_body 1 2;
fastcgi_temp_path /var/cache/nginx/fastcgi 1 2;
uwsgi_temp_path /var/cache/nginx/uwsgi 1 2;
scgi_temp_path /var/cache/nginx/scgi 1 2;
Anyone else hitting this? Would it make sense for CWP to ship the default nginx.conf with these paths set, or switch the default user to "nginx" to match the RPM?
After every nginx package update, uploads larger than client_body_buffer_size start failing. The RPM resets /var/lib/nginx and /var/lib/nginx/tmp to "nginx:root 0770", so the nobody worker can't traverse into them to write client body temp files. SELinux is off, this is just DAC.
Confirm with:
rpm -q --queryformat "[%{FILEMODES:perms} %{FILEUSERNAME}:%{FILEGROUPNAME} %{FILENAMES}\n]" nginx | grep /var/lib/nginx
The usual chown fix works until the next update.
Permanent fix that survives updates: move the temp paths out of /var/lib/nginx into /var/cache/nginx (not owned by any RPM) and add them to nginx.conf:
client_body_temp_path /var/cache/nginx/client_body 1 2;
fastcgi_temp_path /var/cache/nginx/fastcgi 1 2;
uwsgi_temp_path /var/cache/nginx/uwsgi 1 2;
scgi_temp_path /var/cache/nginx/scgi 1 2;
Anyone else hitting this? Would it make sense for CWP to ship the default nginx.conf with these paths set, or switch the default user to "nginx" to match the RPM?
15
Updates / [SECURITY] What should we update after a fresh CWP install?
« on: May 14, 2026, 10:55:23 AM »
After installing a new AlmaLinux server with CWP, what components should we really update manually to keep the server secure?
I know Apache currently has a serious security issue, and the default Nginx version installed with CWP also seems quite old. But it is not fully clear which components are handled by the OS, which ones are handled by CWP, and which ones we need to update manually.
For example, should we update Apache, Nginx, PHP versions, Roundcube, MariaDB, OpenSSL, OpenSSH, Postfix, Dovecot, CSF, ModSecurity, etc.?
Also, shouldn’t this be one of the main priorities of the CWP team? One of the reasons to use a control panel is to avoid having to manually inspect every component and guess what is outdated or vulnerable.
Can the community please share useful links, tutorials, or checklists explaining what really needs to be updated after installing CWP and the safest way to keep everything updated over time?
This would make life easier for everyone using CWP.
I know Apache currently has a serious security issue, and the default Nginx version installed with CWP also seems quite old. But it is not fully clear which components are handled by the OS, which ones are handled by CWP, and which ones we need to update manually.
For example, should we update Apache, Nginx, PHP versions, Roundcube, MariaDB, OpenSSL, OpenSSH, Postfix, Dovecot, CSF, ModSecurity, etc.?
Also, shouldn’t this be one of the main priorities of the CWP team? One of the reasons to use a control panel is to avoid having to manually inspect every component and guess what is outdated or vulnerable.
Can the community please share useful links, tutorials, or checklists explaining what really needs to be updated after installing CWP and the safest way to keep everything updated over time?
This would make life easier for everyone using CWP.
