Major PHP Security Notice

[arcus]

Two critical vulnerabilities have been found in PHP. In other words, a site that uses PHP is now easy to hack (unless it gets upgraded).

Anyone that runs a site on PHP should take precautions and upgrade when the patch is ready (roughly 9 hours from this post).

Upcoming Critical PHP Security Release

The PHP security team would like to give advance notice of an upcoming security release.
It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC.
It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.
All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available.
We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
Full details, affected versions, and the fixed versions will be published with the release.
Thank you for helping us keep PHP secure.

Source.


EDIT: The update is live.

[Noah_S]

Thanks for letting us know

[Dan Q]

There's definitely weaponised code out there already. If you run PHP on an Internet-facing server, here's what I would personally recommend (and it's what I did on half a dozen servers earlier today):

- Put the mitigation line in your php.ini and restart your php-fpm process (I've assumed you're running FPM and not CGI, because it's 2026, not 2006), unless for some reason you absolutely can't (e.g. you're depending the upload-progress feature for something critical)
- If you're running AppArmor (and you should be), check that you're already denying PHP permission to run arbitrary executables; if you're for-some-reason depending on this functionality (god help you), at least restrict which binaries it's allowed to run down to only the ones you actually need

Either one of those two is probably sufficient to prevent an exploit today. But obviously the next step is:

- Later today, install the update (you may then undo the php.ini mitigation line if you like, e.g. if you're using upload-progress indication but it's only a "nice to have")

In general, if you haven't already, I recommend that you reduce your visibility:

- Ensure that your webserver strips headers that advertise that you run PHP, especially if you expose the version number: there's generally no reason to expose this to the world
- While you're in there, consider masking your webserver version too: you don't HAVE to return a Server: header at all, and if you do then it might as well just say the name of the software and not its version number, or make it say something fun!

[Rubbereon]

- If you're running AppArmor (and you should be), check that you're already denying PHP permission to run arbitrary executables; if you're for-some-reason depending on this functionality (god help you), at least restrict which binaries it's allowed to run down to only the ones you actually need

Or run the server from within a sandbox so it cannot affect the whole system and run any necessary binaries from within the sandbox too.

I believe Firejail can do something like that, but I've never done it so I'm not completely sure (been a while I used firejail at all because Snap and Flatpaks are sandboxed, so that's a security concern that really doesn't exist anymore for the casual end user. That said firejail should definitely be an extremely important piece of protection to server webmasters).

[Loebas]

I've turned off Apache, and PHP on the boykisser network until i can apply all patches. And if this cannot happen today, i will turn off the boykisser VPS entirely until patches are available. So my site is down until further notice 
If you have a VPS, i recommend doing the same.

I've seen some forums including ChickenSmoothie following suit.

Scary to see how many websites are still online running PHP. Even the newssite of my city is still online, and that is running wordpress, albeit behind cloudflare.

[Dan Q]

Or run the server from within a sandbox so it cannot affect the whole system and run any necessary binaries from within the sandbox too.

This is good advice in general, but doesn't protect you from all of the harms that this vulnerability can cause. E.g. if your sandbox gets owned, it can be used as a spam relay or as part of a DDoS network for example.

A sandbox is good defence-in-depth. But overall it's better to mitigate and patch.

[meeow]

apparently, till the patch drops, its advised to set session.upload_progress.enabled=0 (i think its off by default in fpm, not 100% sure) even tho a php core dev says is not enough

[shaggy]

Or run the server from within a sandbox so it cannot affect the whole system and run any necessary binaries from within the sandbox too.

Or pay small fee to hosting company and don't give a single damn about what is happening there :P Just have backups xD

[ribose]

i just deactivated the two php sites i had on subdomains, because most of this is going over my head.

one was hosted on infinityfree, where i have no control over the php version, so i think i'll be safe to reactivate it after the patch is released? i'm keeping an eye on their support forum, but the security issue hasn't been mentioned (unrelated to the current issue, it looks like they have a chatbot answering support questions sooo... maybe it's time to move somewhere else?)
EDIT: someone made a test page that shows the current version of php on infinityfree (support thread here)

the other one was on heliohost, which let me choose a php version... and i was using an outdated one. i was using an old fanlisting management system that's no longer maintained, so it looks like i have some work to do before i can safely put this one back online.
EDIT: here's the support thread about it on the heliohost forum
EDIT 2: heliohost is patched!

[candycanearter07]

thanks, i disabled my nfs site and am watching the forums to see when those mins apply the patch

[Noah_S]

infinityfree

maybe it's time to move somewhere else?

Last year I started using infinityfree to build a beta version of my site.

They had 2 and a half months downtime in one go earlier this year and then deactivated my site because it hadn't been getting enough visitors during their downtime. They block you from automating back-ups. They are also incredibly suspicious in that they will hide that they're byethost under another name until after you sign up. I'm also experienced with byethost, and they didn't update their security and then blamed us for it. This was on paid hosting. On infinityfree's shared hosting there are also limitations that they are not upfront about when you sign up. There's a limited amount of times that any file on your website can be loaded before your site gets deactivated for exceeding a limit that you didn't know about. And it counts every single file towards the total. An image was loaded? There's one tick. Another image? Another tick. First image again? Another tick. A CSS file? There's another tick. And this fills up fast.

So to sum it up, yes, I recommend moving somewhere else.

[arcus]

The update is here, along with more details about the vulnerabilities.

[mretn_]

anyway the speedrun for source users is quite simple:
REMEMBER THIS BEFOREHAND THOUGH THESE ARE THE FLAGS FOR THE ENCLOSED CONFIGURE SCRIPT, MAKE SURE TO REMOVE ALL THE APOSTROPHES:

Code

php -i | grep "Configure Command"

and now we go down to the latest php version

Code

wget https://www.php.net/distributions/php-8.5.12.tar.gz
tar -xvzf php-8.5.12.tar.gz
cd php-8.5.12
<paste the configure command here>
make -j$(nproc) # THIS WILL LAG YOUR SERVER MAKE SURE YOU WARN PEOPLE THAT IT WILL LAG, also if over ssh, run screen make -j$(nproc) instead so the compilation would not get killed upon ssh disconnection
sudo make install

[ribose]

my nfs site and am watching the forums

maybe you've already seen it, but in case you haven't, nfs has been patched! (forum post)