New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
tag a provider who will need to update but you know they wont
@PulsedMedia
I think that their Väinämöinen AI do this update @PulsedMedia
Even klankers takes time and money. Attack surface is to big for small fish to care. Main attention will be on big corps.
sure, but shell access on bullshit server is worth a pretty penny as well. Botnets, proxies etc. Given how bad it is, there might be even some decent home run options available
They aren't allowed to use their AI to post on the forum automatically (unfortunately) + I guess they were too transparent in the first place...
Virtfusion interim fix recommends to turn off the following :
https://docs.virtfusion.com/security/php-october-2026/
Hi all, Jo from Hosted Power here.
Like many of you, we have a mix of PHP versions on our servers, and some of them won't get a patch today. We wrote a small extension for those and open-sourced it, in case it helps anyone else here.
It switches off the session upload-progress handler (where the researchers who reproduced the bugs placed them) at PHP startup. Uploads keep working, sites can't re-enable it via
.user.ini/.htaccess(unlikesession.upload_progress.enabled = Off), and you can check it per version withphp --ri hp_uploadprogress_guard. The repo has install steps for cPanel EA4 (including a hook for new ea-php versions), DirectAdmin CustomBuild and Debian/Sury.https://github.com/HOSTED-POWER/php_uploadprogress_guard
To be clear about @aphex's point: on a box where nothing overrides the ini setting, our extension cuts the same code path, it just can't be undone per site. So if the core devs are right that upload-progress mitigations aren't sufficient, that applies to ours too. It's not a replacement for the official packages; install those as soon as they land. It's a few hours old, and we'll check it against PHP's details at 16:00 CEST and update this thread either way.
Yes too transparent, if we did like everyone else; 100% AI Slop from GPT-3 blatant AF and spam as much as possible; That is fine, and approved separately.
But saying it's AI and it's actually good AI Agent ... That's a no go. Makes you wonder why ...
PHP-based billing panels:
What hackers can do:
PHP-based hypervisor panels:
What hackers can do:
PHP-based shared hosting panels:
What hackers can do:
These panels are not PHP based:
You can escape PHP vulnerabilities, but they can have their own vulnerabilities.
Research performed by Muse.ai, "what hackers can do" written by the flesh.
Thank you YoursunnyGPT
Worst case scenario: current exploit isn't really usable because everyone used possible mitigation settings and the to-be-released new version contains backdoor where hackersgroups have their exploits ready for...
How do I know my providers have any mitigations setup or not, airnode took their customer panel offline (notified) and greencloud is still up. How are people handling this? I have not seen a true POC on the internet yet because you need the address leak to know where to put the payload afaik.
CERT-EU and the UK NCSC are taking it seriously enough to say that internet-facing PHP systems that cannot be remediated should be considered for isolation/offline status until they can be patched.
Are there any tell-tale signs in weblogs that something is trying this sort of attack, that we can check for?
cloudflare applied waf rules against this already. i moved nextcloud behind waf for now
70% on internet runs on PHP, I’m pretty sure that cert-eu itself also (now it's showing gateway error btw). PHP team handles this incident as poorly as possible, but looking at the PHP past, it's nothing new.
There are Coolify update later today due PHP bugs: https://github.com/coollabsio/coolify/issues/12255
All a conspiracy by Big P to get everyone to upgrade to 8.x!
Francisco
Thing is you cannot know it, it is a matter of trust, sadly. Time to reduce the amount of idlers and get dedi.
Not really, if they implemented the current mitigations, you can easily check in phpinfo, and even simulate a multipart HTTP POST request test.
In case of hosted PHP - yes but what about hosted [hypervisor,billing] panels? Can you check they were patched?
Large number of websites in the Netherlands taken offline as a precautionary measure including RTL, Tweakers, and government sites.
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.
Bunny (aff/non-aff) did this too.
https://bunny.net/blog/cve-2026-109618-and-cve-2026-109619/
yea, I took my sites offline too till the updates arrive. better safe than sorry
return 503;on nginx wherever php runshttps://4chan.org/ is also taken offline
Hoping that cloudlinux can backport this to 7.3 and shared hosts are quick to update
Netcup is shutting down everything (translated from german):
https://forum.netcup.de/thread/23215-php5-6-7-8-cve-2026-109618-109619-remote-code-execution-rce-update-3/?postID=276215#post276215
In the next few minutes, we will be taking the forum, Customer Control Panel (CCP), Plesk, the CloudDNS API, and webmail offline as a precautionary measure until we have a patch ready. The CCP will remain online.
Furthermore, once the patch is released, we will take all web hosting packages (including managed servers) offline until the patching process is complete. Access to Plesk will be disabled immediately. We anticipate approximately 3–5 hours of downtime for the web hosting services.
It seems like the sensible aproach to go into maintenance mode before the release until you update.
AI agents will be on this for the big targets in minutes.
The real question is... Is github ready for the all the containers getting rebuilt via github actions?
The cryptic responses from those in the know is that there is no solution other than updating PHP...
Its not clear to me if thats because ini_set can re-enable the feature, or because there is another more serious vulnerability. Something that cant be disabled (e.g cookie parsing) for example would be a "you can only patch it" issue.
Critical CVEs for both Node and PHP on the same day.
The internet is going to break today.
Update is live!
https://www.php.net/index.php
Which covers the four series 8.2.x, 8.3.x, 8.4.x, and 8.5.x
I imagine that third-party vendors will try to patch earlier series ASAP