Update your PHP ASAP 🚨

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 used the instructions from the linked guide.

I originally had PHP 8.3.33 on the server, so I first I added 8.5.9 directly through the panel. After that, I followed the guide's instructions using Claude AI to perform the upgrade of 8.5.9 to 8.5.12. Everything went smoothly without a single error, and the server is now running php 8.5.12. I've successfully "migrated" all my websites from version 8.3.33 to 8.5.12.

As for CWP, this is really negligent on their part. They will probably, as always, release a silent update in the background weeks from now. It's frustrating that 8.3.33 is still what they consider current when it's already an outdated build like 8.3.34, 8.3.35 and 8.3.36.

This just isn't affecting CWP.

This RCE bug goes back 12 years, and is in allot of software.

cPanel, Plesk, Froxlor just to name a few other panels affected.

ANY system running PHP.

AlphaGNU has a solution, but there is a problem with the Sodium extension not working.

If you have a WordPress theme that uses it, it will crap out WordPress completely. :/

CWP uses PHP 7.x internaly.
All the other panels are on updated versions -and most have already patch their versions...
This affects CWP and Will continue since there is no backport update to EOL versions.

The public PHP version,used in the accounts, is of course vulnerable until the Patch - that in most have already been deployed.
CWP still doesnt,só you must update manually using some thing like the alphagnu script

Update your CWP to the lastest and you will get the new PHP versions. From 8.2 to most recent ones.

Update your CWP to the lastest and you will get the new PHP versions. From 8.2 to most recent ones.

Good then

But there is still the internal cwp PHP that is 7.x...

Yes, after the latest CWP update, the PHP-FPM Selector now offers the patched versions: **8.3.36, 8.4.27 and 8.5.12**.

However, **PHP Version Switcher still has an issue with PHP 8.4 and 8.5**, showing the error `Missing dependencies found: zlib → zlib-dir`.

On AlmaLinux 8, both `8.4.ini` and `8.5.ini` reference `include=zlib-dir`, but neither defines the corresponding `[zlib-dir]` section. Hopefully this can be fixed in an upcoming update.

**My main concern, however, is CWP's internal PHP 7.2.30**, which is still being used by the panel itself.

Even if we update all our website PHP versions, the panel continues to rely on this outdated and unsupported PHP runtime.

Edit:
Update — PHP-FPM 8.4 and 8.5 builds fail to start (AlmaLinux 8 )

Unfortunately, I've encountered another issue after the latest CWP update.

I tried compiling PHP-FPM **8.4.27 and 8.5.12** using the official CWP PHP-FPM Selector on AlmaLinux 8.

Both builds appear to complete successfully, showing:

```
Build Completed
###################
Error:Can't add notification!
```

However, neither PHP-FPM service starts.

Both versions fail with the same fatal error:

```
PHP Fatal error: Unable to start pcre module in Unknown on line 0
```

The services exit with status 254.

I also tested both PHP binaries directly:

```
/opt/alt/php-fpm84/usr/bin/php -n -v
/opt/alt/php-fpm85/usr/bin/php -n -v
```

Both fail with `Unable to start pcre module`, even with `-n` (without loading php.ini).

PHP 8.4 additionally reports a duplicate `mbstring` warning, but the fatal PCRE error is common to both versions.

So, although the patched versions are now available in the selector, **the resulting PHP installations are unusable on my server**.

Has anyone else experienced this issue with the latest CWP PHP-FPM builds on AlmaLinux 8?

Could the CWP team please investigate the compilation process?

Thanks!

Issue identified and resolved (AlmaLinux 8 / CWP PHP-FPM Selector)

After the latest CWP update, this issue affects **not only the new PHP versions (8.4.27 and 8.5.12), but also previously working PHP versions when rebuilt**, including PHP 8.4.24.

PHP-FPM fails to start with:

`PHP Fatal error: Unable to start pcre module in Unknown on line 0`

The issue was related to the `--with-external-pcre` build option and the external PCRE2 library.

How solved:

Edit:

`/usr/local/cwpsrv/htdocs/resources/conf/el8/php-fpm_selector/8.4.ini`

Under `[pcre]`, change `default=1` to `default=0`.

Then rebuild PHP-FPM 8.4.27 with the external PCRE option disabled in CWP.

Result: PHP-FPM 8.4.27 starts successfully using bundled PCRE2 10.44, with all previously installed extensions preserved.

This workaround was tested successfully with PHP 8.4.27 on AlmaLinux 8. PHP 8.5.12 has not yet been retested with this change.

I was able to update PHP through the PHP-FPM selector and the PHP Version Switcher.

First i had to force update CWP with this command: sh /scripts/update_cwp
After this the new version appears in the dropdown lists.

To compile v8.5.12 in "PHP Version Switcher" I had to disable the zlib extension as it was complaining about a missing dependency on zlib-dir (which is not available in the list of extensions)

The new CWP appears to have the patched versions... but lets not forget that the Internal CWP PHP still uses the 7.x, that is NOT patched and never will be.

Until a CWP update silently update the internal PHP to a 8.2+ version, is RECOMMENDED to close all the ports used by the panel.

I've closed those ports a long time ago. The CWP and SSH ports are only accessible from IPs that are entered in the allowlist. I run an hourly cronjob that checks for certain dns A records and it compares the value with the values in csf allowlist. It appends the new IP to the allowlist when a dns record changes (and then restarts the CSF). This way i cannot lock myself out as the dns record always points to my home IP through ddns.

PHP-FPM issue reproduced on TWO servers (AlmaLinux 8 / CWP8 )

I experienced the same issue on **two separate production servers.

After the initial PHP-FPM update failed, even reinstalling an older PHP version didn't help. Compilation completed, but PHP-FPM failed to start.

After investigating, I found two issues:

1. PCRE:** The `--with-external-pcre` option caused `Unable to start pcre module`. Setting `[pcre] default=0` in the PHP-FPM Selector's `8.4.ini` and recompiling PHP fixed the startup issue.

2. mbstring:** CWP uses an external `mbstring.sh` installation script. I disabled it (`[mbstring] default=0`) and manually compiled `mbstring.so` from the official PHP source.

Both servers are now running PHP-FPM 8.4.27 successfully, with all required extensions loaded and both websites working correctly.

Since this happened on TWO servers, I believe the CWP developers should review the PHP-FPM Selector's PCRE and mbstring configuration.

I was able to update PHP through the PHP-FPM selector and the PHP Version Switcher.

First i had to force update CWP with this command: sh /scripts/update_cwp
After this the new version appears in the dropdown lists.

To compile v8.5.12 in "PHP Version Switcher" I had to disable the zlib extension as it was complaining about a missing dependency on zlib-dir (which is not available in the list of extensions)