Upcoming Critical PHP Security Release

Comments

• angstrom Moderator, Veteran

  October 21 edited October 21

  @raindog308 said:

  @aj_potc said: Interestingly for those in the Red Hat ecosystem, Red Hat doesn't classify these CVEs as Critical, but Important (score = 8.1)

  I'm not a security nerd but is this because RedHat's default configuration isn't as vulnerable?

  PHP on Ubuntu could be a 9.2 but on RedHat it's an 8.1 - is that a thing?

  I suspect that Ubuntu's score of 9.2 is taken directly from PHP security's own score of 9.2:

  • https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
  • https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

  As for Red Hat, they've made their own assessment of the severity

  Thanked by 1raindog308
• twain Member

  October 21

  Anyone contacted @labze for the storageboxes?
• stable_genius Member

  October 21 edited October 21

  @aj_potc said:

  @raindog308 said:

  I'm not a security nerd but is this because RedHat's default configuration isn't as vulnerable?

  PHP on Ubuntu could be a 9.2 but on RedHat it's an 8.1 - is that a thing?

  Both great questions that I can't answer.

  I am assuming Red Hat was given early access to the vulnerability details and had time to come up with their own scores. But I would love to know what, specifically, makes them think their distro is harder to exploit.

  Yeah, RHEL is ahead of the curve in security, they seem to take security more seriously than anyone else.

  Maybe no one gave Red Hat early access to the vulnerability but they got early access to it anyway, by being proactive
• zed Veteran

  October 21

  @ScreenReader said:

  @Zhenmue said:
  How can Cpanel and DA update their php versiones in less than 20-30 minutes

  and CloudLinux needs at least 5 hours.

  sire, a new exploit has hit the building https://fedi.katze.sh/@elise/117479383739450605

  > While not yet fully confirmed, the Fediverse is reporting that the fix
  > to at least PHP 8.5.12 may be incomplete:
  > https://fedi.katze.sh/@elise/117479383739450605
  
  According to a conversation in #security:ubuntu.com Matrix, Canonical
  asked php.org if the issue mentioned in this Mastodon thread was a
  real vulnerability or not, and was told that it's "unrelated and not a
  real issue". If someone from the PHP security team could reconfirm
  this here, that would be greatly appreciated.
  

  https://openwall.com/lists/oss-security/2026/10/21/23
• Neoon Community Contributor, Veteran

  October 21

  How often you wanna update your PHP this week? Yes.
• Jord Moderator, Host Rep, Veteran, Megathread Squad

  October 21

  @Neoon said:
  How often you wanna update your PHP this week? Yes.

  Because why not

  Thanked by 1tux
• NBO Member

  October 21

  @jonathann said:
  @NameCrane please upgrade the PHP versions. DA reports PHP 8.2.34, which is below 8.2.35

  @Francisco
• Daniel15 Veteran

  October 21

  Based on the security advisory, it sounds like it's mostly specific to Apache: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w. fpm is exploitable in theory, but nobody has been able to demonstrate it.

  Ondřej Sury backported the fix to all PHP versions in his Debian repo, going back to PHP 5.6. If you're stuck on an old version for whatever reason, switch to his repo and update. https://codeberg.org/oerdnj/deb.sury.org/issues/145

  @wdmg said:
  fyi:

  add session.upload_progress.enabled = Off to your php.ini.

  it'll fix it.

  This isn't a full mitigation as upload progress isn't the only thing that parses multipart requests.

  Thanked by 1jaden
• Francisco Top Host, Host Rep, Veteran

  October 21

  @MrRadic said:
  FYI - Cloudflare released rules for mitigating this attack.

  Also looks like that setting might not be enough, blocking multipart uploads via your WAF might be the temporary solution.

  @NBO said:

  @jonathann said:
  @NameCrane please upgrade the PHP versions. DA reports PHP 8.2.34, which is below 8.2.35

  @Francisco

  We're on it, ,trust me

  Cloudlinux has been slow on updates, but we had applied the php.ini tweaks early this morning as a stopgap.

  Francisco

  Thanked by 1behuk
• rdes Member

  October 21 edited October 21

  Another fix that can be compiled as php module:
  https://github.com/HOSTED-POWER/php_uploadprogress_guard

  (found on DirectAdmin forums, not tested yet).
• Ramsterdam Veteran

  October 21

  @rdes said:
  Another fix that can be compiled as php module:
  https://github.com/HOSTED-POWER/php_uploadprogress_guard

  (found on DirectAdmin forums, not tested yet).

  The author is in LET as well @jgoossens ; thanks for the contribution.
• carlos001 Member

  October 21 edited October 21

  
• Mainfrezzer Member

  October 21

  the funniest and "spookiest" take away from today is that some repos basically died because people kept refreshing for updates.

  Thanked by 2MikeA tux
• Daniel15 Veteran

  October 22 edited October 22

  For anyone that can't patch for whatever reason... From the advisories on Github, it looks like fatal_error_backtraces=0 and memory_limit=-1 are needed mitigations in php.ini too, but be careful when unlimiting memory usage with untrusted users (like on shared hosting) since that could result in actual OOMs. Probably best to put a cgroup memory limit on the PHP process in lieu of PHP's built in one.
• NBO Member

  October 22

  My @NameCrane is still not updated.
• behuk Member

  October 22

  @NBO said:
  My @NameCrane is still not updated.

  CloudLinux backported the fix: https://lowendtalk.com/discussion/comment/4894144/#Comment_4894144.
• jgoossens Member

  October 22

  Thanks @Ramsterdam! Quick update for anyone using it: v3.2.2 also covers the two issues PHP hasn't fixed in a release yet (php-src#24481 and #24488), on patched and unpatched PHP, and now ships Windows DLLs for 5.6 too. Update PHP first; the module is a bridge.

  https://github.com/HOSTED-POWER/php_uploadprogress_guard

  Thanked by 1Ramsterdam
• grinc0in Member

  October 22

  Offtopic: Nodejs just released very high CVE too
• jgoossens Member

  October 22

  Small follow-up, since a few people here run it: v3.2.3 fixes threaded Apache (mod_php with worker/event, and the Windows ts DLLs), where the upload handler only covered the first thread. A user found it by testing instead of trusting phpinfo, which is exactly how it should go.

  The release page now has one zip / tar.gz with everything, plus an installer for Debian/Ubuntu: https://github.com/HOSTED-POWER/php_uploadprogress_guard/releases/latest

  Thanked by 1Ramsterdam
• SplitIce Member, Host Rep

  October 23

  Trigger: **: Request error [upload/malformed_multipart_opening]
  Trigger status: PROBLEM
  Trigger severity: Warning
  

  There has been alot of attempts to exploit this vulnerability over the past 24-hours.

  If you havent already upgraded, you are playing with fire.
• jgoossens Member

  October 26

  Last update from me here. Since v3.2.3:

  CVE-2026-115560 (session upload progress, PHP advisory of 23 October) is not fixed by the 21 October releases. PHP's mitigation is session.upload_progress.enabled=0, and the module already does exactly that by default, locked so .user.ini or ini_set() can't turn it back on. If you run the module, you're covered.
  v3.2.5 fixes a race on threaded PHP (ZTS: Apache worker/event, Windows ts) where a rejected upload could still slip through on another thread. Found and patched by NewEraCracker while porting it to his Suhosin fork, then confirmed under load before release.
  The installer now also works on servers with a noexec /tmp.
  As @SplitIce says, the exploit attempts are real, so update PHP first. The module still covers what PHP hasn't fixed yet (the CVE above, unserialize php-src#24481, SimpleXML php-src#24488).