PHP security advisory: Critical remote code execution vulnerabilities, update now (21 Oct 2026)

Comments

• Maounique Host Rep, Veteran

  October 24

  Guys, is this unexpected? Really?
  The world is running on billions of lines of code and on weird setups of mix-match stuffs, so this will keep happening for everything. Eyeballs can get tired from auditing that codebase, the AI does not.
  This is good, though, now everyone knows about the exploits and they will be patched much faster instead of being sold to 3 letter agencies and Israeli "security" firms.
  I very much prefer this new world in which the access to exploits is "democratic".

  Thanked by 4MannDude angstrom zed MaxLagomorph
• noob404 Member

  October 24

  @dustinc said:
  As a heads up - unlike a traditional PHP update, CloudLinux backported the fix into its php packages. This means the version number may be below PHP's, despite being patched.

  How to confirm the fix

  Our packages carry the fix as a backport, so their version numbers stay below PHP's (for example, ea-php84 is 8.4.26, not 8.4.27). Look for the CVE IDs in the package changelog instead:
  rpm -q ea-php84-php-cli --changelog | grep -E "CVE-2026-(109618|109619)"

  I was scratching my head yesterday when I realsied despite this huge vulnerability, Ubuntu 26.04 repo was still supplying the older 8.5.4. Then, I realised, it had the patch.
• forest Member

  October 24

  @Maounique said: I very much prefer this new world in which the access to exploits is "democratic".

  It's definitely beneficial in the long run, but in the short term, it's a bit frantic and painful.

  Thanked by 1Maounique
• Maounique Host Rep, Veteran

  October 24 edited October 24

  @forest said: It's definitely beneficial in the long run, but in the short term, it's a bit frantic and painful.

  There is another benefit, people will finally realize that whatever is connected is: 1. not private and 2. not secure. Encrypt and backup everything, from storage to communication, a hard to break setup is possible these days, a reliably resilient one pretty easy and it is also free, software wise.
  People over 50 like me remember how much it used to cost to run even basic setups back in the day...
  @forest is right though, this comes at a very high cost regarding your time. For three days I barely slept.

  Thanked by 2forest MannDude
• Tony40 Member

  October 25

  PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches

  PHP has warned of another way an attacker could run code on a web server, two days after it shipped emergency fixes for the critical PHP2Shell flaws.

  The new issue, assigned CVE-2026-115560, affects only web applications configured in an unusual way, and PHP considers it an unlikely risk.

  The project is not issuing an emergency fix for it. Instead, it recommends turning off a feature called session upload progress until a fix is available in the next routine release.

  The warning came in a short informational advisory published on October 23. It follows the October 21 emergency release that fixed two critical PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, which let an attacker without an account run code on a server. Those ....

  https://thehackernews.com/2026/10/urgent-php-warns-of-another-unpatched.html
• angstrom Moderator, Veteran

  October 25

  @Tony40 said:
  PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches

  Okay, but this has already been mentioned twice in this thread:

  • https://lowendtalk.com/discussion/comment/4895190/#Comment_4895190
  • https://lowendtalk.com/discussion/comment/4895363/#Comment_4895363

  Thanked by 1borkedascii
• woinokiz Member

  October 25

  @woinokiz said:

  @forest said:

  @woinokiz said:
  Php, java , node ,

  What's remaining now?

  We need to go back to Perl.

  @woinokiz said:

  @Jord said:

  @woinokiz said:
  Php, java , node ,

  What's remaining now?

  We're going to hell in a handcart

  Ok I just got info that Ruby also got involved

  Python also got involved

  Tailscale also joined the race
• Jord Moderator, Host Rep, Veteran, Megathread Squad

  October 25

  @woinokiz said:

  @woinokiz said:

  @forest said:

  @woinokiz said:
  Php, java , node ,

  What's remaining now?

  We need to go back to Perl.

  @woinokiz said:

  @Jord said:

  @woinokiz said:
  Php, java , node ,

  What's remaining now?

  We're going to hell in a handcart

  Ok I just got info that Ruby also got involved

  Python also got involved

  Tailscale also joined the race

  Fun
• forest Member

  October 26 edited October 26

  I'm hoping the end result of this AI bug apocalypse is that it will improve just enough that we can give it a codebase and a prompt and ask it to formally verify it and it will actually do so. If that happens, we'll quite literally live in a world completely free of software bugs. And if that does happen, maybe we can ditch Rust and just use formally-verified C.

  Thanked by 3rpqu avsisp darkimmortal
• hyperblast Member

  October 26

  aibugcalypse
• avsisp Member, Patron Provider

  October 26 edited October 26

  For any hosts on Debian or Ubuntu like us, running your own website on that, not on WHM/Cpanel, here's a tip:

  • crontab -e
  • add a line:
    "30 1,13 * * * apt-get update && apt-get upgrade -y && systemctl restart apache2 && systemctl restart mysqld && rm /var/log/*.gz /var/log/*.0 /var/log/*/*.gz /var/log/*/*.0"

  The rm commands are just clearing useless wasted log space - the rest before it being the important part that would have saved your bacon here. The rest updates everything and restarts apache2 + mysql (very low downtime, ms - not even a second). If you're on nginx, change it to nginx and add php-fpm also, etc.

  A huge shoutout also to Sury - lifesaver here and we've been using only him on all PHP endpoints for a long time - https://deb.sury.org/ -> his repos were updated for amd64 almost immediately.
• tasfin Member

  October 26

  Glad to see most hosts patched quickly. A quick reminder for WHMCS operators: restart PHP-FPM/LSAPI after updating. Then check that the PHP version actually serving WHMCS is patched, and patch the CLI PHP your cron runs on too. On multi-PHP setups, those two are often different versions.

  Thanks to Ondřej and the distro maintainers for the fast backports. 🙏

  Thanked by 2georgedatacenter avsisp
• Mynymbox Member, Host Rep

  October 27

  @avsisp said:
  For any hosts on Debian or Ubuntu like us, running your own website on that, not on WHM/Cpanel, here's a tip:

  • crontab -e
  • add a line:
    "30 1,13 * * * apt-get update && apt-get upgrade -y && systemctl restart apache2 && systemctl restart mysqld && rm /var/log/*.gz /var/log/*.0 /var/log/*/*.gz /var/log/*/*.0"

  The rm commands are just clearing useless wasted log space - the rest before it being the important part that would have saved your bacon here. The rest updates everything and restarts apache2 + mysql (very low downtime, ms - not even a second). If you're on nginx, change it to nginx and add php-fpm also, etc.

  A huge shoutout also to Sury - lifesaver here and we've been using only him on all PHP endpoints for a long time - https://deb.sury.org/ -> his repos were updated for amd64 almost immediately.

  Why not use the Debian & Ubuntu unattended upgrade function? Super easy to use

  Thanked by 2tentor darkimmortal
• zed Veteran

  October 27

  @Mynymbox said:

  @avsisp said:
  For any hosts on Debian or Ubuntu like us, running your own website on that, not on WHM/Cpanel, here's a tip:

  • crontab -e
  • add a line:
    "30 1,13 * * * apt-get update && apt-get upgrade -y && systemctl restart apache2 && systemctl restart mysqld && rm /var/log/*.gz /var/log/*.0 /var/log/*/*.gz /var/log/*/*.0"

  The rm commands are just clearing useless wasted log space - the rest before it being the important part that would have saved your bacon here. The rest updates everything and restarts apache2 + mysql (very low downtime, ms - not even a second). If you're on nginx, change it to nginx and add php-fpm also, etc.

  A huge shoutout also to Sury - lifesaver here and we've been using only him on all PHP endpoints for a long time - https://deb.sury.org/ -> his repos were updated for amd64 almost immediately.

  Why not use the Debian & Ubuntu unattended upgrade function? Super easy to use

  rm the logs via cron seems ghetto too, just configure the logging how you want it. system already removes the oldest though so..

  Thanked by 1tentor
• Mynymbox Member, Host Rep

  October 27

  @zed said:

  @Mynymbox said:

  @avsisp said:
  For any hosts on Debian or Ubuntu like us, running your own website on that, not on WHM/Cpanel, here's a tip:

  • crontab -e
  • add a line:
    "30 1,13 * * * apt-get update && apt-get upgrade -y && systemctl restart apache2 && systemctl restart mysqld && rm /var/log/*.gz /var/log/*.0 /var/log/*/*.gz /var/log/*/*.0"

  The rm commands are just clearing useless wasted log space - the rest before it being the important part that would have saved your bacon here. The rest updates everything and restarts apache2 + mysql (very low downtime, ms - not even a second). If you're on nginx, change it to nginx and add php-fpm also, etc.

  A huge shoutout also to Sury - lifesaver here and we've been using only him on all PHP endpoints for a long time - https://deb.sury.org/ -> his repos were updated for amd64 almost immediately.

  Why not use the Debian & Ubuntu unattended upgrade function? Super easy to use

  rm the logs via cron seems ghetto too, just configure the logging how you want it. system already removes the oldest though so.

  Right. I'm not using any of this ways on production environments since I want to see what's going on 😀

  Thanked by 1oloke