Jump to content

PHP CVE-2026-109618 and CVE-2026-109619: check your PHP version !


WHMCS Carlos

Recommended Posts

  • WHMCS Staff

Hi everyone,

We emailed licence holders about this on 21 October, the day PHP shipped the fixes, and again on 28 October. The full write-up went on the blog today. The forum is the last place I can put it in front of you, so here it is again.

On 21 October PHP fixed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution. They are in PHP itself, not in WHMCS code, which is why there is no WHMCS patch for them.

That last part is the bit I want to be careful about. "No WHMCS patch needed" does not mean nothing to do. If your server is running an unpatched PHP, your WHMCS install is sitting on it.

Three things, in order:

  1. Check what PHP you are actually on. Utilities > System > PHP Info. Then check that your WHMCS cron runs on the same PHP version as the web server. On a lot of installs it does not, and the cron one gets forgotten.
  2. Update PHP. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Restart PHP-FPM or Apache afterwards, then go back to PHP Info and confirm it took. If you are on 8.1 or older there is no upstream release, so you need a patched package from your host or your distribution. If someone else runs your server, ask them to confirm they have done it. Do not assume.
  3. Update WHMCS. This does not fix the PHP flaws, nothing in WHMCS can. It fixes separate WHMCS security issues, which is its own reason to do it. Current releases are 9.1.0, 9.0.9 and 8.13.7. 8.12 and earlier are end of life and are not getting security fixes.

WHMCS Cloud customers: we patched this automatically, with no downtime. Nothing for you to do.

If you genuinely cannot patch today, set

session.upload_progress.enabled=0

in php.ini or your FPM pool and restart every worker. ini_set() and .user.ini do not count here. On 23 October PHP published a related issue, CVE-2026-115560, and the guidance is to leave that setting off until the next bugfix release even once you are patched.

The full write-up, including which PHP versions each WHMCS release supports and the rest of the mitigations, is here:
https://blog.whmcs.com/133799/php-cve-2026-109618-and-cve-2026-109619-our-response-and-what-whmcs-customers-need-to-do

If something specific is blocking you from patching, open a ticket, or reply here and I will pick it up.

Carlos
 

Link to comment
Share on other sites

Worth adding for anyone on cPanel/WHM, because the web-vs-cron mismatch Carlos mentions is very common there:

1. PHP Info in WHMCS only shows the version serving the admin area, which on cPanel is whatever MultiPHP Manager has set for that domain. The cron uses whatever binary the cron line calls. If your line is just php -q /home/user/crons/cron.php, that's the server's system default PHP, which can easily be a different ea-php version. Check with crontab -l -u youruser, then run that exact binary with -v. The clean fix is to call the version explicitly, for example /opt/cpanel/ea-php83/root/usr/bin/php -q /home/user/crons/cron.php, matching what MultiPHP Manager shows for the WHMCS domain.

2. Check every installed version, not just the one WHMCS uses today. rpm -qa | grep -E 'ea-php8[0-9]-php-(cli|fpm)' lists the build of each EasyApache PHP on the box. Update them with dnf update 'ea-php*' (yum on older systems) once the fixed builds are available, then restart FPM with /scripts/restartsrv_apache_php_fpm. On CloudLinux, PHP Selector's alt-php versions are separate packages (rpm -qa | grep alt-php8), and on LiteSpeed check the lsphp packages too and restart with /usr/local/lsws/bin/lswsctrl restart.

3. If you need the session.upload_progress.enabled=0 stopgap, the easiest place on cPanel is WHM > MultiPHP INI Editor > Editor Mode for each PHP version, then restart PHP-FPM. Bear in mind a per-domain FPM pool override can still win, so verify instead of assuming.

4. Verify both sides afterwards: PHP Info inside WHMCS for the web side, and for the cron run the same binary your cron uses with -i | grep -E 'PHP Version|upload_progress'. Both should show the patched version and the setting you expect.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated