Action Required: Critical worldwide PHP security update (php2shell), please upgrade PHP

3 posts by 2 authors in: Forums > CMS Builder
Last Post: Friday at 2:56pm (RSS)

Hi everyone,

Just a heads up, you may have already heard about this. This week, PHP released fixes for two critical security issues called php2shell (CVE-2026-109618 and CVE-2026-109619). They let someone run their own code on your server, with no login, just by sending a request to a PHP page. Attack attempts have already been reported.

This is a bug in PHP itself. It has nothing to do with CMS Builder or any other website software. If your server runs PHP and has even one PHP file accessible from the web, it's affected, no matter what else is on it.

This is the most serious PHP security issue we've seen in over 10 years.

What to do: upgrade PHP to one of these versions or newer:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

PHP 8.1 and older are end-of-life, so there's no official release with this fix. The PHP team published fix code for 7.4, 8.0, and 8.1 for people who build PHP themselves, and some hosts and support vendors provide patched versions. If you're on 8.1 or older, upgrade to 8.2 or newer, or check with your host to confirm you're running a patched version.

If you're on shared hosting or aren't sure what you're running, check with your hosting provider. You can see your PHP version in CMS Builder under: Admin → General Settings → Server Info

If you manage your own server: Plesk and cPanel each run their own separate copy of PHP for the control panel, and updating your website PHP doesn't update it. Make sure you're running the latest control panel update, and restart your server after you update.

More details are on the PHP site: https://www.php.net/archive/2026.php#2026-10-21-5

Let me know any questions.

Thanks!

Dave Edis - Senior Developer
interactivetools.com

By KennyH - Friday at 12:22pm

Thanks for the heads-up, Dave. One addition for everyone: PHP published a follow-up advisory on October 23, and it affects CMS Builder sites more directly than the original two did.

What we did for php2shell

We manage our own server, and all of our CMS Builder sites are now patched:

We updated PHP to 8.3.36.
We moved everything that was still on PHP 8.1 to 8.3: webmail, phpMyAdmin, our internal APIs and a few older sites. There will never be an official 8.1 release with this fix, so moving was the only real option.
We removed the old PHP versions (7.3, 7.4 and 8.1) from the server completely, so nothing can fall back to them.
We updated the control panel software and the rest of the server stack.

If you run DirectAdmin: phpMyAdmin and Roundcube run on the server's own PHP. If an old PHP version is still installed for them, they're still exposed even after your websites are updated.

Attack attempts are real. Cloudflare reported millions of exploit attempts within a day of the announcement, so please don't put this off.

The new one: CVE-2026-115560 (October 23)

The PHP releases Dave listed do not fix this issue. PHP rates it unlikely, and there's no emergency release. The fix will come in the next regular release. A site is exposed when all of these are true:

The server's php.ini setssession.serialize_handlertophp_binaryorphp_serialize.
The application changes it tophpwithini_set()before callingsession_start().
Session upload progress is on, which is PHP's default.

CMS Builder always does #2. In webadmin/lib/SessionHandler.php, register() calls ini_set('session.serialize_handler', 'php') before the session starts. That's harmless on a default server, where the handler is already php. But on a host whose php.ini uses php_serialize or php_binary, a CMSB site meets all three conditions.

What to do (one setting)

Set this in php.ini or in your PHP-FPM pool config, then restart PHP:

session.upload_progress.enabled = 0

Don'tset it withini_set()or.user.ini. PHP says it has to apply before the request is processed.
This is also one of PHP's listed mitigations for CVE-2026-109619, one of the two php2shell flaws. If you already turned it off for that, you're covered.
To check your server, look atsession.serialize_handlerandsession.upload_progress.enabledin phpinfo (CMS Builder: Admin → General Settings → Server Info).
On shared hosting, ask your host to turn it off.

We turned it off server-wide on October 23. The only side effect we've seen is that phpMyAdmin's import progress bar no longer shows.

Dave, would it make sense for CMSB to skip that ini_set() when the server's handler isn't already php? Or Server Info could flag a non-default handler while upload progress is on. Either would protect anyone whose host doesn't make the change.

Links:

PHP's advisories:https://www.php.net/archive/2026.php
Tenable's FAQ on php2shell:https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote

Thanks,

Kenny H

By Dave - Friday at 2:56pm

Hi Kenny,

Thanks for posting this, and for the detailed write-up. Your post was actually the first place I saw it.

I've confirmed it on php.net. Their Oct 23 notice says the Oct 21 releases don't fix this one. The fix and the full advisory will come in PHP's next regular release, and until then they haven't published how the issue works: https://www.php.net/archive/2026.php#2026-10-23-1

Here's a patch anyone can apply now to be extra safe, and we'll include it in the next release as well.

In cmsb/lib/SessionHandler.php, search for this line:

ini_set('session.serialize_handler', 'php');

And replace it with this:

// CVE-2026-115560: temporary workaround until servers install PHP's fix.
// Reference: https://www.php.net/archive/2026.php#2026-10-23-1
// Attackers could potentially run code, but only when all three of these are true:
// - phpinfo() shows session.serialize_handler as php_serialize or php_binary (not the default, php)
// - the line below switches it to php
// - session.upload_progress.enabled is on, which is PHP's default
// Once most servers run a PHP version that fixes this CVE, delete this note and uncomment the line below.
//ini_set('session.serialize_handler', 'php'); // Use PHP's built-in session serialization

On servers where session.serialize_handler isn't set to php, existing sessions won't load after this change, so users will need to log in again once. Servers using PHP's default won't notice any difference. Versions before v3.67 don't have this line and don't need the patch.

Setting session.upload_progress.enabled = 0 server-wide, as you described, is still a good idea. It also covers one of the php2shell issues on servers that haven't been updated yet.

Thanks again for the heads up! Let me know any questions or more news.

Dave Edis - Senior Developer
interactivetools.com