Control Web Panel
WebPanel => PHP => Topic started by: djprmf on October 20, 2026, 10:46:42 PM
-
Two critical PHP vulnerabilities, both rated 9.2 (CVSS v4.0)
"All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available."
https://www.php.net/archive/2026.php#2026-10-20-1
-
PHP2Shell
https://arstechnica.com/security/2026/10/php-maintainers-tell-web-devs-to-prepare-themselves-for-critical-security-patches/
-
and, if you haven't already, now may be a good time to change to:
https://www.alphagnu.com/topic/633-standalone-cwp-php-cli-build-manager-build-php-7485-php-fpm-selector-switcher-and-pie-extensions/
-
This is urgent: Could someone from the CWP team let us know when updated PHP packages will be released?
For example, PHP 8.3 is currently at version 8.3.35, but CWP only offers 8.3.33.
It is critical that CWP makes the latest upstream PHP releases available promptly.
-
There are some suggested mitigation actions to take while we wait for new PHP versions
Update php.ini with (hopefully you don't use it)
session.upload_progress.enabled = Off
update .htaccess with
RewriteEngine On
#PHP2SHELL
RewriteCond %{REQUEST_METHOD} ^POST$ [NC]
RewriteCond %{HTTP:Content-Type} ^[[:space:]]*multipart/form-data([;,[:space:]]|$) [NC]
RewriteRule ^ - [F,L]
Add custom WAF rule
# Detect and block the PHP2Shell upload progress exploit vector
SecRule ARGS_POST_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS" \
"id:10033,\
phase:2,\
deny,\
status:403,\
log,\
severity:CRITICAL,\
t:none,\
msg:'PHP session upload progress field exploit attempt (PHP2Shell CVE-2026-109618/109619)'"
-
There are some suggested mitigation actions to take while we wait for new PHP versions
Update php.ini with (hopefully you don't use it)
session.upload_progress.enabled = Off
update .htaccess with
RewriteEngine On
#PHP2SHELL
RewriteCond %{REQUEST_METHOD} ^POST$ [NC]
RewriteCond %{HTTP:Content-Type} ^[[:space:]]*multipart/form-data([;,[:space:]]|$) [NC]
RewriteRule ^ - [F,L]
Add custom WAF rule
# Detect and block the PHP2Shell upload progress exploit vector
SecRule ARGS_POST_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS" \
"id:10033,\
phase:2,\
deny,\
status:403,\
log,\
severity:CRITICAL,\
t:none,\
msg:'PHP session upload progress field exploit attempt (PHP2Shell CVE-2026-109618/109619)'"
This can help, but have been already confirmed that do NOT fix the vulnerability.
The only fix is update the PHP when the new version is released.
This is urgent: Could someone from the CWP team let us know when updated PHP packages will be released?
For example, PHP 8.3 is currently at version 8.3.35, but CWP only offers 8.3.33.
It is critical that CWP makes the latest upstream PHP releases available promptly.
From the history... you can wait several weeks. 🤷♂️
-
And its on 🚨
https://www.php.net/archive/2026.php#2026-10-21-5
CWP still doesn't have the update
-
I don’t want to speak out of turn again, but I have some test VPS instances running the KeyHelp and HestiaCP panels, where security patches have already been applied. With CWP, not only are updates missing, but it’s not even possible to upgrade to PHP versions 8.2 or 8.3—and here I’m referring specifically to what kandalf mentioned: "For example, PHP 8.3 is currently at version 8.3.35, but CWP only offers 8.3.33."
How are you guys dealing with this situation? We haven’t had any meaningful updates or changelog information from CWP since version 1.12.
Is the CWP team on vacation, or are they even aware of the PHP version issue? :))))
-
Some info would be nice.
I pulled all CWP servers offline waiting for an update. But I can't do that for very long.
Another concern is the CWP internal PHP version, I think one of my CPW servers still runs on 7.1 internaly.
-
Some info would be nice.
I pulled all CWP servers offline waiting for an update. But I can't do that for very long.
Another concern is the CWP internal PHP version, I think one of my CPW servers still runs on 7.1 internaly.
Hi,
I have a question regarding the PHP version used by CWP internally.
Did you manage to upgrade the internal PHP version used by CWP itself from PHP 7.1 to PHP 8.x, so that the entire CWP panel and its internal services run on PHP 8.x? Or did you only change the PHP version used by websites and services such as Roundcube, while CWP itself still runs on PHP 7.1?
I noticed that some internal CWP configuration files still reference paths such as /usr/local/cwp/php71/, even when PHP 8.x versions are installed.
Could you please clarify what you changed and whether it is possible to upgrade CWP's internal PHP version safely?
Thank you!
-
Currently, there is nothing that can be done, only the CWP team can update on this - and if history told us something is that, probably, the reply will be too little, too late.
Every single CWP server is currently vulnerable. And CWP team will only deploy an update several days (or weeks) after - leaving a BIG gap to every server be attacked.
This is a PHP vulnerability, but CWP is COMPLETLY responsible for the damage that is being done from the lack of information.
-
Let’s hope the security solution protecting our servers will block attacks this time as well.
It’s really disappointing to see CWP falling behind when it comes to keeping the control panel up to date and secure. I’ve raised these concerns repeatedly on the forum, and I apologize if I sound frustrated, but it’s becoming increasingly difficult to remain patient.
As I’ve mentioned before, I have 25 CWP Pro servers running in production, and I’ve been using CWP for almost 10 years now, if I remember correctly. I genuinely want to see the project succeed, which is why these security issues and delays are so frustrating.
-
It’s really disappointing to see CWP falling behind when it comes to keeping the control panel up to date and secure. I’ve raised these concerns repeatedly on the forum, and I apologize if I sound frustrated, but it’s becoming increasingly difficult to remain patient.
As I’ve mentioned before, I have 25 CWP Pro servers running in production, and I’ve been using CWP for almost 10 years now, if I remember correctly. I genuinely want to see the project succeed, which is why these security issues and delays are so frustrating.
Same feeling.
If you have, use Cloudflare. They have released a WAF rule to protect - doesn't solve the issue, since is needed a PHP update, but can protect something for Cloudflare enable websites.
-
I contacted support about this and their response was -
"Hello,
we are working with PHP issue. It will be fixed in a future release.
Regards,
Igor S."
My guess is sadly no time soon. I'm already looking into migration options away from CWP.
-
If you have, use Cloudflare. They have released a WAF rule to protect - doesn't solve the issue, since is needed a PHP update, but can protect something for Cloudflare enable websites.
If I'm right the Cloudflare WAF is only available with enterprise plans, not on the free tier?
-
If you have, use Cloudflare. They have released a WAF rule to protect - doesn't solve the issue, since is needed a PHP update, but can protect something for Cloudflare enable websites.
If I'm right the Cloudflare WAF is only available with enterprise plans, not on the free tier?
No. The mitigation is for free and paid accounts.
-
From another thread on here, this is an absolute lifesaver - a standalone php builder that works alongside CWP but allows you to install any version you want (include more uptodate versions that CWP hasn't added to their repo yet)
I just installed it on my AlmaLinux 9.8 server, had it build php-fpm 8.5.12
It upgraded it in place for CWP, the client site works perfectly too.
https://www.alphagnu.com/topic/633-standalone-cwp-php-cli-build-manager-build-php-7485-php-fpm-selector-switcher-and-pie-extensions/
-
From another thread on here, this is an absolute lifesaver - a standalone php builder that works alongside CWP but allows you to install any version you want (include more uptodate versions that CWP hasn't added to their repo yet)
I just installed it on my AlmaLinux 9.8 server, had it build php-fpm 8.5.12
It upgraded it in place for CWP, the client site works perfectly too.
https://www.alphagnu.com/topic/633-standalone-cwp-php-cli-build-manager-build-php-7485-php-fpm-selector-switcher-and-pie-extensions/
That works for the public PHP - and is great.
But:
1- Is NOT a official tool from CWP
2- Doesn't fix the issue with the internal PHP that CWP uses.
-
Absolutely correct.
The internal PHP version is 7.1 or 7.2, there is no update available to patch such an old version I don't believe.
-
The response from the CWP "team" about this issue, in ticket:
"Thanks for writing in.
We're aware of this and the patch will be very soon. Kindly standby for further update.
Please do not hesitate to contact me, should you need any additional assistance or have further queries. I remain at your service."
The same generic and vague response every time there is a security issue. Every single panel - paid or not paid - have already provide at least **some** info about what they are doing.
CWP have almost every single server where he is vulnerable.
This will have repercusions - lets remind that EU, where CWP is providing they services - have severe fines and rules about cybersecurity. Everytime there is a security incident, CWP doesn't take responsability, or even worst, try to hide it and pass it as a "silent update".
CWP, as a company, have responsabilities - and no, the fact that LINANTO LLC (the main company) is in Georgia doesn't take responsability of follow the EU rules (where is also providing the CWP and other services).
===
For now, to anyone:
1- Use the "Standalone CWP PHP CLI Build Manager" to update the PHP for all the configurations:
https://www.alphagnu.com/topic/633-standalone-cwp-php-cli-build-manager-build-php-7485-php-fpm-selector-switcher-and-pie-extensions/
Is easy to follow and install.
Update ALL the PHP versions that are active, if you have more than one. Make sure to use the correct patched versions:
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
All the older versions are EOL, and don't have a patch. If you are still using them, UPDATE NOW to a more recent version.
2- About the CWP panel itself, there is nothing that can be done to update the internal PHP. Is currently vulnerable, and it WILL be attacked - have passed already several hours, so expect bots and malicious traffic exploiting the vulnerability.
As recommendation: CLOSE NOW the CWP ports at the firewall level (2030,2031,2082,2083,2086,2087,2304).
Yes, you lose the CWP panel access, but is better than a server attacked due the incompetence of the CWP team.
3- Wait for the CWP update... And bet with me: will be another silent update, where no one from CWP team provide any info or will be again very vague, and will come several DAYS after. Too little, too late.
Since this will probably need several changes to the internal CWP panel PHP, and to the code within, i can guess will not be a easy task. CWP have been negleting the internal PHP for years, and NOW is paying the price of that... despite all the warnings of the community and not the "devs-wannabe".
-
I use prestashop 8.2, i can't go over 8.1 PHP, and no patch for this branch ??
-
I use prestashop 8.2, i can't go over 8.1 PHP, and no patch for this branch ??
There is no patch for versions under the 8.2 (they are EOL).
You need to update your installation or make it compatible with recent versions.
-
I have a alma linux 9 vps, and out of despair i asked Gemini how can i switch to php 8.3.36 and it gave me these directions. I tried it and it works, so use it at your own risk if you will.
1) go to
/usr/local/cwpsrv/htdocs/resources/conf/el9/php_switcher/versions.ini
2) add
version[]=8.3.36
(right over version[]=8.3.33)
3) open terminal
cd /usr/local/src
wget https://www.php.net/distributions/php-8.3.36.tar.gz
4) Go to CWP version switcher and select 8.3.36 and compile
5) It will fail because cwp can't find the 8.3.36 file, so you go to
/usr/local/src/php-rebuild.sh
6) Open it in file editor and change the
# PHP Sources
section all the way until the ioncube line with this
# PHP Sources Check Overridden for Local File
if [ -f "/usr/local/src/php-$version.tar.gz" ]; then
PHPDOWNLOADVERCWP=99999999
phpsource="file:///usr/local/src/php-$version.tar.gz"
else
PHPDOWNLOADVERCWP=`wget -q -S --spider "https://www.php.net/distributions/php-$version.tar.gz" -O - 2>&1 | sed -ne '/Content-Length/{s/.*: //;p}'`
if [ -z "$PHPDOWNLOADVERCWP" ]; then
PHPDOWNLOADVERCWP=0
fi
phpsource="https://www.php.net/distributions/php-$version.tar.gz"
fi
# Check if file size is over 8MB
if [ $PHPDOWNLOADVERCWP -ge 8000000 ]; then
echo "Valid archive found, proceeding..."
else
echo "Failed to Download PHP version $version!"
exit 1
fi
7) By the way in the file above you should see these lines (because we attempted to compile 8.3.36 from GUI)
# CONFIGURE MIRRORS HERE
version=8.3.36
If you don't see this version there (8.3.36) for any reason, also change it to 8.3.36
8 ) After this you open terminal and
cd /usr/local/src
sh php-rebuild.sh
9) Once it finishes compiling
systemctl restart httpd
10) You check with
php -v
It should show 8.3.36
Worked for me. So I don't know if this is the right way to go, but something needs to be done while CWP is lagging behind.
By the way, when you edit files in File Manager, sometimes a syntax error happens due to new lines being removed or whatever, in which case you need to install this thing called dos2unix, and then run dos2unix /path/to/file this fixes the problem.
-
I have a alma linux 9 vps, and out of despair i asked Gemini how can i switch to php 8.3.36 and it gave me these directions. I tried it and it works, so use it at your own risk if you will.
Just use the AlphaGNU script.
Is compatible with CWP and not a "AI made" solution that could work... but also can break many things or in the future.
http://forum.centos-webpanel.com/php/update-your-php-asap-128680/msg54477/#msg54477
-
I can't upgrade easyly to prestashop 9, it need a full developpement for this migration, template etc.....
-
Anything non-CWP origin can break things in the future.
No need to fixate on a single alternative. This solution is simply using the official php file to make the update, it's pretty straight forward.
I have a alma linux 9 vps, and out of despair i asked Gemini how can i switch to php 8.3.36 and it gave me these directions. I tried it and it works, so use it at your own risk if you will.
Just use the AlphaGNU script.
Is compatible with CWP and not a "AI made" solution that could work... but also can break many things or in the future.
http://forum.centos-webpanel.com/php/update-your-php-asap-128680/msg54477/#msg54477