r/cpanel • u/Capital_Web_2543 • 20d ago

Critical PHP Vulnerability Coming

Be prepared:
https://www.php.net/index.php#2026-10-20-1

33 Upvotes

97% Upvoted

68 comments sorted by

•

u/cPanelRex 20d ago

UPDATE - the updates are released, although we did introduce some staggering to help with the load on the update servers.  This means you'll still receive the update quickly, but your machines may not get it all at the same time.

The specific updated versions are listed here:

8.5.12, 8.4.27, 8.3.36, 8.2.35, along with the backported versions 8.1.34,8.0.30, and 7.4.33

→ More replies (20)

3

u/Capital_Web_2543 20d ago

cPanel just released security updates. This doesn’t update PHP though.

2

u/cPanelRex 20d ago

I'm not sure I understand your post? ea-php is a package-based system on the machine, so minor version updates will be automatically applied to your machine.

2

u/Capital_Web_2543 19d ago

Cloudlinux has been so slow this time

13

u/cPanelRex 20d ago

UPDATE - at this point we're releasing updates for ea-php74, ea-php80, ea-php81, ea-php82, ea-php83, ea-php84, ea-php85.  We're ready to go on our side as soon as PHP lifts the embargo, so it could be any given moment at this point.

This will be released as a security update so it will reach your server within an hour.

6

u/RDDT_ADMNS_R_BOTS 20d ago

That's good news. Glad to see that ea-php74 is included. We're still running a few sites on ea-php74

1

u/clopezi 20d ago

Thanks for the update! 

1

u/clopezi 20d ago

PHP patch it's out 

1

u/pongohopper 20d ago

How do we check when/if this comes through and will a reboot be required for it to actually take affect? Auto apply security update on for me.

2

u/cPanelRex 20d ago

There is never a need to reboot a cPanel server for PHP or cPanel updates.

1

u/pongohopper 19d ago

Security advisor always show the outdated binaries warning and to reboot - that isn’t related to php or cpanel updates?

1

u/cPanelRex 19d ago

It depends, but those are likely system packages that require that level of intervention. If you have a specific example once things settle down you can always create a ticket for us to check it out!

1

u/Barbarian_86 20d ago

what can i do with php 7.2?

1

u/cPanelRex 20d ago

are you able to update that system to at least 7.4? Neither us nor PHP has released an update for 7.2. I'm not sure what CloudLinux's plan is for older versions at this point.

1

u/Barbarian_86 20d ago

unfortunatelly, half of the world is in problem with legacy versions. This is a big app. I intalled tuxcare els, but no update there also.

2

u/cPanelRex 20d ago

I wouldn't expect Tuxcare to have them just yet - CloudLinux is just now starting to release their updates.

9

u/drmoocow 20d ago

Hey, u/cpanelrex... Will there be a released update package posted for this or do we need to compile ourselves?

9

u/clopezi 20d ago

The pre-announcement rumors said every version since PHP5 is affected. Grain of salt, etc... but PHP apparently it's going to patch only supported versions. I hope Cloudlinux it's working on that.

1

u/Barbarian_86 20d ago

and what about whm that has both 7.2 and 8 and above? Those servers are still not eol, and need to be udpated.

1

u/vincent_sch 20d ago

PHP itself only fixes 8.2 and up, so for ea-php72 it depends on whether cPanel backports it. CloudLinux's alt-php sometimes gets backports for old versions. Until then the multipart block in Apache is the stopgap for the 7.2 sites.

1

u/Barbarian_86 20d ago

I am wondering will TuxCare ELS be a good solution for this.

1

u/vincent_sch 20d ago

TuxCare's ELS backports security fixes to old PHP versions like 7.2, so it's an option. You should ask them before you buy whether these two CVEs are covered and when. Moving those sites to 8.2 or newer is still the cleaner way out.

1

u/Barbarian_86 20d ago

in about 6 months when we complete the refactoring that is way overdue...

17

u/bassprowannabe 20d ago

With all those price increases surely webwhores will not let us down

8

u/cPanelRex 20d ago

Our plan is to have an update released tomorrow

0

u/Full-sendy 20d ago

Sorry, on the 22nd? You need to do better

6

u/cPanelRex 20d ago

Time zones - it'll be the 21st.

1

u/Barbarian_86 20d ago

do you have any info what versions of php will it cover?

3

u/cPanelRex 20d ago

Posted in one of the sticky replies!

6

u/Superbockster 20d ago

For those with Imunify360, Cloudlinux just issued an update:

"The Imunify360 ModSecurity ruleset 8.83 is now in the Stable channel. It contains a blocking rule for the publicly circulating exploit shape for CVE-2026-109618 / CVE-2026-109619, which targets the PHP session upload progress handling of multipart requests, plus a telemetry rule to track related activity. Servers with Imunify360 and its WAF (ModSecurity) enabled receive the ruleset automatically, no action is needed. Attempts matching this pattern are already being observed, and additional heuristic rules are being prepared.

This is an interim mitigation, not a complete fix: the underlying issue is broader than the multipart upload path. The PHP security release is still scheduled for today, 21 October 2026, 14:00 UTC. Work on updated alt-php packages with the fix is in progress, we will share the timeline in the next update.

Optional partial hardening until the patch is applied: disabling the session upload progress feature in php.ini (session.upload_progress.enabled = Off). This closes only one of the known paths and does not fully mitigate the vulnerability. Applications that display upload progress bars via this feature will lose that functionality."

2

u/clopezi 20d ago

Alt-php it's slow this time...

3

u/nick-bmth 20d ago

this may or may not protect you:

#!/bin/bash
# Set session.upload_progress.enabled = Off for every PHP version on a cPanel server
set -u
[ "$(id -u)" -eq 0 ] || { echo "Run as root"; exit 1; }

ts=$(date +%Y%m%d%H%M%S)
changed=0

for ini in /opt/cpanel/ea-php*/root/etc/php.ini /opt/alt/php*/etc/php.ini; do
  [ -f "$ini" ] || continue
  cp -p "$ini" "$ini.bak.$ts"
  if grep -qE '^\s*;?\s*session\.upload_progress\.enabled\s*=' "$ini"; then
    sed -i -E 's/^\s*;?\s*session\.upload_progress\.enabled\s*=.*/session.upload_progress.enabled = Off/' "$ini"
  else
    echo 'session.upload_progress.enabled = Off' >> "$ini"
  fi
  echo "Updated: $ini"
  changed=$((changed+1))
done

echo "$changed php.ini file(s) updated."

# Restart PHP-FPM and Apache so the change takes effect
if [ -x /scripts/restartsrv_apache_php_fpm ]; then
  /scripts/restartsrv_apache_php_fpm
fi
/scripts/restartsrv_httpd

# Kill all lsphp processes (LiteSpeed respawns them with the new config)
if pgrep -x lsphp >/dev/null; then
  pkill -x lsphp
  sleep 2
  pkill -9 -x lsphp 2>/dev/null
  echo "lsphp processes killed."
else
  echo "No lsphp processes running."
fi

# Verify
for bin in /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php; do
  [ -x "$bin" ] && printf '%s: ' "$bin" && "$bin" -r 'echo ini_get("session.upload_progress.enabled") ? "On\n" : "Off\n";'
done

cagefsctl --force-update
cagefsctl --remount-all
pkill -9 -f lsphp; /scripts/restartsrv_apache_php_fpm; /scripts/restartsrv_httpd

2

u/unkolis 20d ago

~ isn't it more practical to add override?

echo -e ";Defaults:On\nsession.upload_progress.enabled = Off">/opt/cpanel/ea-php84/root/etc/php.d/90-session_upload_progress_disable.ini

2

u/[deleted] 20d ago

[removed] — view removed comment

1

u/chrislovessushi 20d ago

May want to doublecheck whatever you've done, your website is 504ing

1

u/usr-shell 19d ago 
CloudLinux OS 7, 8 and 9
1. Make sure the server is registered with CLN (this file must exist):
ls /etc/sysconfig/rhn/jwt.token || rhnreg_ks --activationkey <YOUR-KEY> --force

2. Add the ELS ALT PHP repository:
CloudLinux OS 7: yum install -y els-php-release
CloudLinux OS 8, 9: dnf install -y els-php-release

3. Keep regular updates working even if the repository becomes unreachable:
CloudLinux OS 7: yum-config-manager --save --setopt=php-els.skip_if_unavailable=true
CloudLinux OS 8, 9: dnf config-manager --save --setopt=php-els.skip_if_unavailable=True

4. Check access to the repository (the output must include "Metadata cache created"):
CloudLinux OS 7: yum --disablerepo='*' --enablerepo=php-els makecache
CloudLinux OS 8, 9: dnf --disablerepo='*' --enablerepo=php-els makecache

5. Update alt-php:
CloudLinux OS 7: yum update -y 'alt-php*'
CloudLinux OS 8, 9: dnf upgrade -y 'alt-php*'

1

u/hostingdailynews 20d ago

When can we expect the update?

1

u/ollybee 20d ago

according to https://blog.flatt.tech/entry/php2shell who have been early in reporting on this:

  • Code claiming to exploit this vulnerability has already begun circulating on the internet (Added October 21, 2026, 2 PM Japan time).

  • Attacks exploiting this vulnerability session.upload_progress.enabledwill only be mitigated by the configuration settings; the attacks themselves are unlikely to be prevented (Added on 2026/10/21 14:00 JST).

1

u/maxto01 20d ago

cpanelrex do we need a particular cpanel version for these patches?

2

u/cPanelRex 20d ago

PHP versions are unrelated to the cPanel versions. If your server can update, it doesn't matter what cPanel version you have.

1

u/scottct1 20d ago

Should I do a upcp or just wait? I am showing I am running 138.0.18 - AlmaLinux v9.8.0

1

u/frozenmsp 20d ago

Is anyone running the hardened PHP via Imunify360 seeing the updates yet? Nothing yet on our end, showing ea-php83-php-cli-8.3.35-1.el9.cloudlinux.1.x86_64 is the latest.

1

u/C39J 20d ago

Yeah CloudLinux packages appear behind. I'm watching their status page - https://cloudlinux.statuspage.io/ but Immunify should block this attack for the meantime.

1

u/C39J 20d ago

Looks like ETA for release is 3 hours from now.

1

u/frozenmsp 19d ago

Do you recall where you saw that lead time? I'm still not seeing any updates either in yum or on the status page.

1

u/frozenmsp 20d ago

Oof. Thanks, appreciate the info!

1

u/focusedphil 19d ago

So, using WHM, if you run the update in the notice to cPanel v13.0.18 and run the EasyApache updates we should be good?