Messages

1

Other / Re: Goodbye CWP — I’m done for good

« on: February 22, 2026, 06:22:42 AM »

Okay, goodbye. We'll miss your contribution here.

I'm all for ending the AI-composed echo chamber. You're making your choice, I've made mine. I'm sticking with CWP for the foreseeable future. Hope your new panel serves you well!

Okay, goodbye. We'll miss your contribution here.

I'm all for ending the AI-composed echo chamber. You're making your choice, I've made mine. I'm sticking with CWP for the foreseeable future. Hope your new panel serves you well!

Yea, I used AI to refine my wording intentionally, so I don't use the words or adjectives I actually think for some people hijacking this form to get adrenaline rush and I don’t waste time on petty phrasing debates.

What’s interesting is that instead of addressing the real observations points (changelog, CVE timelines, roadmap, support expectations), the reply is about “AI echo chambers.”

That tells me everything I need to know, for me and specially for you fan boy...

We clearly operate at different standards where I am not blinded by the cheerleading and knee jerk defence of CWP or any other forum you spend your time on; it's time to grow up and take real decisions. I’ve moved on, and I’m not spending more time in circles.

For AI, yea I use it heavily to write and integrate it into my projects.

FYI, I still used AI to omit the words I actually i meant...

Good luck, you’ll need it the day...

Logging out for good... JS

2

Other / Re: Goodbye CWP — I’m done for good

« on: February 19, 2026, 05:54:20 AM »

Completely agree with Jaspreet Singh.

This project seems to be dead, as we have not received any updates since Nov 2024, and there is no support on the forum either.

Some time ago, I contacted the CWP team, and they said they were working, but they blocked me then. There are a few members who are running the forum by just saying "CWP Team is working, CWP is not dead, blah blah, etc.." and a few of them are sharing their article users, but the actual CWP team doesn't bother looking at the forum.

It's time to move on

Project is NOT DEAD. Not sure why you keep posting that line...

CWP pushed an update today (2026-02-18)  0.9.8.1222.
And before that 0.9.8.1221 was pushed on 2026-02-02

It's personal preference if you want to stop using CWP and 'move on'

I've tested other panels, and they all have CVEs and can not be kept updated as easily as CWP can be.
Some don't even have the features CWP has, and cost $$$ more.

Can CWP do better with some things, yes.

Clarifying “dead” vs “production-viable” (and what I’m asking for)

Nobody is saying “no code ever ships” or “the installer stops working.” The point is operations reality : predictable maintenance, transparent communication, and accountable support.

Right now, what’s missing (for me, and for others replying here) is official clarity :

• Release notes / changelog transparency:
  Version numbers being pushed is not a changelog. A serious production panel needs release notes that answer:
  
  • What changed?
  • What was fixed?
  • What was removed/broken?
  • What security issues were addressed (with references)?
  If there is an official changelog for 2025–2026, please link it. If not, that’s exactly the problem.
• Security cadence & accountability:
  “All panels have CVEs” is true and irrelevant. The question is: how fast are fixes shipped and communicated?
  Please provide:
  
  • The last 5 high/critical CVEs that affected CWP’s stack
  • For each: disclosure date → patch date → where it was documented
  Without that, admins are forced into DIY patching and custom scripts to stay safe which is not acceptable for client workloads.
• Roadmap (missing or opaque):
  This is the biggest gap. A roadmap isn’t “talk.” It’s a public commitment with dates (even if approximate) and scope.
  Examples of what operators need to know:
  
  • PHP cadence: When are 8.4 and 8.5 planned, and what is the official method (repo/channel) and support window?
  • OS support: Which distro versions are officially supported today, and until when? What is the plan for newer major OS releases?
  • Core components roadmap: web stack changes, mail stack changes, kernel/openssl compatibility, DB stack changes  what is planned and what is not?
  • Breaking changes policy: How are breaking changes communicated and how are rollbacks handled?
  • EOL policy: What is the official end-of-support policy for older stacks?
  If the answer is “use a community guide” or “you can DIY it,” that’s precisely confirming the ops problem: we’re building the missing roadmap ourselves.
• Support reality:
  Community help is appreciated but it is not the same as official support. 
  If the official support channel exists, please share:
  
  • Where to file issues
  • Expected response time
  • What’s covered vs not covered
  Forum replies and unofficial “help hubs” can’t replace accountability when clients are paying and uptime/security matter.
• Production-grade features (example: DNS cluster):
  If DNS clustering is considered production-ready, please link the official documentation/design and the supported failure modes (sync model, consistency, recovery, monitoring).
  If it requires custom scripts to be stable and predictable, then it’s not production-grade.

So my position stays simple:
If someone wants to argue “Project is NOT DEAD,” that’s fine but then please answer with links and specifics:

• Official changelog/release notes (2025–2026)
• CVE fix timelines (disclosure → patch → documentation)
• Official roadmap (PHP + OS support + core stack + policy)
• Official support channel + expectations

On the “but it’s cheaper” argument (price vs total cost)

Cost is not the point being debated predictable operations are.

Yes, other panels can be more expensive up-front. But the real comparison for anyone running client workloads is TCO (Total Cost of Ownership):

• Admin time: Hours spent firefighting, writing custom scripts, applying workarounds, and reverse-engineering changes.
• Security exposure: Slow fixes + unclear advisories increases risk, and one incident costs more than years of license fees.
• Downtime cost: Outages, mail issues, broken updates your time + customer churn + reputational damage.
• Opportunity cost: Time wasted on panel survival is time not spent growing the business.

So “it’s cheaper” is not a rebuttal to missing changelogs, missing roadmap, slow security response, or support gaps.
It only proves this: some users accept those risks because their use-case is static and price-sensitive. That’s fine.
But for production hosting where accountability matters, cheap without transparency becomes expensive.

If a “cheap” panel costs even 2–3 extra hours/week in babysitting, that alone can exceed the license price difference before counting downtime or security incidents.

Until those exist publicly and consistently, calling it “alive” doesn’t help the people running production. 
That’s why I moved on. No drama just operational facts.

3

Other / Goodbye CWP — I’m done for good

« on: February 14, 2026, 06:55:08 PM »

Goodbye CWP, I’m done for good.

Alright folks, this is my last post here.

I’m officially moving away from Control Web Panel and I’m not looking back. This isn’t a rage-quit. It’s a long-overdue “operations sanity” decision.

Why I’m leaving:

• Admins missing in action. Too often it feels like nobody is steering the ship.
  
• A few loud users run the forum. If you ask real questions, you get politics instead of answers.
  
• Support reality: Asking for help here is mostly useless and if you positively criticize something, some people act like you committed a crime.
  
• The usual reply: “Go buy a paid panel then.” Cool. That’s exactly what I did because when clients are paying me, I need reliability and support, not forum drama.
  
• Updates went for a toss: There hasn’t been a meaningful update in forever (feels like a year+). PHP updates feel like a wishful dream, roadmap talk stays talk, and the product momentum just isn’t there.
  
• Updates + security: CVEs get discovered fast… but fixes feel slow. And in between, you’re left patching holes with your own custom scripts just to keep things tight.
  
• DIY forever: Fixing loopholes and making things “production-safe” shouldn’t require custom scripts for half the stack, but here we are.
  
• DNS cluster (sorry): It’s not production-grade. I ended up writing my own DNS cluster scripts and they’ve been more stable and predictable than what I got out of the box.
  

My take (simple):
Open-source is amazing when it’s actively maintained and supported. 
But if you’re running a business, charging clients, or your uptime matters, then support and accountability aren’t “luxury items.” They’re the basics.

So yeah… I finally did it. Moved on. 
And honestly, if you’re reading this while firefighting the same stuff every week maybe you should consider it too.

No hate, no personal beef just facts from the trenches.

Wishing you all the best. 
Logging off for good...

--
Jaspreet Singh

4

PHP / Re: 0.9.8.1215

« on: September 10, 2025, 06:53:09 PM »

any chance that php 8.4 may debut via an update to avoid manual installation errors or issues?

5

Updates / Will someone update the Changelog

« on: September 06, 2025, 07:47:20 PM »

I noticed my CWP server just dropped an update tarball for CWPpro version: 0.9.8.1214

I have no clue what were the changes or fixes in last few updates or whats going on, No idea on PHP update or 8.4 version or others.

Will someone please update the same?

6

Updates / Re: Roundcube vulnerability

« on: August 26, 2025, 02:19:15 PM »

Here is the updated guide to update Roundcube to version 1.5.11:

https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/update-roundcube-webmail-to-version-1-5-11-in-cwp-on-almalinux-8-9/

Worked with Rocky 8

7

CentOS-WebPanel Bugs / Re: [CRITICAL] Multiple CWP Servers Infected – Arbitrary PHP Code Execution via Publ

« on: July 13, 2025, 03:29:12 PM »

just checked it, fixed. can someone also please validate the same.

8

CentOS-WebPanel Bugs / Re: [CRITICAL] Multiple CWP Servers Infected – Arbitrary PHP Code Execution via Publ

« on: July 12, 2025, 01:33:35 PM »

My Approach to Stopping the CWP File‑Manager Exploit

• 1. Scan & Identify Malware
      • Searched for obfuscated PHP payloads 
     

Code: [Select]

    grep -rniE "(eval\s*\(|base64_decode|gzinflate|str_rot13|shell_exec|proc_open|passthru|system)" \
        /home/*/public_html/
   
    • Caught the classic pair in every account:
      nbpafebaef.jpg  (PHP in disguise) 
      defauit.php     (web‑shell)

    • Found tmp propagators reported in the forum thread: 
      /tmp/.auto_monitor and /tmp/.tmp_baf[/li]

[li]2. Clean & Quarantine
   

Code: [Select]

    mkdir /root/quarantine
    mv /home/*/public_html/{nbpafebaef.jpg,defauit.php} /root/quarantine 2>/dev/null
    mv /tmp/.auto_monitor /tmp/.tmp_baf /root/quarantine
        • Manually opened every recently‑modified functions.php; all were clean, so no theme replacement required.[/li]

[li]3. Global Block via ModSecurity (NOT .htaccess)
    Added to /usr/local/apache/modsecurity-cwaf/custom_user.conf:
   

Code: [Select]

# Put your custom ModSecurity directives here
# Please don't remove this file
# Block CWP filemanager exploit attempts (CVE-2025-48703)
SecRule REQUEST_URI "@contains /user/index.php" \
    "id:4870301,phase:2,deny,status:403,log,msg:'[CWP Exploit Block] Block access to module=filemanager&acc=findFiles',\
    chain"
    SecRule ARGS:module "@streq filemanager" \
        "chain"
        SecRule ARGS:acc "@streq findFiles"

        Restart Apache:
   

Code: [Select]

systemctl restart httpd[/li]

[li]4. Verification (cURL)
   

Code: [Select]

    curl -X POST "https://your-domain.com/user/index.php?module=filemanager&acc=findFiles" \
         -A "Mozilla" -I
    # Expected: HTTP/1.1 403 Forbidden
   

403 confirms ModSecurity now blocks the exploit endpoint for every vHost.[/li]

Result: Infection removed, endpoint sealed, and logfile shows only blocked attempts. 
Hope this helps anyone still cleaning up from the same CVE!

9

Installation / Re: CWP-CentOS 8 MINIMAL ou BOOT Stream-Delayed

« on: July 12, 2025, 01:32:40 PM »

My Approach to Stopping the CWP File‑Manager Exploit

• 1. Scan & Identify Malware
      • Searched for obfuscated PHP payloads 
     

Code: [Select]

    grep -rniE "(eval\s*\(|base64_decode|gzinflate|str_rot13|shell_exec|proc_open|passthru|system)" \
        /home/*/public_html/
   
    • Caught the classic pair in every account:
      nbpafebaef.jpg  (PHP in disguise) 
      defauit.php     (web‑shell)

    • Found tmp propagators reported in the forum thread: 
      /tmp/.auto_monitor and /tmp/.tmp_baf[/li]

[li]2. Clean & Quarantine
   

Code: [Select]

    mkdir /root/quarantine
    mv /home/*/public_html/{nbpafebaef.jpg,defauit.php} /root/quarantine 2>/dev/null
    mv /tmp/.auto_monitor /tmp/.tmp_baf /root/quarantine
        • Manually opened every recently‑modified functions.php; all were clean, so no theme replacement required.[/li]

[li]3. Global Block via ModSecurity (NOT .htaccess)
    Added to /usr/local/apache/modsecurity-cwaf/custom_user.conf:
   

Code: [Select]

# Put your custom ModSecurity directives here
# Please don't remove this file
# Block CWP filemanager exploit attempts (CVE-2025-48703)
SecRule REQUEST_URI "@contains /user/index.php" \
    "id:4870301,phase:2,deny,status:403,log,msg:'[CWP Exploit Block] Block access to module=filemanager&acc=findFiles',\
    chain"
    SecRule ARGS:module "@streq filemanager" \
        "chain"
        SecRule ARGS:acc "@streq findFiles"

        Restart Apache:
   

Code: [Select]

systemctl restart httpd[/li]

[li]4. Verification (cURL)
   

Code: [Select]

    curl -X POST "https://your-domain.com/user/index.php?module=filemanager&acc=findFiles" \
         -A "Mozilla" -I
    # Expected: HTTP/1.1 403 Forbidden
   

403 confirms ModSecurity now blocks the exploit endpoint for every vHost.[/li]

Result: Infection removed, endpoint sealed, and logfile shows only blocked attempts. 
Hope this helps anyone still cleaning up from the same CVE!

10

Information / Re: Roundcube big security issue.

« on: April 21, 2025, 05:26:19 PM »

UPDATE – Correction to my previous response

In my earlier post, I suggested disabling Roundcube logging using the following entries in `config.inc.php`:

Code: (php) [Select]

$config['log_driver'] = 'null';
$config['log_logins'] = false;
$config['log_session'] = false;
$config['log_authfail'] = false;
$config['smtp_log'] = false;
$config['imap_log'] = false;

While these are valid config parameters, they do not prevent Roundcube from writing to errors.log when it's running under CWP’s internal `cwpsrv` backend.

The correct fix is located in the core bootstrap file:

Code: [Select]

/usr/local/cwpsrv/var/services/roundcube/program/lib/Roundcube/bootstrap.php

At line 31, change:

Code: (php) [Select]

'log_errors' => true,
to:

Code: (php) [Select]

'log_errors' => false,

This completely disables error logging in Roundcube and prevents `errors.log` from being generated or written to.

Reference: https://www.roundcubeforum.net/index.php?topic=30798.0 – Roundcube Forum, February 23, 2024

11

Information / Re: Roundcube big security issue.

« on: April 19, 2025, 05:38:20 AM »

✅ SOLVED – Roundcube logs publicly accessible via /logs/errors.log (CWPpro 0.9.8.1201)

If you're seeing this issue:

Code: [Select]

https://domain.com/webmail/logs/errors.log
https://domain.com/roundcube/logs/errors.log
...and `.htaccess` isn’t being respected by `cwpsrv` or your webmail backend, here's a permanent fix that works regardless of web server behavior.

🛠️ Solution: Disable Logging from Within Roundcube 
This will stop Roundcube from writing to `errors.log` entirely.

Step-by-step instructions:
[olist]

• SSH into your server
• Edit the Roundcube config file:

Code: [Select]

nano /usr/local/cwpsrv/var/services/roundcube/config/config.inc.php
[/li]
[li]Add the following at the bottom:[/li][/list]

Code: (php) [Select]

// Disable all Roundcube logging
$config['log_driver'] = 'null';       // Prevent writing logs
$config['syslog_id'] = null;          // Disable syslog output
$config['log_logins'] = false;        // Do not log logins
$config['log_session'] = false;       // Do not log sessions
$config['log_authfail'] = false;      // Do not log failed logins
$config['smtp_log'] = false;          // Disable SMTP log
$config['imap_log'] = false;          // Disable IMAP log
[/li]
[li]Save and exit (Ctrl+O, Enter, Ctrl+X)[/li][/list]
[/olist]

✅ No restart needed — changes are applied immediately.

🧱 Why this works: 
Disabling logging at the application level ensures nothing is written to disk, eliminating the exposure even if `.htaccess` is ignored.

🔍 Tested On:

Code: [Select]

CWPpro:        0.9.8.1201
Roundcube:     1.4.11 & 1.5.6
Apache:        2.4.62
PHP-FPM:       8.2.28
MariaDB:       10.11.11
OS:            Rocky Linux 8.10
Stack:         Nginx → Apache (forced PHP-FPM)

Hope this helps others secure their Roundcube installs on CWP. 
Let me know if you need a web server rule version as well.

Jaspreet Singh 

12

Nginx / Re: How to update NGINX version to version 1.26.2

« on: March 22, 2025, 05:17:49 AM »

My Approach to Upgrading Nginx Without a Full Reinstallation

In my experience, the optimal strategy is to update Nginx directly using the official stable repository, rather than removing it entirely. This approach helps maintain your current configuration and avoids the hassle of extensive reconfiguration.

Step 1: Backup Existing Configurations

• Backup the conf.d directory.
  
• Backup the nginx.conf file.
  

Step 2: Add the Official Stable Repository
Instead of removing your existing Nginx installation, add the new stable repository. This is crucial for accessing the latest version without disrupting your current setup.

Step 3: Direct Update
Execute a direct update using:

Code: [Select]

dnf update nginx
This command updates Nginx in place, preserving your configuration and significantly reducing the risk of introducing new issues.

Step 4: Apply Configuration Adjustments
Navigate to WebServer Settings > WebServers Main Conf. Verify and adjust the necessary settings, and enable the "rebuild all vhost on save" option to ensure all virtual host configurations are updated seamlessly.

Step 5: Restart Services
Restart both Apache and Nginx to finalize the update.

This method emphasizes stability and preserves your existing configuration, avoiding the unnecessary overhead and risks associated with a full reinstallation.

13

Information / Re: Changelogs

« on: November 12, 2024, 03:02:53 PM »

Version CWP7: 0.9.8.1188 release, yet no changelogs.

14

DNS / Re: DNS Slave

« on: April 03, 2024, 01:43:37 PM »

I appreciate the insights shared in this discussion.

I took a different approach to setting up DNS slave servers for CWP and it works flawlessly, even without the CWPpro version.
Although I do recommend the pro version for its added features, my method provides a robust solution, For a complete tutorial on how to set up high-availability DNS slave servers for the CWP panel, you can check out my post at

https://www.jaspreet.net/2211/2024/02/22/how-to-setup-high-availability-dns-slave-servers-for-cwp-panel-complete-tutorial/

It’s a comprehensive guide that I believe will be beneficial for many users here.

15

Installation / CWP Host SSL with Cockpit?

« on: February 01, 2023, 05:47:12 AM »

Hello,

I am using Rocky 8.7 with CWP Pro. I have also got Cockpit running to monitor the Physical Server. I noticed that Cockpit is using unsigned or self signed certificates.

My Question: Is there a way we can configure CWP or Cockpit to use Lets encrypt ssl certs already present on CWP server. (In my case i al talking about hostname certs to be shared with Cockpit.)

Any Advise will be highly appreciated. If I have posted this post in wrong category, I apologies for the same in advise.

Cheers!