Control Web Panel
WebPanel => Information => Topic started by: NIIcK on October 07, 2025, 02:38:21 PM
-
Hello,
I have a PRO license of CWP and I have submitted several tickets in the past concerning Varnish not working with Almalinux 9. The initial one was in February 2025 and last one in September 2025.
Almalinux 9 is mentioned as supported by CWP and while I understand that it takes time to deal with everything CWP it is very hard for me to understand 10 months now and no change in the Varnish status.
Secondly, ConfigServer Services has announced the end of support for CSF as of 31st of August 2025 clearly stating that:
In order to continue using any of our commercial software after the 31st of August, you must have updated the software to the latest version.
If you did not update the software, any of our commercial software products will cease to function and cannot be reactivated once the download and license servers are shut down.This time had passed with no reaction from the CWP team, again.
My question to the CWP team is: are you still maintaining it? As, by the looks of it, you don't.
Thank you.
P.S. Link to the ConfigServer Services (CSF) announcement: https://configserver.com/announcement/
-
In 28/08/2025 i sent a ticket to support:
"Since CSF will no longer be updated, is there any alternative for CWP? Since there is no firewall directly in the CWP (only the CSF integration), this can have big downsides for the panel.
Announcement here: https://configserver.com/announcement/"
The response:
"Hello.
Yes, we know about the issue.
Regards,"
Indeed, the lack of comunication is concerning.
And CWP appears even more unmaintained to this point. Nothing really is "new".
And don't forget a preaty bad security issue, that was never explained: https://forum.centos-webpanel.com/centos-webpanel-bugs/critical-multiple-cwp-servers-infected-arbitrary-php-code-execution-via-publ/
This happend, and no, is not a issue with the websites or WordPress in the server. Was a issue with CWP that was never publicly confirmed by the team, and was fixed silently with the updates.
The lack of comunication is concerning, and the lack of new updates is also concerning.
Maybe is better start to look for alternatives, because CWP appears every single day more "dead".
-
CWP is not dead, was just updated 2 days ago. The security issue was fixed within days and is a non-issue now (but each admin should inspect their servers to ensure there was not a compromise). The ConfigServer team surprised the world by only giving 30 days notice before closing up shop. It is now GPLv3 licensed, so development can continue or it could be forked. There are guides on updating CWP to use the open source version, but probably the best course is to hold tight and wait to see which direction CWP pursues and keep your kit mainline without deviating too far.
The dev team could certainly increase in communication, but it is still a solid product -- I run multiple servers under it. Far better value proposition than cPanel, for sure!
-
That doesn't solve the issue.
Just because a update was "launch" two days ago, don't say much. Where is the changelog, what changed, do you know?
For what you know, could just be a "minor" bump in the version number...
And the security issue, yes, was solved in days... without any information. Not even a single post from the team to confirm that have existed - and you can see that in the topic. There is still people that think that was because of something in the Wordpress or some website in it...
The lack of comunication IS a problem. The lack of new features is a problem, there is no confirmation about what is going on, the road map, nothing...
-
CWP is still going and is alive.
As mentioned by @overseer 0.9.8.1218 was just release on 2025-10-06, and 0.9.8.1217 was on 2025-09-22.
These where both bug fixes.
It is noted that AL9 is in beta with CWP.
Never quite understood the whole Apache/Nginx/Varnish thing.
If you have a fast enough server and connection, just plain 'ol Apache works fine, and without any complicated setup/config.
You can try posting your problem at https://www.alphagnu.com/ (https://www.alphagnu.com/)
The PHP issue is with a PHP bug, has Nothing to do with CWP.
Most of the servers where the attack went thru where running CentOS 7.
If you have your PHP configured correctly, and updated, you should be fine.
For your CSF questions, see: https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/csf-firewall-error-oops-unable-to-download-no-host-option-provided (https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/csf-firewall-error-oops-unable-to-download-no-host-option-provided)/
But if your not happy with CWP, maybe cPanel would suit your needs better.
-
In 28/08/2025 i sent a ticket to support:
"Since CSF will no longer be updated, is there any alternative for CWP? Since there is no firewall directly in the CWP (only the CSF integration), this can have big downsides for the panel.
Announcement here: https://configserver.com/announcement/"
The response:
"Hello.
Yes, we know about the issue.
Regards,"
Indeed, the lack of comunication is concerning.
And CWP appears even more unmaintained to this point. Nothing really is "new".
And don't forget a preaty bad security issue, that was never explained: https://forum.centos-webpanel.com/centos-webpanel-bugs/critical-multiple-cwp-servers-infected-arbitrary-php-code-execution-via-publ/
This happend, and no, is not a issue with the websites or WordPress in the server. Was a issue with CWP that was never publicly confirmed by the team, and was fixed silently with the updates.
The lack of comunication is concerning, and the lack of new updates is also concerning.
Maybe is better start to look for alternatives, because CWP appears every single day more "dead".
CWP didn't have anything to do with ConfigServer closing down.
And there is nothing else on the market like CSF/LFD.
But v15.00 works fine, and will continue working.
After all the year, CSF pretty much doesn't need any updates. Which is good.
Again, the PHP Injection Attack, had nothing to do with CWP.
But happened to older servers that where not updated and their PHP hardened.
PHP Injection Attacks are common by script kiddies. And just don't happen to CWP.
GoDaddy's servers are constantly getting hacked, which are using Amazon AWS. lol
There are several articles out there on has to secure you php.ini config.
-
But if your not happy with CWP, maybe cPanel would suit your needs better.
I don’t think going with a black-and-white mindset is the best way forward. Like I said, CWP isn’t “freeware,” no matter what the price tag is. If we keep thinking cheap means bad or that low cost equals poor communication, then we might as well shut things down and move on.
Your posts, @Starburst, basically prove my point about CWP’s communication. It’s been the community doing the talking and dealing with issues—not the CWP team.
Sure, being a sysadmin means reading a lot and keeping up with updates, but if you’re paying for a product, you expect certain things—like being kept in the loop about what’s happening with the platform that’s supposed to protect your business and income.
Big thanks, @Starburst, for the CSF fix here:
https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/csf-firewall-error-oops-unable-to-download-no-host-option-provided/
.
Kinda bittersweet though—since this should’ve already been taken care of by CWP themselves.
-
Kinda bittersweet though—since this should’ve already been taken care of by CWP themselves.
And that is the point.
@Starburst
No one is saying that CSF closure was CWP fault... makes no sense...
What i was saying is that CWP is not providing a clear information about anything. And you are proving that.
Again: yes, there was a update recently in CWP. But you know what was updated? I bet you can't provide anything that confirm WHAT has been updated, besides the version number in your panel. That IS the point.
The vulnerability in CWP. No one talks about it? Let it go under the rug in silence?
That is NOT how the development of a control panel should go... I still dont see ANY information about it. Yes, was patched, but was silently patched - that is worrying.
And the plans for CSF... you are proving my point there again.
Yes, the guides can be great, but they are NOT from the CWP team itself, are from a third party. It is concerning when is a third party that must start to provide information about basic things, and not the developers of the control panel itself.
And even more, your guides can help... but do we know you? Who are you exactly?
You are providing guides to make critical changes in our systems, that some people without knowledge follow... and yes, the could work. But your guides provide your own mirrors, with your own code in the mix.
How do we know that we can trust you and your code?
Some people will follow your guides, without knowing what are they doing.
And you can be a great person, don't get me wrong. You appear to be here to help... but we are in the internet....
I look at your guides, and they are ok - but i would be worry to use code that is in a unknown mirrror. Would be better if CWP team provide those instead? Yes, it will, because at least CWP we know...
-
Again, the PHP Injection Attack, had nothing to do with CWP.
But happened to older servers that where not updated and their PHP hardened.
PHP Injection Attacks are common by script kiddies. And just don't happen to CWP.
GoDaddy's servers are constantly getting hacked, which are using Amazon AWS. lol
There are several articles out there on has to secure you php.ini config.
That is NOT true.
The issue WAS a vulnerability in CWP. Is NOT fault from the users.
https://fenrisk.com/rce-centos-webpanel
https://gbhackers.com/centos-web-panel-vulnerability/
So not, wasn't the users fault. it WAS a vulnerabilty in CWP.
-
@Starburst
And even more, your guides can help... but do we know you? Who are you exactly?
You are providing guides to make critical changes in our systems, that some people without knowledge follow... and yes, the could work. But your guides provide your own mirrors, with your own code in the mix.
How do we know that we can trust you and your code?
Some people will follow your guides, without knowing what are they doing.
And you can be a great person, don't get me wrong. You appear to be here to help... but we are in the internet....
I look at your guides, and they are ok - but i would be worry to use code that is in a unknown mirrror. Would be better if CWP team provide those instead? Yes, it will, because at least CWP we know...
I am a very old and warped SysOp. 8)
Our servers have been running CWP since 2019.
We are also a large mirror provider for ELRepo. So if you use that repo, you probably connect to one of our servers around the globe.
As well as a mirror in England for MariaDB.
Which also gave use the unique ability to do what we did for CSF.
Any 'code' we offer is in plain English to say, and you can see exactly what it is doing.
Also any feedback is welcome to make our guides better, as we aim to be more than 'OK'.
As any company the KB has article we used allot, and there are some that are not public, since those usually very company to company with specific settings.
-
@Starburst You are going offtopic - that is not the point here. I stated that in the previous message exactly to reinforce the point.
The fact that you are providing KB articles, and NOT the CWP team, is the problem here. You are NOT the CWP team...
And you left back the questions: you KNOW what changed in the updates? Do you know anything that is made in every update?
I see that you provided false information in the CWP exploit topic, stating that it wasn't a CWP exploit.... when it was.
This alone shows how little comunication is made from the team.... is a random member in the forum that is providing the information without any "official" knowledge of what is happening.
Is great that you are trying to help anyone around here, and great if you have the back for that as a sysadmin... but you are NOT the CWP team and cannot make sentences for them about the control panel, because is NOT your own creation/development.
-
Again, the PHP Injection Attack, had nothing to do with CWP.
But happened to older servers that where not updated and their PHP hardened.
PHP Injection Attacks are common by script kiddies. And just don't happen to CWP.
GoDaddy's servers are constantly getting hacked, which are using Amazon AWS. lol
There are several articles out there on has to secure you php.ini config.
That is NOT true.
The issue WAS a vulnerability in CWP. Is NOT fault from the users.
https://fenrisk.com/rce-centos-webpanel
https://gbhackers.com/centos-web-panel-vulnerability/
So not, wasn't the users fault. it WAS a vulnerabilty in CWP.
Yes, but other control panels HAD this problem also, even Chrome did...
As did cPanel:
https://sploitus.com/exploit?id=948E719F-C0C9-518E-969F-C65D0D6FBE65 (https://sploitus.com/exploit?id=948E719F-C0C9-518E-969F-C65D0D6FBE65)
https://www.reddit.com/r/webhosting/comments/1d1jg3v/help_hacker_keeps_injecting_code_into_my_cpanel/ (https://www.reddit.com/r/webhosting/comments/1d1jg3v/help_hacker_keeps_injecting_code_into_my_cpanel/)
https://medium.com/@anonymousshetty2003/sql-injection-vulnerability-on-a-security-awareness-website-from-database-dump-to-cpanel-access-4bb3645eef07 (https://medium.com/@anonymousshetty2003/sql-injection-vulnerability-on-a-security-awareness-website-from-database-dump-to-cpanel-access-4bb3645eef07)
https://stackoverflow.com/questions/550879/php-injection-attack-how-to-best-clean-up-the-mess (https://stackoverflow.com/questions/550879/php-injection-attack-how-to-best-clean-up-the-mess)
Look at gbhackers, they list all the vulnerabilities with PHP: https://gbhackers.com/multiple-php-vulnerabilities/ (https://gbhackers.com/multiple-php-vulnerabilities/)
https://www.broadcom.com/support/security-center/attacksignatures/detail?asid=30062 (https://www.broadcom.com/support/security-center/attacksignatures/detail?asid=30062)
aaPanel even had the same issue:
https://fenrisk.com/rce-aapanel
PHP even has a comment about it:
https://www.php.net/manual/en/mongodb.security.request_injection.php (https://www.php.net/manual/en/mongodb.security.request_injection.php)
Even Chrome had been affected...
https://gbhackers.com/technical-details-and-exploit-released-for-chrome-flaw/ (https://gbhackers.com/technical-details-and-exploit-released-for-chrome-flaw/)
https://cybersecuritynews.com/10-year-old-roundcube-rce-vulnerability/ (https://cybersecuritynews.com/10-year-old-roundcube-rce-vulnerability/)
post-authenticated remote code execution vulnerability that exploits PHP object deserialization.
I could continue on, but don't blame CWP, when they where clearly not the only one who had this.
But systems that has proper PHP security hardening survived the attacks.
Our ModSecurity systems caught the PHP Injection Attacks as well, and blocked them.
No system is 100%, but this was NOT a CWP bug, but rather a PHP common code vulnerability that affect ALL system running PHP.
-
@Starburst You are going offtopic - that is not the point here. I stated that in the previous message exactly to reinforce the point.
The fact that you are providing KB articles, and NOT the CWP team, is the problem here. You are NOT the CWP team...
And you left back the questions: you KNOW what changed in the updates? Do you know anything that is made in every update?
I see that you provided false information in the CWP exploit topic, stating that it wasn't a CWP exploit.... when it was.
This alone shows how little comunication is made from the team.... is a random member in the forum that is providing the information without any "official" knowledge of what is happening.
Is great that you are trying to help anyone around here, and great if you have the back for that as a sysadmin... but you are NOT the CWP team and cannot make sentences for them about the control panel, because is NOT your own creation/development.
Fine, they don't expect any help from us or probably any others here other than the 'Official CWP team'...
But also don't spread Mis-information about CWP, that you clearly don't have the experience or knowledge to talk about...
We are a CWP partner company, and not some 'random' forum member...
-
Your post makes no sense.
All you have done is link to many RCE vulnerabilities in different applications - some dated 16 years ago. What have that to do with anything?
No one is saying that RCE is a "new thing"... is a security issue, and yes, if has happend before in different aplications... but what have that to do with the LACK OF COMMUNICATION from CWP, about the RCE issue that happend in the control panel.
Those links have nothing to do with the CWP situation.
Or are you stating that just because RCE is a thing, CWP shouldn't be blamed because of it?
For that logic, every attack, malware or exploit have a excuse: "oh well, it happend to others, so..."
Do you see the fault in your logic?
The point here is that CWP did NOT acknowledge the security issue, not even a post to alert the administrators about it. Not even in the post that was created by a forum member to alert.
Can you provide some way in HOW they confirm the issue?
So yes, CWP is to blame. They fixed, but silent fix a security issue is NOT the way that any credible company does this - and you should know that!
And about the other issue, @Starburst, you can be whatever you want to be. You can be a CWP partner... but you ARE NOT CWP.
Again, you are making no sense... How i was spreading misinformation?
- You are just a forum member? Yes
- You provided false information about in how CWP had nothing to do with a security issue in they panel? Yes
- You are trying to prove that just because RCE exploits exist - had had FOR YEARS - that somehow make CWP team not responsible to disclose a security issue in they panel? Yes.
- You are a CWP Partner? Yes
- You are NOT a CWP team member, so you cannot talk for them? Yes
Is anything here wrong?
In fact, your response about all this is troubling, because you cannot call you a sys admin and state that every exploit in a software should be "excused" just because "it exist"... That is NOT how this works...
You are a forum member, that's it. You are not the entity responsible for the CWP development, and you don't have any say or do in how CWP is developed. Only the CWP team has, and to this point, no one is talking anything.
at best yes, you are a CWP partner... but STILL NOT A DEVELOPER of the CWP team.
-
TLDR: If you develop something, you ARE responsible for the security of that thing. Just because you have an error in the code, security issue, or anything in the thing that you develop, that doesn't make you any less responsible for it.
yes, you should fix it. But if is something that OTHERS WILL USE, you should ALSO report that to everyone, not sweep under the rug....
And no: you cannot excuse the issue just because others had it. That is not any of this works.... never had been.
-
One more time, apparently I have to be very KISS with you...
The RCE Vulnerability was a PHP RCE VULENABILITY
That affected, CWP, cPanel, aaPanel, and MANY Others that run PHP...
You just singling out and blaming CWP IS mis-information, and not the root cause.
Please go use cPanel or some other control panel.
-
Guys, the annual Pro license of CWP costs $12 ($1/month). You can consider it as donation because no one can provide high quality support service for such price. So just expect as much as much you pay.
So if you run serious business and care about your product then consider to use the enterprise level control panel like cPanel, DirectAdmin, Plesk, etc. However, cPanel has some mail vulnerabilities/security breaches and their team doesn't care to fix it.
"Every program (control panel) has vulnerabilities, if the program (control panel) doesn't have vulnerabilities then it means no one uses this program or it is useless."
-
Here is the CVE, and even advised has to secure against it, dated 2024-09-27...
https://www.wiz.io/blog/critical-rce-php-cgi-vulnerability
But @cyberpscae is correct.
-
dude, no one is blaming CWP for the RCE... that is a PHP thing, exist since PHP exist...
What you don't understand that is NOT *the* vulnerability, but the LACK OF INFORMATION to acknowledge the vulnerability from the CWP side?
CWP had a vulnerability. THAT IS FINE.... if they fix it and disclosure it.
They fix it. Great!
But the disclosure? NO!
Every single one of the panels that you state HAVE disclosure the vulnerability in they software. Because - and again, becase you apparently cannot understand this - THEY ARE RESPONSIBLE FOR THE SOFTWARE THAT THEY CREATED!
CWP did not disclosure that. They prefer hide it under a "update", that you don't even know what is. Or do you have a changelog for the versions lauch?
-
Yes, they are responsible for the software they create, but they DID NOT CREATE PHP...
And that's where this vulnerability is located.
You are blaming CWP in your posts THEY ARE RESPONSIBLE FOR THE SOFTWARE THAT THEY CREATED!
for something they had NO control over. And hence it wasn't a CWP bug to even 'disclose' or responsible for.
You need to goto the PHP forums and blame them, as they are the ones who a responsible for the software they created.
Tell me where in the below it mentions CWP, or even cPanel, aaPanel, etc...
--
SUBJECT:
Multiple Vulnerabilities in PHP Could Allow for Remote Code Execution
OVERVIEW:
Multiple vulnerabilities have been discovered in PHP, the most severe of which could allow for remote code execution. PHP is a programming language originally designed for use in web-based applications with HTML content. Successful exploitation could allow for remote code execution in the context of the affected service account. Depending on the privileges associated with the service account an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Service accounts that are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.
-
Here is the fix to apply to your php.ini
The flaw stems from unsafe handling of the id parameter, which is passed directly into PHP’s unserialize() function without validation.
Attackers can supply malicious serialized PHP objects that trigger arbitrary command execution via system().
This is also blocked by ModSecurity and the OWASP CRS ruleset when correctly configured.
-
Then, by your logic, we should blame the creators of the binary... because they created this digital thing.
Or we should blame the creators of guns... not who use them and for what...
You don't really see how your logic makes no sense?
-
Then, by your logic, we should blame the creators of the binary... because they created this digital thing.
Or we should blame the creators of guns... not who use them and for what...
You don't really see how your logic makes no sense?
I'm placing blame where is belongs - with PHP...
The flaw stems from unsafe handling of the id parameter, which is passed directly into PHP’s unserialize() function without validation.
Attackers can supply malicious serialized PHP objects that trigger arbitrary command execution via system().
So are all the CVE's of this PHP vulnerability.
Servers that where correctly secured where not affected.
-
The RCE with CWP wasn't fixed? And by who?
Or now CWP doesn't uses PHP anymore? By your logic then.... this isn't fixable, since is a "PHP Thing"... so....
-
CWP did not disclosure that. They prefer hide it under a "update", that you don't even know what is. Or do you have a changelog for the versions lauch?
Hire the CWP team, pay them wage and set your rules how they must act. In other case you accept their rules and how they support their product.
If their rules aren't acceptable for you then you need to use another product.
-
Just because the product is free that doesn't mean that security issues should be hidden.
You are literally saying that is better to have a SECURITY ISSUE, in a control panel that many use in they servers, just because "its free". That is NOT a good answer to give, and not a very good idea to have if you manage any kind of server - even more if you have clients in it.
Just because something is "free" doesn't excuse everything. And a security issue is not something that should be hidden.
Anyone that think other wise doesn't know anything about server management and should not be consider a sysadmin - that is a fact in the industry, not something made up by me...
Are you for real? I know that people that use CWP not always have the biggest knowledge about server management and sysadmin in general - and that IS FINE. But have people say that it is better to have security issues hidden than disclosed... is just ridiculous.
And i read that sentence over and over again: "go to other panel". Do you understand that, if everyone does that, CWP just cease to exist, right? The panel that you are supporting here... you are not helping at all with statements like that.
And is not a first thing: Sentora was one example.
In fact, im helping here more that anyone else that comment: transparency MUST be something that should be in EVERY SINGLE action of a project. That is A FACT. If you hide something like a security issue, just because is Free, you are doing it wrong.
Also, @Starburst, kindle stop providing false articles about WAF protection when you clearly don't know what they do. WAF protection is to protect against potential attack vectors - like exploits. You CANNOT apply WAF rules in the CWP - your guide is to apply to the website in the servers, that is pointless (and you know why? Exactly, because the exploit here WAS IN CWP, not in because of the websites in the servers with CWP).
-
And i found out this: https://control-webpanel.com/changelog
The last "update" in what was really changed was in version 0.9.8.1188, released in 13/11/2024.
After that there is updates, but no one knows in what.
And this is the OFFICIAL WEBSITE of CWP. Is not me, is not made up. You CANNOT provide any info about what was updated after 13/11/2024 besides numbers that increase in the CWP panel.
If you don't see any issue in this lack of transparency, just because "is free"... oh boy.
-
CWP isn't maintained by huge number of people. If you want to make CWP more reliable then I recommend you invest more than $1/month into the CWP project or offer some other help for CWP or run your own similar project You will find it is more expensive than $1/month.
The last "update" in what was really changed was in version 0.9.8.1188, released in 13/11/2024.
After that there is updates, but no one knows in what.
And this is the OFFICIAL WEBSITE of CWP. Is not me, is not made up. You CANNOT provide any info about what was updated after 13/11/2024 besides numbers that increase in the CWP panel.
If you don't like it then why do you use CWP and not cPanel/DirectAdmin/Plesk ? Do you like to pay nothing and get everything ? Seems so...
-
You guys seem to like to use something without any transparency about what you are using... And that is ok because it's free. Makes sense I guess ♂️
-
Your arguments reek of being a straw man. Is Cisco's IOS open source? Do you use any of their products $$$$? Do they offer full transparency into their development process? And do their CVE publications present everything factually without any sort of distortion or positive spin?
I am a paying CWP Pro customer and am generally happy with the product. It is NOT open source -- it is IonCube encoded to protect their development efforts -- and I'm okay with that. This is a capitalistic arrangement through and through.
At this point, I'm ready to say, "Go back under your bridge."
-
Is CWP still maintained ?
No it's not that's why you still get updates although the changlogs would be kinda cool if that got updated.
-
Your arguments reek of being a straw man. Is Cisco's IOS open source? Do you use any of their products $$$$? Do they offer full transparency into their development process? And do their CVE publications present everything factually without any sort of distortion or positive spin?
I am a paying CWP Pro customer and am generally happy with the product. It is NOT open source -- it is IonCube encoded to protect their development efforts -- and I'm okay with that. This is a capitalistic arrangement through and through.
At this point, I'm ready to say, "Go back under your bridge."
Yes. Every single example that you give have a public change log.
Do you need examples?
-
My apologies, but I had to chime in.
My Linux experience goes back to 1991. H.J. Lu's boot/root floppy images and less than a few hundred of us on a Usenet group. Then SLS on about 10 floppies if I recall. It's been a long time.
With all due respect to the developers (and some of the "old timers" like me). At minimum, at least a change log needs to be maintained.
Please take it for what it's worth.
With respect,
G.