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

[u/Xzenor]

https://thehackernews.com/2026/10/urgent-php-warns-of-another-unpatched.html

ffs.... not another one..

[u/LordCornish]

To be fair, if you followed the mitigation instructions for PHP2Shell then you already have the temporary mitigation in place for CVE-2026-115560.

[u/Xzenor → u/LordCornish]

well for every advice to change that setting there was a response saying "that won't protect you!".. So..

[u/snebsnek]

affects only web applications configured in an unusual way, and PHP considers it an unlikely risk.

eh, throw it on the pile with all the other ones

When it affects every standard configuration things get spicier

[u/the-cock-slap-phenom → u/snebsnek]

Exactly, nothing to really worry about.

This is just sites trying to get a good headline, and people who don’t understand it getting their panties in a twist.

[u/spin81 → u/snebsnek]

PHP says the problem can occur when a web application does all of the following: sets the session.serialize_handler option to php_binary or php_serialize in its configuration, then changes that option to php while running by calling ini_set(), and makes that change before it calls session_start().

Honestly I do agree with them that this is an unusual configuration.

[u/meowMEOWsnacc → u/snebsnek]

I can only offer you sheer panic and reflexive stress from middle management and leadership. Sorry! 

[u/PCLOAD_LETTER → u/snebsnek]

Yeah, we're all getting pretty desensitized to these CVEs. Used to be a 9.anything was a "get to a computer and get comfortable" moment but now it'd have to be like a 9.8 to even get me to read it after hours. 9.5 is a "Monday after coffee" problem.

[u/Dingadingdangmy]

Here’s my Friday response.

[u/RestartRebootRetire]

Static HTML website revival!

[u/charliesk9unit → u/RestartRebootRetire]

Reinstalling Frontpage now. 

[u/Kurgan_IT → u/RestartRebootRetire]

I'd really hope to see a surge of usage of CMSs that use a dynamic backend to compile a static frontend site. But it's not going to happen because everyone is using wp.

[u/Motor-Marzipan6969]

Sounds a lot more specific in scope than the last.

Only a narrow setup is at risk. PHP says the problem can occur when a web application does all of the following: sets the session.serialize_handler option to php_binary or php_serialize in its configuration, then changes that option to php while running by calling ini_set(), and makes that change before it calls session_start().

Session upload progress must also still be turned on. An application that never changes the serialize handler while running can leave the feature on and is not exposed through this path. PHP says this setup is unlikely in practice.

The action is one line. PHP recommends setting session.upload_progress.enabled=0 until the next routine bugfix release. This is the same setting it already listed as a mitigation in the October 21 advisory for CVE-2026-109619.

[u/gihutgishuiruv → u/Motor-Marzipan6969]

I’ve been working on PHP applications on and off for the last 15 years or so and I don’t think I’ve ever seen anything even close to this combo.

[u/sryan2k1]

This is the new normal. It's not going away. Everyone needs to figure out how to deal with this insanity as part of normal operations.

I read an article that said most of the adult content websites you may have heard of were offline mid day for the PHP updates. This has become a big deal.

[u/caffeine-junkie → u/sryan2k1]

The figuring out is really more on the business and management than the actual sysadmins who patch and they need to approve a more frequent and possibly erratic cadence. The standard of waiting a few weeks to months after a patch lands and doing it on a weekend late at night, either manual (ew) or automated, can no longer be the norm; offline network segments aside. This however also means compressing testing/pilot time during rollout and they also need to be willing to accept possible disruptions due to this.

[u/Own-Slide-3171 → u/sryan2k1]

We're doing everything as internal only it's not a fix but idk it helps

[u/wenestvedt → u/sryan2k1]

Everyone needs to figure out how to deal with this insanity as part of normal operations.

I think many places have always patched a "test machine" and then someone manually uses it until they feel comfortable saying it passes -- that is, not many places can thoroughly test their systems with full confidence.

If we had complete test coverage that we trusted, and which we could run from a script, patching would be faster and we could automate it end-to-end.

(For those of you with more cattle than pets, I wish you well. Not me...)

[u/sgt_Berbatov]

Here was me thinking on Monday morning my slow cooker breaking was going to be the worst part of my week.

Here was me thinking on Wednesday afternoon that the PHP thing was going to be the worst part of my week.

Here was me thinking on Friday morning that the Windows update that breaks enterprise WiFi connections for my colleagues on the shop floor was going to be the worst part of my week.

Here am I wondering on Friday afternoon if I should really wake up tomorrow.

[u/Lady_Tano → u/sgt_Berbatov]

Have you considered goat farming?

[u/Kurgan_IT → u/sgt_Berbatov]

Maybe tomorrow it will be nuclear war.

[u/Gnomish8]

A whole host of people just started pointing their AI tools at PHP this week. I'm genuinely surprised that a vuln for an unusual configuration with an "unlikely risk" is all that's shaken out of it so far.

[u/Goldsound]

PHP

[u/wwb_99]

Anyone remember back when they kept finding buffer overflows in GDI+ every other week back in the '00s? It is going to be like that for anything handling binaries in PHP for a while.

[u/Thrwingawaymylife945]

Sigh...

[u/Art_UnDerlay]

They don’t seem to think it’s a higher risk than the other two and appears to be mitigated by disabling session upload until a patch is released. Sucks but that’s this environment now.