21
Updates / Re: CWP7: 0.9.8.1230
« Last post by kandalf on June 10, 2026, 09:42:57 AM »What is the changelog?
22
Updates / CWP7: 0.9.8.1230
« Last post by cgauthey on June 09, 2026, 07:29:19 PM »CWP7: 0.9.8.1230
23
CSF Firewall / Re: CWP / Nginx Reverse Proxy: cwpsrv not logging authentication failures
« Last post by cyberspace on June 09, 2026, 06:59:09 PM »Quote
Is there a configuration in cwpsrv to enable "Real IP" support similar to how Apache/Nginx handle it?In my option you need to recompile nginx (cwpsrv) used by CWP to handle the requests coming to the panel to add the nginx module called "
ngx_http_realip_module":
https://nginx.org/en/docs/http/ngx_http_realip_module.html
Update the config file:
/usr/local/cwpsrv/conf.d/users.conf
to get the IP from the header X-Forwarded-For or X-Real-IP.
Here is the "configuration" used to compile cwpsrv:
Code: [Select]
--prefix=/usr/local/cwpsrv --sbin-path=/usr/local/cwpsrv/bin/cwpsrv --conf-path=/usr/local/cwpsrv/conf/cwpsrv.conf --pid-path=/usr/local/cwpsrv/var/run/nginx.pid --error-log-path=/usr/local/cwpsrv/logs/error_log --http-log-path=/usr/local/cwpsrv/logs/access_log --user=root --group=root --with-http_ssl_module --with-http_gzip_static_module --with-file-aio --with-http_secure_link_module --with-http_ssl_module --add-module=src/misc/ngx_http_auth_pam_module
Please note you make the changes on your own risk.
24
CSF Firewall / CWP / Nginx Reverse Proxy: cwpsrv not logging authentication failures
« Last post by idovecer on June 09, 2026, 10:50:10 AM »Hi everyone,
I’m running into a serious issue with brute-force protection on my AlmaLinux server after moving to an Nginx -> Apache -> PHP-FPM stack on CWP.
The problem is that all access requests to my panel subdomains (e.g., cpanel.some-domain.com) are logged in /usr/local/cwpsrv/logs/access_log as 127.0.0.1. Since Nginx acts as a reverse proxy, the backend (cwpsrv) sees the localhost IP instead of the client's real IP. Consequently, CSF/LFD cannot detect or block brute-force attacks, as it cannot see the actual source of the requests.
Key Technical Details:
Access Logs: Even with incorrect passwords, the requests return a 200 OK status, not a 401/403 error.
Example: 127.0.0.1 - - [09/Jun/2026:09:34:27 +0200] "POST /login/index.php?acc=validate HTTP/1.0" 200 70 ...
Missing Error Logs: I noticed that there are no entries in any error logs (including /var/log/secure or cwpsrv error logs) when a login fails. It seems cwpsrv handles authentication internally without triggering standard system-level auth logs.
Inconsistency: Regular websites hosted on the same server have their logs correctly populated with real client IPs (so Nginx is likely forwarding headers like X-Forwarded-For correctly).
My Questions:
How can I make cwpsrv log the real client IP (passed via X-Forwarded-For) so that LFD can parse it?
Since the failed login returns a 200 OK status, does LFD have a mechanism to parse the application-level response or "validate" string to trigger a block, even if the IP is hidden behind a proxy?
Is there a configuration in cwpsrv to enable "Real IP" support similar to how Apache/Nginx handle it?
Any insight on how to restore brute-force protection for the panel subdomains would be greatly appreciated!
I’m running into a serious issue with brute-force protection on my AlmaLinux server after moving to an Nginx -> Apache -> PHP-FPM stack on CWP.
The problem is that all access requests to my panel subdomains (e.g., cpanel.some-domain.com) are logged in /usr/local/cwpsrv/logs/access_log as 127.0.0.1. Since Nginx acts as a reverse proxy, the backend (cwpsrv) sees the localhost IP instead of the client's real IP. Consequently, CSF/LFD cannot detect or block brute-force attacks, as it cannot see the actual source of the requests.
Key Technical Details:
Access Logs: Even with incorrect passwords, the requests return a 200 OK status, not a 401/403 error.
Example: 127.0.0.1 - - [09/Jun/2026:09:34:27 +0200] "POST /login/index.php?acc=validate HTTP/1.0" 200 70 ...
Missing Error Logs: I noticed that there are no entries in any error logs (including /var/log/secure or cwpsrv error logs) when a login fails. It seems cwpsrv handles authentication internally without triggering standard system-level auth logs.
Inconsistency: Regular websites hosted on the same server have their logs correctly populated with real client IPs (so Nginx is likely forwarding headers like X-Forwarded-For correctly).
My Questions:
How can I make cwpsrv log the real client IP (passed via X-Forwarded-For) so that LFD can parse it?
Since the failed login returns a 200 OK status, does LFD have a mechanism to parse the application-level response or "validate" string to trigger a block, even if the IP is hidden behind a proxy?
Is there a configuration in cwpsrv to enable "Real IP" support similar to how Apache/Nginx handle it?
Any insight on how to restore brute-force protection for the panel subdomains would be greatly appreciated!
25
Nginx / CVE-2026-40519 - Nginx Proxy Manager Authenticated RCE via setupCertbotPlugins()
« Last post by Starburst on June 08, 2026, 11:26:02 PM »CVE ID: CVE-2026-40519
Published: June 8, 2026
Description: Nginx Proxy Manager versions 2.9.14 through 2.15.1, fixed in commit a5db5ed, contain an authenticated remote code execution vulnerability via OS command injection in the setupCertbotPlugins() function in backend/setup.js, allowing attackers with certificates:manage permission to execute arbitrary commands by storing a malicious payload in the dns_provider_credentials field. The user-controlled dns_provider_credentials value is interpolated directly into a shell command executed via child_process.exec() without sanitization or escaping, causing the injected command to execute upon backend restart.
Severity: 7.7 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
https://cvefeed.io/vuln/detail/CVE-2026-40519
Published: June 8, 2026
Description: Nginx Proxy Manager versions 2.9.14 through 2.15.1, fixed in commit a5db5ed, contain an authenticated remote code execution vulnerability via OS command injection in the setupCertbotPlugins() function in backend/setup.js, allowing attackers with certificates:manage permission to execute arbitrary commands by storing a malicious payload in the dns_provider_credentials field. The user-controlled dns_provider_credentials value is interpolated directly into a shell command executed via child_process.exec() without sanitization or escaping, causing the injected command to execute upon backend restart.
Severity: 7.7 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
https://cvefeed.io/vuln/detail/CVE-2026-40519
26
Apache / Re: HTTP/2 Bomb — Remote DoS Exploit Hits nginx, Apache, IIS, Envoy, and Cloudflare
« Last post by Starburst on June 08, 2026, 11:08:26 PM »I think the only way to find the version of mod_http2 is to check the log of the webserver:
/usr/local/apache/logs/error_logCode: [Select]grep 'mod_http2' /usr/local/apache/logs/error_log
You da man @cyberspace...
Shows the version for both mod_http2 and nghttp2

27
Apache / Re: HTTP/2 Bomb — Remote DoS Exploit Hits nginx, Apache, IIS, Envoy, and Cloudflare
« Last post by cyberspace on June 08, 2026, 10:52:58 PM »I think the only way to find the version of mod_http2 is to check the log of the webserver:
/usr/local/apache/logs/error_log
/usr/local/apache/logs/error_log
Code: [Select]
grep 'mod_http2' /usr/local/apache/logs/error_log
28
Apache / Re: HTTP/2 Bomb — Remote DoS Exploit Hits nginx, Apache, IIS, Envoy, and Cloudflare
« Last post by Starburst on June 08, 2026, 05:17:09 PM »Would be useful either way to find out what mod_http2 the system is running.
29
Apache / 7 new CVE's for Apache. 2.4.68 Just Released
« Last post by Starburst on June 08, 2026, 05:16:06 PM »CISA Just release 7 new CVE's for Apache, that affect up to version 2.4.67
The Apache Foundation just release 2.4.68 that take care of the vulnerabilities.
Update guides, if needed can be found at:
HTTP/2 Version:
https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/update-apache-http-2-to-2-4-68-in-cwp-on-almalinux-8-9/
Non HTTP/2 Version:
https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/update-apache-to-2-4-68-in-cwp-on-almalinux-8-9/
The Apache Foundation just release 2.4.68 that take care of the vulnerabilities.
Update guides, if needed can be found at:
HTTP/2 Version:
https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/update-apache-http-2-to-2-4-68-in-cwp-on-almalinux-8-9/
Non HTTP/2 Version:
https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/update-apache-to-2-4-68-in-cwp-on-almalinux-8-9/
30
Apache / Re: HTTP/2 Bomb — Remote DoS Exploit Hits nginx, Apache, IIS, Envoy, and Cloudflare
« Last post by overseer on June 08, 2026, 11:56:09 AM »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.
Recent Posts