Heads up - critical PHP patch needed tomorrow for all servers

On server update at 9.15am

"The security fixes have been backported into the existing PHP releases, so the version number shown in cPanel, phpinfo() or WordPress Site Health won't change.

** Patched servers will still report the same PHP version (5.2–8.5) as before, but are running the fixed build. **

** There's no need to change your PHP version or contact us to confirm your site is protected. **""


Sound ok?
 
Last edited:
Alvin63 said:
On server update at 9.15am

"The security fixes have been backported into the existing PHP releases, so the version number shown in cPanel, phpinfo() or WordPress Site Health won't change.

** Patched servers will still report the same PHP version (5.2–8.5) as before, but are running the fixed build. **

** There's no need to change your PHP version or contact us to confirm your site is protected. **""


Sound ok? I'd be happier if I saw the number change to 8.3.36
Click to expand...

They can't just blindly upgrade everyone to that, some people are running specific versions and it could cause more problems.

Backporting is the right move, if everything on your side is up to speed and can jump to 8.3.36, then request it.
 
Is there a way to know which PHP version a remote website is using ?

Can I figure out what php version Xenforo.com is using ? (as an example).
 
Digital Doctor said:
Is there a way to know which PHP version a remote website is using ?

Can I figure out what php version Xenforo.com is using ? (as an example).
Click to expand...

Nope usually not. There are options to display it in headers etc. but it’s usually wise to remove those to make it harder for people to find servers running vulnerable versions.

But if you’re interested, we’re running PHP 8.3.36.
 
I can see the scenario unfolding now: companies balking about 'oh noes, that means we lose X amount of cash with this downtime!!'.... Many companies/entities this week probably had a crash course on immutable rolling updates and upgrading their code. ;)
 
Dragonfruit said:
They can't just blindly upgrade everyone to that, some people are running specific versions and it could cause more problems.

Backporting is the right move, if everything on your side is up to speed and can jump to 8.3.36, then request it.
Click to expand...
I can see that could be an issue though - but yes I can upgrade.

Also if they've patched it why are they still saying this?

"Please don't switch session.upload_progress.enabled back on. We've turned it off for you as part of the fix."
 
Last edited:
Any guidance on CVE-2026-115560?

From an article:
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().
Click to expand...

If we're only running XenForo, should there be an issue?
 
XenForo doesn't use php session handling, so it should be fine. Hopefully no add-ons are doing something insane with php session handling.
 
frm said:
Any guidance on CVE-2026-115560?

From an article:


If we're only running XenForo, should there be an issue?
Click to expand...
"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."

My server already said yesterday that session upload progress was turned off as part of the fix so maybe servers already know about this other one?
 
frm said:
Any guidance on CVE-2026-115560?

From an article:
If we're only running XenForo, should there be an issue?
Click to expand...

Yes. The PHP team suggests remediating for now.

This remediation should cover new / old versions of php and also all 3 CVEs:

Code: 
#Courtesy mitigations, updated 10/23/2026
#rationale: https://github.com/syhunt/php2shell-protection
session.upload_progress.enabled = Off
memory_limit = -1
post_max_size = 32M
upload_max_filesize = 28M

#possibly break some applications
session.use_strict_mode = 1
session.cookie_httponly = 1
session.cookie_secure = 1

Working and tested on 10 different kinds of apps including two xenforo forums.
max upload size, you will need to warn your members about. The best advice to them is to upload 1-2 images at a time. Otherwise a big batch will fail.

You may not need all these mitigations so check the github repo as it explains each line.

Of course you should upgrade your PHP also like a good sysadmin.
 
Alvin63 said:
"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."

My server already said yesterday that session upload progress was turned off as part of the fix so maybe servers already know about this other one?
Click to expand...
xenforo itself probably doesn't need or perhaps even rely on session.upload_progress.enabled anyway.
@Chris D

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().
Click to expand...
 
I was overdue to freshen up one group of my servers, and I did that over these past few days. By freshen up, I moved all three servers to new VPS instances and installed and configured everything new, which also cleaned up a lot of old issues I had, and despite the new instances having the same specs, everything is running much better now. Since Cloudflare provided some protection, I didn't need to jump on the vulnerability right away, but everything is secured now.

My other half's son has been dealing with this for the entire week--he is on the I.T. team at a large auto dealership network and they've had a combination of upgrading/patching their software and taking some sites offline until they could be fixed. This is on top of their usual hectic daily pace.
 
You must log in or register to reply here.
Back
Top Bottom