Recent Posts

Pages: 1 2 [3] 4 5 ... 10
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
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
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!
25
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
26
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

Code: [Select]
grep 'mod_http2' /usr/local/apache/logs/error_log

You da man @cyberspace...

Shows the version for both mod_http2 and nghttp2  :)
27
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

Code: [Select]
grep 'mod_http2' /usr/local/apache/logs/error_log

28
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/
30
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.
Pages: 1 2 [3] 4 5 ... 10