Upcoming Critical PHP Security Release

angstrom

@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

twain

Anyone contacted @labze for the storageboxes?

stable_genius

@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

@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

How often you wanna update your PHP this week? Yes.

Jord

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

Because why not

NBO

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

@Francisco

Daniel15

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.

Francisco

@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

rdes

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

@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

Mainfrezzer

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

Daniel15

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

My @NameCrane is still not updated.

behuk

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

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

jgoossens

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

grinc0in

Offtopic: Nodejs just released very high CVE too

jgoossens

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

SplitIce

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

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).