$ docker pull php:8.4.27
8.4.27: Pulling from library/php
no matching manifest for linux/arm64/v8 in the manifest list entries
$ docker pull --platform linux/amd64 php:8.4.27
8.4.27: Pulling from library/php
no matching manifest for linux/amd64 in the manifest list entries
Many here call for an earlier release of the patch.
But it is not clear if releasing the fix early would make the damage smaller or larger.
Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
There is no way to coordinate the whole world on an earlier time. I would guess the number of people who have to patch their instances is in the hundreds of thousands.
Everybody who actively watches the topic already has the option to shut down their instances.
So ringing the bell and getting as many people as possible to shut down their webservers now and patch at 14:00 might be the best in terms of damage minimisation.
By the way, it is not enough to just "shutdown -h now" and then later restart and "apt update && apt upgrade". The moment the machine comes back, it can get hacked. So you should make sure the webserver does not start after the next boot. For Apache this would be something like "rm /etc/systemd/system/multi-user.target.wants/apache2.service" and then after patching recreate the symlink via something like "ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/apache2.service".
I have not seen confirmation that the exploit is for the bug that is going to be patched.
It seems the published exploit can be easily prevented by filtering out multipart post requests. So people actively watching the situation can already prevent that issue by filtering those.
How does it work that some service that most people never heard of distributes (paid) images with alleged fix for vuln 24h before official vuln fix/image is available? Seems somewhat shady.
I can almost confirm a Wordpress site I manage was attacked with this. Oct 5th updated it to latest php and Wordpress. Oct 6th it was exploited with a web shell exploit
> Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
I think that this made sense a few years ago but in today's world it is so feasible to give an LLM a hint and throw some cash at it to find an exploit that I don't think this calculus makes sense anymore.
> Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
No matter the excuse, the security issue must be fixed. Anyone trying to delay this is not acting in good faith. I understand your rationale but that does not excuse you from being labelled as such too.
We should live in the age of open source AT ALL TIMES. No exceptions, for anyone, no matter the reasons. And that includes those who want to withhold code or patches.
I've tried to take one website on a shared hoster down. But I actually can't disable PHP there at all. So no idea if just taking down the website will fix it. Probably PHP won't get executed if no .php files are served, but I'm not sure.
For everyone wondering why the patch is not out yet:
There are a handful people responsible for doing a release. They are still asleep.
To be honest, I am also shocked, that the exploit was published that quickly, after the leaked video (which was the reason, why the announcement happened in the first place, at that specific time). We expected a bit more time, even with LLMs...
We've been working with the team on the coordinated disclosure, but I made the call to get these out early when exploits hit in the wild.
The vulnerability and patch are both very complex, and the maintainers did an incredible job on this one. We tested the patch extensively and it's holding up well.
We've made these images free and will keep them that way.
How? Biggest organisations and shared hosting providers had a chance to patch and protect their users. Everyone else will learn about the vulnerability the second patch comes out (this is also fixable with a configuration chance, so nobody needs to wait for their distro). This was the right approach and it worked.
This is something of a fallacy. "The Industry" cannot learn.
But laws and regulations can require better security.
As in the history of seatbelts in vehicles, tech tool stacks are insecure by design and no one is ever really held accountable... until the cost is deemed too high.
It's evident that we have not reached that limit yet.
This is nonsense, disappointed to see that publicly from a core dev. Yes, some people are asleep, but the decision was made to wait, to ensure the patch is only made available when users are actually able to install the update and we're giving distros the time to build PHP packages.
That's horribly naive with an installed base this size and if you are that geographically dependent then I would hope to read how this will be dealt with going forward.
Honestly, kindarails2shell resulted in a responsible disclosure coordination followed by the decision to release early since it was reversed too quickly. Even just a hint of a 0-day is enough to cause people to look for it and exploit it with LLMs.
lmfao what... If the police woke me up to fix anything the only thing they'd get out of me is "lawyer". And I wouldn't put a single iota of effort into fixing that thing until the entire matter with the police was resolved. If you want someone's attention on something, especially something nuanced and intricate like a software bug, that's absolutely not how you get it.
Given that this affects every PHP version from the past decade, and that the exploit instructions are circulating at the top of twitter, and that there's no fix available yet, it doesn't seem outrageous to assume every major PHP website is already compromised?
The upgrade instructions here should include torching your hosts and starting again.
I would assume that in many (smaller, non-professional) systems/code bases, it is also possible to poison the backups and code base in general. This would have been a major effort in the pre-LLM age, but it should be pretty easy now. As soon as such instructions are out there, people (or rather LLMs) are going to find ways to make the threat persist.
It’s probably advisable to go through your password manager and start deleting any accounts you no longer use. And of course make sure that you have zero shared passwords
The exploit is already out. Yeah this looks like it's going to go on history as the worst vulnerability ever. And now with LLMs you'll likely see tens of thousands of agents hacking any php website out there within hours.
Yup, I'm seeing several legit people on X claiming to have seen or found the exploit. Some say that: turning session.upload_progress.enabled off and setting file_uploads = Off will mitigate. But others are claiming that those steps are not enough and "Upload progress can serialize before basic RINT clears BG(serialize)". So, I'm taking no chances and taking my services offline.
I think this exploit + agentic AI (which allows for rapid secret exfiltration/utilization) may be a potent enough combo to trigger a sort of Kessler Syndrome for network security.
If the problem is in the parser then `file_uploads = Off` doesn't help, PHP still parses the multipart body. That seems to be why they're talking about blocking multipart/form-data on routes that don't take uploads and rate-limiting those that do.
>PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
I get that maintenance teams need to have conviction in this approach, but this is definitely going to cause catastrophically large data breaches downstream.
> Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
None of these 2 CVEs seem relate to POC spread in twitter. I'm not sure if the POC is something fake or they just unveil something within a few hours..
Scroll down in the actual patches to the weirdness of the multipart parser. That very much looks related to the what can be abused via the upload progress callbacks that had been discussed on (anti)social media.
I took my services offline last night, wouldn't have been able to sleep otherwise. There has been core PHP members that have outright said the mitigation's currently doing the rounds won't help and even cloudflare can only mitigate against known attack payloads.
The maintainer's comments are singularly unhelpful - "there's nothing you can do, just curl up and die" is pretty useless when you're faced with "take the entire company site offline" vs "maybe get exploited."
Mindboggling, wtf don't they release it if its ready and exploit is in the wild, its a lot of time until 14:00 UTC and a lot of websites will be breached.
They should have shut up, released a new stealth PHP version and told everyone to update ASAP. They gave way to many details ahead allowing some AI agents to find the vulnerability within half an hour...
The reason we (used to) have responsible disclosure timelines is so that the information & software to fix vulnerabilities can be assessed, organised, written up. Builds could get built, attackers and defenders find out at once. But crucially, defenders could use the normal channels to fix their installations and be sure they'd covered themselves.
When a PoC drops before that timeline is up (like now!) the attackers get a head start because they have less work to do - just figure out how to use it to their payload, start spraying it out.
Meanwhile maintainers don't want release an incomplete or misunderstood fix. Otherwise they'd risk people updating and believing that they're safe when they're not. Even a fragment of misinformation from an official channel will spread like wildfire. So when you demand fixes NOW you're demanding something that may not be completely understood.
So (I'm sure we'll find out but) I believe this 2pm timeline was already as soon as is human possible for the PHP team to do a repsonsible job, and not risk us having to come back tomorrow for a fix to the fix.
LLMs gives attackers the advantage for a while, and it means we'll have to tighten the secrecy around even the rumour of a vulnerability.
Years ago I migrated all my personal sites to being statically generated, since they don't have actual dynamic content anyway. That was a good decision.
Same here. And for the dynamic content, I host dedicated, small services, or client side code.
Not only 10 years of no more security updates. But hosting static content is cheap, performant and sustainable. Bot literally (you can move the content anywhere, using any kind of server) and in energy sense.
While I understand it is not for everyone to write markdown files and run build commands, I strongly urge anyone with a WordPress or drupal site to give the various jamstacks, or static site builders and guis a test run.
How can I try this to see if I should shut things down myself. I run a 6 figure stealth and have a day job for fintech in 9 figures all php so kinda worried
But created my own based on it since it feels sketchy running someone else's exploit poc ya know. Ran it first in a vm before running it against a production site.
Meh, I'll just roll PROD back to our 4.7 image, then head down to the pub for a pint until this all blows over... Only 3 years of data will be missing... No biggie! LOL :P
The demo video has been going around Twitter today and apparently the proof of concept is privately being shared around too. The video shows pasting something in the URL and then gaining a shell on the server. It looks completely catastrophic.
I think the best course of action is to just shut your server down before the patch goes live and then bring it back after you have patched.
The URL is to show the effects of the exploit. The person's running a python script that runs the exploit and then makes the PHP installation execute an arbitrary shell command. The proof of concept involves writing "pwned" to a publicly accessible location on the web server, then they refresh the browser pointing at the URL to show it's been written.
This is gonna rinse so many LAMP WordPress installs where the PHP version is either not getting a patch or the hosting is managed by the user via a contractor or the hosting is managed by a company with a fleet of custom servers etc etc.
We almost need some bot that logs in to every vulnerable PHP server and turns it off to prevent it being properly exploited before the server admin updates it..
We observed this update ourselves and suspected it to be a mitigation when it was rolled, but I can't find any definitive record that these rules are about the PHP vulnerability. Do you have more info?
I initially updated the following php.ini setting and verified that it updated via phpinfo(). I understand this to be only a possible mitigation (see below).
session.upload_progress.enabled = Off
file_uploads = Off
According to someone stating they are one of the PHP release managers:
"INI settings alone won't protect you. You need to patch PHP."
I use Apache, and added an htaccess rewrite rule in my base directory to block all requests containing multi-part headers. Rewrite rules can also be added into Apache virtual host blocks. Accepting file uploads are not a critical function of the app in my case. This blocks multi-part form requests before they reach PHP.
I've tested the CVEs on PHP 8.5.11 and `session.upload_progress.enabled = Off` definitely increases safety but it doesn't guarantee it. Use of plugins can open up additional exposure.
If you're behind CloudFlare apparently they'll cover you, issue is, some people don't have their web servers configured to block traffic NOT from CloudFlare, so it is kind of a bandaid that's falling off I guess.
I'd check this carefully and make sure you have the WAF enabled. I seemed to always have plenty of weird looking PHP and WP requests happily forwarded by CloudFlare to my servers.
Users on the Free plan have access to the Cloudflare Free Managed Ruleset, a subset of the Cloudflare Managed Ruleset.
If the rumors for these exploits being shared on Twitter are correct this is going to be a nightmare. I wouldn't be surprised if VPS hosts step in to mitigate it somehow since so many cheap/unmaintained LAMP installs are running on those servers.
I'm keeping a list [1] of all the (possible) precautions one can take, ahead of the patches appearing in a few hours. Exploits are now circulating, according to Cloudflare's CTO, so _any_ mitigation is worth investigating
I'm not seeing any discussion here about woeful web application architectures from the 1990s still in use?
The single biggest problem I came across over a decade ago when maintaining an open source PHP web application was web applications at the time typically having access to a common database server role (often also common between users and administrators) which allowed a web application process to read and sometimes write to the entire database. No use of user-specific roles in database servers and row-level-security/column-level-security authorisation. At the time I don't think PostgreSQL even had row-level-security support built into it. A runaway PHP process could return the entire database to the attacker, or change every single row of data held within the database.
The second biggest and related problem was web applications accepting files uploaded from users, or having to generate reports (maybe with external software) and save them to disk for a user to download, and not being able to ensure a runaway PHP process can't just dump all of those files or reports to an attacker. You might have been able to store the user files (or at least a decryption key for the files) in a database but then you're back to dealing with problem (1) above.
Even a decade ago it was fairly common for web application developers (of the PHP sorts too) to be well aware of the need to make their web root read-only, put the web application source code into a read-only directory outside the web root, execute interpreters such as PHP with "nobody"-like permissions, launch a new interpreter process for each connection (not multiple threads within the same process), firewall off the server the web application sits on so a runaway PHP process can't connect to internal servers, etc. Outside of an attacker messing with a database, most other aspects of PHP web applications at the time were immutable if the web application developer / system administrator had setup the environment correctly.
Is there a solution for (1) and (2) for PHP web application development that has become popular in the proceeding decade?
edit: also nominating the shared $_SESSION state of PHP that was typical a decade ago to just be left to default (e.g. all PHP processes just read/write session files to a common /tmp directory). https://www.php.net/manual/en/function.session-set-save-hand... should probably instead be used by web application developers to somehow better isolate session state between users.
As far as I can tell none of this is related to the current vulnerability in PHP itself. Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.
A dynamic language having access to all of the files it has access to is not unique to PHP. Vulnerabilities are not unique to PHP, and I doubt the Dutch National Cyber Security Center took their website offline because they lack user-specific roles in the database: https://www.ncsc.nl/index-en.html
So maybe save your elitism for a day when so many of us aren't already putting out fires? Congratulations on not being part of the 75% of the internet affected.
PHP is definitely more at risk of this class of vulnerability because fatal errors are longjmps which skip resource clean-ups. In a runtime with real unwinding, this exploit class can't exist.
> Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.
Vulnerable but perhaps with no impact. If you've setup your web server well, the vulnerable PHP process is sandboxed, at least to some degree, and an attacker executing their own code within the compromised PHP process can't move laterally through your internal networks, write files to disk, read files from disk, etc because you've locked down the PHP process.
In 2026, perhaps it's possible to:
1. Use systemd socket activation with Accept=yes [1] and strict sandboxing applied to a systemd service that executes the PHP interpreter. The result being each incoming request is dealt with inside an isolated PHP process spawned specifically to handle the request. Compromise of a PHP process doesn't impact any other concurrent requests, or any future requests, except through defined sandbox interfaces such as access to a database server socket.
2. For each user of the web application (perhaps including an 'anonymous' user too if anonymous users have access to dynamic content), if using PostgreSQL, create a role in PostgreSQL for each web application user. Then use row-level-security permissions and security barrier views within the database, and have the PHP process accept credentials from the user which are then needed to be passed through to PostgreSQL to login as that individual user.
It's not without some significant downsides:
1. It's complex and you might be the only person in the world trying to use PHP in this secure way. And if you're going this far, for a complex web application, it'd be best to split it into smaller web applications each with their own systemd service defining specific sandboxing constraints. E.g. microservice architecture where "login", "file upload", "user administration" are all separated with different sandboxing constraints applied to each.
2. Performance will suffer and you'll need more resources--for spawning new PHP processes from scratch for each request (although this is already the case with php-fpm which is most widely used), and for dealing with row-level-security in PostgreSQL (see e.g. LEAKPROOF functions).
The more common pattern I've come across on public websites in recent times that might mirror some of the above is client-side JavaScript dynamic rendering with API calls to a GraphQL database exposed on the Internet (using e.g. field-level access control). The user isolation problem is essentially pushed from PHP+PostgreSQL to a GraphQL implementation.
PHP has been the worst thing to happen to the web. It was insecure many decades ago and still is. Even CGI with C is probably more secure, never mind technologies like Java, ASP.NET and Rust with are far more secure.
I even have a preference for web stores which use ASP.NET or Java since I know my personal information are safe there.
There are probably thousands of web stores using PHP unwittingly too. I've noticed only about half of them have been taken offline.
Kind of seems like they just shut down their PHP service like everyone else... If this is the case, hopefully they can set up a temporary static site to inform about relevant updates.
Talked to my clients this morning and persuaded most of them to shut down the services and wait for the patch. For most of them it's cheaper to lose a day of work than to pay for recovery. Scary to be in a situation where you have no fix/workaround in sight.
Surprising that this sort of vuln can exist for DECADES. Perhaps software really is too complex for all its behaviours to be outwardly visible. Many student-run services are down right now, even the lunch menu website is going down for maintenance.
I mean we do have examples of how to try to make actually proven and secure software (of course still not absolute), but this is simply deemed to expensive. It's basically the same for every other big problem. We do have examples how to not consume as much resources, as we do now, or how to not shoot explosives at each other. We simply do not want to do it, collectively speaking.
how does Docker not yet have a new, official PHP image ready? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are :20 minutes past due. Everyone had a multi-day heads up, this is negligence
What an awful video, not only because of the content of many PHP-running sites being exploited, but also because of the awful glitching and vignette effect, an odd dancing anime girl at the bottom and the horrendous music.
For those of you using PECL as part of your image build pipeline. I'm seeing timeout issues downloading packages. PECL has been deprecated in favor of PIE. I'd recommend switching to PIE if your build relies on PECL. You don't want to run into this as you rush to update your images.
I got into software dev because of cyber sec, and almost everything I learned revolved around poorly implemented php, so I always stayed away from it when building
There are regular security patches for basically everything these days, including OSs. Why does this notice stand out to you? The post suggests that they're being proactive, and discovered and patched these before they were exploited. Rather they take this transparent approach, as opposed to being silent and/or doing nothing.
This one stands out because it's trivially exploited over the internet on the default configuration for all PHP versions. Most vulnerabilities require being able to run malicious code on the machine or using some rare configuration.
If the rumors going around are true this will be the worst computer security incident in history.
If you use Nginx, you can temporarly block the subject by disallowing multipart sendings to PHP. This is quite a problem for a lot of forms, but way better that being hacked.
Here is an Nginx patch :
if ($http_content_type ~* "multipart") {
return 403;
}
You can also turn of session progress in php.ini as mentionned but that does not seem to cover every cases :
session.upload_progress.enabled = Off
Have you tested this against a POC to see if it actually mitigates? Seeing a lot of proposed mitigations but with very little detail about whether they worked or not.
It assumes PHP frees the upload progress data when it reloads the session. But PHP 8.4 (the one we use is 8.4.24, i don't know for other versions) calls Z_TRY_ADDREF(progress->data) to keep that data alive. The fake function call also seems to contain invalid fields.
This makes me question this particular PoC, not the official PHP security warning. I have not reproduced the exploit, so this is a concern based on reading the code, not proof that the real vulnerabilities cannot be exploited.
But anyway the CVE still exists, and the exploitation is tied to multipart, disabling it seems the best thing you can do now without shutting everything down.
PHP as it is desperately needed the speedups in the 7 and 8 series releases to be relevant, performance loss of that magnitude is simply not going to be accepted anywhere
I help manage a few sites hosted on WPEngine, and taking them down is not an easy call to make. After making sure that our environments had the latest everything (WordPress version, PHP version, all plugins and themes on the latest), I contacted WPEngine support briefly.
They're on top of it as I would expect any major PHP hosting service to be. After asking if there was anything I could do to prep for php2shell (seemingly not), I just pleaded to be first in line when they apply patches and let them go.
How are others in similar situations handling this?
The exploits seem to rely on multipart form submissions. In a normal setup, I don’t believe PHP’s multipart parser processes GET requests.
Therefore, a temp mitigation that runs short of shutting your site down is to temporarily block POST requests until you can get the patches in place. This will screw up any form functionality, including your WP login form, but keeps your site presence up. A failed form submission is probably a better look than no site presence. You can affect this with Apache config or by using a WAF. For instance if you have cloudflare caching your domain, use a free security rule to block all POST requests until your patches are in. Something like `http.request.method in {"POST" "PUT" "PATCH" "DELETE"}`
I like PHP and I use it everyday. What concerns me about incidents like this isn't just the vuln itself, but how much access a compromised PHP process can have to the rest of the system.
That rumor is false, probably because Calif, the firm that discovered the exploit also just published an OpenBSD ASLR bypass people think they must be connected.
Php2shell is completely language level. By the time the OS sees it it's just a function of the webserver.
I would really like a list of all major websites using PHP so I can continue to avoid ever using them again (something I already try to do). This whole situation should make it clear who was affected by their downtime in response.
It is other way around, it was a top post, but AFAIK anti flamewar measures kick in when there are many comments compared to up votes. I mean it isn't bad heuristics when discussion already shifts in "PHP bad" direction.
Unsure what the correct response from the PHP team is here - I hope there's been plenty of work done behind the scenes to mitigate this on unpatched servers because there's not a chance defenders win the race everywhere it matters once the patches are out.
What steps can someone take to determine if they might have been hit?
So far, I have checked to see if any new files have been placed in our directories or if there have been any file changes. I've also looked at the access logs for unexpected POST requests.
If your application is known to routinely "deserialize" (unsafe-eval) strings from a database or cache, an attacker might have placed a tiny backdoor that way, only to be used after the everyone has applied the PHP patches and attention levels & active staff are back to normal.
I actually looked through PHP code responsible for parsing POST request body and it's pretty bad [1].
First, there is a huge function, that is hard to read and reason about. Second, instead of proper parsing of "Content-Type" header to extract "boundary" parameter, there is just a set of substring searches which is not correct. It doesn't mean there is a vulnerability but it means PHP can read the header in a way different from a standard-compliant implementation (such as web server, WAF etc).
In terms of taking sites/applications down, if you have a maintenance mode that serves only HTML does that seem sufficient at the moment, or is the mere presence of PHP on a server enough right now to warrant "entire server, off button"?
The previous presence of PHP and its oftentimes ridiculous common practices might mandate a maintenance mode that is a little more involved than just serving HTML.
Many modern hosts run php in fcgi mode, where your app is a process that listens on some http port. And where the webserver is "just" a proxy and ssl termination. Shutting down the process is enough.
But traditionally, php was a module loaded into apache. Where apache not only handled ssl, http etc, but also compiled and ran php for you. With that setup, adding an html file, will keep the php runtime and app online.
If the oauth wall is managed by PHP, then it looks like the answer is yes, you’re vulnerable to client connections that haven’t logged in.
This looks like a bug in PHP’s assembly of multipart responses & you can feed one of those to the PHP backend with a simple web request, no auth required I think.
If you put the oauth wall in front of the application before it can even reach PHP (i.e. in your nginx/caddy/apache config), then no, assuming all paths are covered.
So, theoretically, if you wanted to hack a server but you don't know what OS/PHP, version they're running, you could compile a list of every delta for every litespeed release and then bruteforce it, right?
Not necessarily. Most apps should build in reproducible way these days. That means you can compile the same versions and likely get the same offsets. (+/- custom options applied to your local system)
Only 53 comments for what's most likely going to be the biggest vulnerability in history? I don't understand how this isn't getting more attention. The exploit is already out and it's basically shell access on any php website out there.
It's also very early in EU and evening/night time in part of US. The information that was out earlier was on level "make sure you update tomorrow when the patch comes out", the actual details weren't out yet.
There are some vulns that warrant a pre-release announcement (in the Drupal community, this happened for a few of the more serious fixes). And prior to the public pre-announcement, there is often informal coordination between some of the larger hosting providers or giant companies who can help roll out the patch more quickly.
The proof of concept works against any PHP server (5 and up) running in the default configuration, leading directly to RCE without authentication. The PoC out there can be defeated by disabling multi part uploads.
The PoC also requires a known binary to exploit so custom PHP builds may be safe if you're lucky, but this seems to be an extremely bad one.
Apparently, any PHP server that accepts a POST request is vulnerable to arbitrary code execution on the host (from the FPM user?) with no defense. This is DEFCON 1 of internet security: 70% of all websites are currently vulnerable until 14:00 UTC tomorrow with zero escape hatch other than blocking traffic.
That's not likely to happen. You don't even know what the exploit is.
Anyway my point is I'm much less likely to get hacked in this new era of AI assistance, as I'm only a few days behind, rathe than a few months or years behind.
God damn Claude (Opus, Fable, either) is not even helping because of their god damn shitty safeguards. Thank you, Anthropic, for letting bad guys win. I can't tell you how much I want open-weight models to work at home that can handle this type of work in the future without bullshitting about safeguards.
these safeguards are insane. codex would do some fix, them say "hm, my change has introduced a vulnerability. let me write a test for it and then do the fix" and the safeguard stops it.
This seems serious enough that I've contacted a few less-technical loved ones about it. I'm warning them of possible scams in the next days, perhaps even hosted on otherwise official pages.
PHP don't support it and likely won't patch it (even though this is probably big enough that they should), it's up to your distribution whether or not they will.
It's going to be hilarious if I'm not vulnerable because I'm running PHP like it's 1995 via CGI and so get a brand new process per request and break ASLR infoleaks by side effect.
A PHP core dev suggested all the mitigations getting posted are not enough and that if possible you need to shut down any PHP app until the patch comes out https://phpc.social/@Girgias/117476510850918355
I'm a sysadmin that manages several servers, I realized I was vulnerable and reproduced what I found on our systems, it appears that simply disabling progress with php_admin_flag session.upload_progress.enabled Off renders the exploit inert...
I don't know if people understand that this actually lowers their reputation, instead of increasing it. Putting so important text as AI slop. Maybe it is not so important, if not worth of modifying themselves.
Once the dust has settled, it would be interesting to give LLMs the pre-patch source code and see whether any of them can identify this chain of vulnerabilities. Even if they can't identify the full chain, can they at least spot one of the constituent bugs and recognise its seriousness?
The original exploit, and then when the rumors of a big critical patch got out, the people who are leaking the details online probably used an LLM to find the exploit again.
Just revealing that an unpatched exploit exists in $XYZ these days basically guarantees that a bunch of people are going to target $XYZ with LLMs looking for that exploit.
Wow, that's a terrible one. Shut down old apps (that I'd forked and upgraded to latest) I had that were PHP. Sadly, my blog was on Mediawiki and so I've got to turn that off too. Tomorrow we learn.
EDIT: Ha, Claude just took the blog and rendered all pages and now it is a static site! I'll restore the Mediawiki once I can fix the issue.
So all local universities have now essentially shut down
their web-services for students. This is ... kind of
curious because now you can not download recent updates
(e. g. new .pdf files published) from that software.
We need a long-term solution with regards to PHP. PHP
is a success story - so much web-software depends on it.
But it also has become a liability when they are all now
scared that the server can be easily taken over. This is
not acceptable, PHP.
PHP has been a security dumpster fire for decades. It's just how the entire web ecosystem works: some web designer lacking any technical know-how is asked to make a site and dumps WordPress on it out of habit.
Even though there are much more secure CMS technologies out there like Umbraco or Piranha (both ASP.NET) and web stores like NopCommerce (ASP.NET also).
There are just too many technically clueless people building web sites and web stores.
Rather than taking your site down tonight, if you have cloudflare handling your DNS, orangeclouding your domain, you can use its free security rules to just block all post requests until tomorrow rather than taking your whole site offline. Drop this into a rule: `http.request.method in {"POST" "PUT" "PATCH" "DELETE"}`
Of course you can do this with web server (eg Apache) config as well, but the CF rule is something you can do now on your phone.
I’m not saying I know this works as a mitigation, but it seems like it could at least contribute to a temporary guard until you get patch in place. Everything I’ve seen about the exploits seem to revolve around multipart form submissions.
Don’t forget to firewall your webserver so it will only accept traffic that actually went through Cloudflare. This is the most false sense of security one can get.
Haha you’re right, but the skill you need to be good with is probably eye strain tolerance. But must needs and all. :) If you don’t use a WAF of some type, the risk is probably sufficient to warrant firing up the laptop tonight or worst case use the phone.
I am seeing a lot of words like "unconditional" thrown around but I remind that defense in depth is a thing and you can practice it, or should have been practicing it. You can, for example, disable the `system` function of PHP altogether. You can also arrange for your PHP to be running in a situation where there's no shell, or any other program, to exec. Or for that matter a filesystem.
It's a RCE bug, it does not matter if you disable php functions. It's not arbitrary PHP execution, it's an exploit chain resulting in arbitrary code execution.
Indeed, an attacker theoretically can access anything the PHP process has permission to access. However even without limiting permissions (also a good idea) that means the simple/published exploits won't work on your server, and there's a high chance criminals will look for other targets, assuming you're not targeted.
no idea why this is downvoted. PHP runs typically on linux machines. If you depend on a language feature to prevent 'exploit' and don't utilize the operating systems features to limit access to data.
Shell access is not good, but in many places that wouldn't be the end of the world either.
If your PHP application accesses a database, you've got exfiltration, it doesn't matter in this case. Unless your PHP application is just echoing non sensitive data (i.e. rendering md files)...
<p>Due to an <a href="https://www.php.net/archive/2026.php#2026-10-20-1">upcoming significant vulnerability disclosure</a> with no official mitigation, services are currently offline as a precaution. Services will not be restored until at least later in the day on October 21. This time may also be spent on additional maintenance, so this message may be periodically unavailable.</p>
> The OpenStreetMap.org operations team have decided to temporarily shutdown a number of key secondary OSM.org services due to a critical PHP security vulnerability.
I don't want to jinx it but... A discussion about, of all languages out there, PHP being the one hit by that and not, say, Go or Java or Rust or Haskell etc.?
Can we discuss that at least a tiny bit?
How do people feel about running servers with PHP today?
I don't think most people that use PHP use it because they love it and find it a great technical solution, it's mostly technical debt being maintained and the fact that PHP is available to host everywhere.
I mean no language is immune to issues. Java world constantly sees fixes for both JVM and libraries. For example, besides famous log4shell, you can see still see in HTTP access log that bots are checking for vulnerable Struts versions. On the other hand, Java pushed to 100% Java (no native code) database drivers, while PHP strongly relies on c/c++ extensions, cause PHP is/was too slow.
If there is any other difference, I think it just comes to legacy PHP approach - memory management didn't matter if entire request (and forked process that handles it) was alive for maximum few seconds.
These issues tend to happen way more in languages that depend on a runtime, especially one with dynamic lookup capabilities. If I remember correctly, log4shell depended on dynamic class loading and a lot of runtime-dependent stuff. Languages that are statically-compiled and memory-safe (namely Go and Rust) don't have the runtime vector and don't generally have the memory safety vectors either. I feel a lot safer deploying services written in Go than JS, for example.
A rewrite would tackle the classic C-style W^X problems, at the expense of maintainability and focus on logic bugs and general oversights from inelegant (or lack of) design. And I'd bet PHP (and popular PHP software for reasons rooted in the language) still got plenty of the latter. You know, the "oops, that filename was client provided" kind of code execution that no amount of (un)safe blocks can help with.
Bun isn't an interpreter. It uses JavaScriptCore for that, which, you guessed it, is C++. As far as I know they have no plans of rewriting it in rust either. Your hot take doesn't seem to apply here.
A reminder, because it really needs to be said, that they spent millions of dollars in tokens for the claimed 11 day sprint, and then spent an additional 3.5 months fixing hundreds of issues it introduced before actually releasing it. Long-term maintainability remains to be seen.
Because some upstream services here in central Europe,
are closed down because of that PHP problem. So now I
am annoyed since this disrupted my workflow.
PHP, please either get your act together - or disband.
NodeJS and Java are in a similar place (this CVE is a memory safety issue in PHP's C-language interpreter) but Go's compiler/runtime is written in Go and is memory-safe all the way down to the assembly.
I hope that people will realize that PHP is unsuited for public websites and that they need to switch to secure technologies like Java, ASP.NET or Rust.
PHP contains an almost endless stream of vulnerabilities since its inception almost 3 decades ago. Proponents claim that it's getting better but this just goes to show that nothing's changed.
Writers/editors really, really like Wordpress for some reason, which is like 40% of the Internet, add to that all the other Php stuff. At $DAY_JOB we have a Wordpress instance behind our VPN and use the json API to send the articles to a front-end server written in something else. Forces us to duplicate some of the front-end plugin code (and we try to not use many) but we get peace of mind in exchange.
Just as a scripting language on my own laptop, nothing prod. But one thing I notice, even coming back to it after a little while, even after using Python for everything, I find I am effortlessly productive with it.
There was an article I read recently about a blind developer who finds it easy to write in, as the "$" for the variable names makes it easier for him to identify what's going on in any given line of code.
Like any language it has advantages and disadvantages.
The "Syntax as landmarks" section sounds like he's comparing it particularly to Python. The quirk of `$` denoting a variable did kind of work out for him. Especially compared to Python where you declare a variable by assigning it. But it's not like PHP was designed with a special character for each syntax role. He still needs to use context to infer other roles.
PHP has the advantage of being preinstalled or easy to install in a lot of environments. I had to investigate the blind developer thing because I'm still on the hunt for a second advantage.
I think the ubiquiti edgerouter admin interfaces use PHP. I don’t know about mikrotik, but wouldn’t surprise me if there are a lot of those devices hanging off the internet on some nonstandard port.
Fixed versions have been released slightly early, along with full technical details:
https://www.php.net/archive/2026.php#2026-10-21-5
RCE via OOM corruption - https://github.com/php/php-src/security/advisories/GHSA-w8hw...
RCE via stale global state - https://github.com/php/php-src/security/advisories/GHSA-6wmf...
The PHP Foundation's official writeup of the vulnerability and details about the timelines to disclosure + fix: https://thephp.foundation/blog/2026/10/21/todays-php-securit...
From what has been coming out, this vuln has been known for a while. So they had time to have the patches, etc all prepared, and push everything out.
Still waiting on container updates and package updates. Not a peep from cpanel or plesk. What a mess
cPanel might not have said anything but they have patches available
1 reply →
So the proposed mitigations (block multipart forms, disable upload progress) are actually helpful (if not necessarily sufficient).
Fyi updated versions are now available for the Gentoo Linux distribution: https://packages.gentoo.org/packages/dev-lang/php
(I just ran an "emerge --sync" but the mirror that was used does not have yet the updates)
Ubuntu's updates have hit their package archives too:
https://ubuntu.com/security/CVE-2026-109618
Really, all previous PHP versions are affected?
Are there security patches for servers running old versions?
There are so many keeping old php versions alive for compatibility with whatever software
7 replies →
There's also this writeup: https://www.wiz.io/blog/php2shell-php-rce
It seems to have a few more technical details.
Also released on Docker Hub now
Are they though?
1 reply →
FreeBSD ports tree has the updates in their git now.
[flagged]
https://news.ycombinator.com/item?id=50180987
[dead] ?
1 reply →
How would that work for the OOM cases?
1 reply →
"If you don't want to be vulnerable just install this vibecode project from a 10 minute old repo someone posted."
Doesn't really feel like it's a good way to handle security to me.
3 replies →
Many here call for an earlier release of the patch.
But it is not clear if releasing the fix early would make the damage smaller or larger.
Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
There is no way to coordinate the whole world on an earlier time. I would guess the number of people who have to patch their instances is in the hundreds of thousands.
Everybody who actively watches the topic already has the option to shut down their instances.
So ringing the bell and getting as many people as possible to shut down their webservers now and patch at 14:00 might be the best in terms of damage minimisation.
By the way, it is not enough to just "shutdown -h now" and then later restart and "apt update && apt upgrade". The moment the machine comes back, it can get hacked. So you should make sure the webserver does not start after the next boot. For Apache this would be something like "rm /etc/systemd/system/multi-user.target.wants/apache2.service" and then after patching recreate the symlink via something like "ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/apache2.service".
There are several PoCs, and according to Cloudflare, the vulnerability is already being actively exploited: https://x.com/dok2001/status/2112811965735202970
> Everybody who actively watches the topic already has the option to shut down their instances.
In theory. In practice, many can't just decide to shut down their service for a few hours.
Guess they can decide to let random hackers all over their server instead.
14 replies →
There's an exploit freely available already, by the way. You can't contain things like this.
If not, you or our agent could build an exploit from the information that's already out.
Are you 100% sure? I have tested 2 PoC's against my dev environment, no luck so far. So I am not sure if there is working exploit already.
I have not seen confirmation that the exploit is for the bug that is going to be patched.
It seems the published exploit can be easily prevented by filtering out multipart post requests. So people actively watching the situation can already prevent that issue by filtering those.
I was able to cook up something in less than 10 minutes and tested many sites. There is a page with enough explanations to do it.
4 replies →
fwiw it looks like the patches were made available early on chainguard
https://images.chainguard.dev/directory/image/php/versions
How does it work that some service that most people never heard of distributes (paid) images with alleged fix for vuln 24h before official vuln fix/image is available? Seems somewhat shady.
2 replies →
Is there a public announcement? I can only see PHP 8.5.11 images, but having a recent build date is not enough to say they are indeed patched.
1 reply →
I can almost confirm a Wordpress site I manage was attacked with this. Oct 5th updated it to latest php and Wordpress. Oct 6th it was exploited with a web shell exploit
On the other hand: it is Wordpress, who knows how many other exploits could be hiding among the dozens of plugins it likely has installed?
this is not a web shell exploit. This goes to container shell level. Very different scenarios.
What ultimately ended up happening?
Yeh this isn't that.
systemctl mask/unmask
> Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
I think that this made sense a few years ago but in today's world it is so feasible to give an LLM a hint and throw some cash at it to find an exploit that I don't think this calculus makes sense anymore.
> Having the patch probably makes creating an exploit easier. So the number of attacks would increase.
No matter the excuse, the security issue must be fixed. Anyone trying to delay this is not acting in good faith. I understand your rationale but that does not excuse you from being labelled as such too.
We should live in the age of open source AT ALL TIMES. No exceptions, for anyone, no matter the reasons. And that includes those who want to withhold code or patches.
You might disagree with them, but I am pretty sure the php maintainers are acting in good faith.
1 reply →
DigiD.nl (login to government services), RTL (major broadcaster) and parliament shut down their websites. https://nos.nl/liveblog/2636066-websites-kwetsbaar-voor-soft...
Looks GovCMS decided to do the same thing, that means the vast majority of Australian govt websites are now offline... insane stuff
I'd be worried about websites not shutting down immediately. It's better to wait few hours than being hacked.
1 reply →
Even worse, Tweakers as well :(
Not Tweakers!!
Seriously though. I don’t know what’s best. Taking everything down or not.. I just run a small time SaaS.
5 replies →
I've tried to take one website on a shared hoster down. But I actually can't disable PHP there at all. So no idea if just taking down the website will fix it. Probably PHP won't get executed if no .php files are served, but I'm not sure.
it's a shared host? So the hoster should have shut it down?
1 reply →
University of Vienna also took a lot offline. Seems it's getting patched fast now, though.
Edit: Or maybe not? At least one service on their IT-department's list seems to be working again. :-)
For everyone wondering why the patch is not out yet:
There are a handful people responsible for doing a release. They are still asleep.
To be honest, I am also shocked, that the exploit was published that quickly, after the leaked video (which was the reason, why the announcement happened in the first place, at that specific time). We expected a bit more time, even with LLMs...
https://images.chainguard.dev/directory/image/php looks like patched builds for 8.5-8.2 are available here
We've been working with the team on the coordinated disclosure, but I made the call to get these out early when exploits hit in the wild.
The vulnerability and patch are both very complex, and the maintainers did an incredible job on this one. We tested the patch extensively and it's holding up well.
We've made these images free and will keep them that way.
22 replies →
today only a rumour of a bug is enough to find and replicate it quickly.
anything that narrows the searchspace
Good for them to be able to sleep the night before this chaos was meant to erupt, earnestly.
Hopefully the industry will learn something about how withholding fixes to known vulnerabilities is, in fact, bad policy.
How? Biggest organisations and shared hosting providers had a chance to patch and protect their users. Everyone else will learn about the vulnerability the second patch comes out (this is also fixable with a configuration chance, so nobody needs to wait for their distro). This was the right approach and it worked.
5 replies →
> the industry will learn something
This is something of a fallacy. "The Industry" cannot learn.
But laws and regulations can require better security.
As in the history of seatbelts in vehicles, tech tool stacks are insecure by design and no one is ever really held accountable... until the cost is deemed too high.
It's evident that we have not reached that limit yet.
This is nonsense, disappointed to see that publicly from a core dev. Yes, some people are asleep, but the decision was made to wait, to ensure the patch is only made available when users are actually able to install the update and we're giving distros the time to build PHP packages.
> We expected a bit more time, even with LLMs...
That's horribly naive with an installed base this size and if you are that geographically dependent then I would hope to read how this will be dealt with going forward.
So how much do you pay the php foundation for 24/7 support?
1 reply →
Honestly, kindarails2shell resulted in a responsible disclosure coordination followed by the decision to release early since it was reversed too quickly. Even just a hint of a 0-day is enough to cause people to look for it and exploit it with LLMs.
[flagged]
lmfao what... If the police woke me up to fix anything the only thing they'd get out of me is "lawyer". And I wouldn't put a single iota of effort into fixing that thing until the entire matter with the police was resolved. If you want someone's attention on something, especially something nuanced and intricate like a software bug, that's absolutely not how you get it.
13 replies →
[dead]
Given that this affects every PHP version from the past decade, and that the exploit instructions are circulating at the top of twitter, and that there's no fix available yet, it doesn't seem outrageous to assume every major PHP website is already compromised?
The upgrade instructions here should include torching your hosts and starting again.
I would assume that in many (smaller, non-professional) systems/code bases, it is also possible to poison the backups and code base in general. This would have been a major effort in the pre-LLM age, but it should be pretty easy now. As soon as such instructions are out there, people (or rather LLMs) are going to find ways to make the threat persist.
It's time to have the conversation about killing PHP again.
We don't really need it anymore now that we have LLMs.
20 replies →
Yes. Even if you are not running PHP yourself, you should now prepare for:
- Any PHP site you ever put your email/password/personal data in being hacked over the next few hours (especially things like forums).
- As a result of the above, a massive wave of phishing attempts.
- Corporates/Admins panicking and turning off services as a precautionary measure over the next hours or days.
That's not panicking.
What else do you expect them to do? Pray?
Switching something off is far preferably over being hacked.
1 reply →
It's not really panicking when CERT-EU is literally suggesting this (in the comment text of this story)
1 reply →
It’s probably advisable to go through your password manager and start deleting any accounts you no longer use. And of course make sure that you have zero shared passwords
The exploit is already out. Yeah this looks like it's going to go on history as the worst vulnerability ever. And now with LLMs you'll likely see tens of thousands of agents hacking any php website out there within hours.
Yup, I'm seeing several legit people on X claiming to have seen or found the exploit. Some say that: turning session.upload_progress.enabled off and setting file_uploads = Off will mitigate. But others are claiming that those steps are not enough and "Upload progress can serialize before basic RINT clears BG(serialize)". So, I'm taking no chances and taking my services offline.
https://x.com/MagicalTux/status/2112725774025572431 https://x.com/rina4_tot/status/2112723421641531772
I think this exploit + agentic AI (which allows for rapid secret exfiltration/utilization) may be a potent enough combo to trigger a sort of Kessler Syndrome for network security.
If the problem is in the parser then `file_uploads = Off` doesn't help, PHP still parses the multipart body. That seems to be why they're talking about blocking multipart/form-data on routes that don't take uploads and rate-limiting those that do.
Mark Karpelès? Wow that's a name I haven't thought about since 2014.
2 replies →
> sort of Kessler Syndrome for network security.
why it would be a thing, beyond "serious problem"?
> Yeah this looks like it's going to go on history as the worst vulnerability ever.
lol no.
I feel old. Heartbleed was 2014.
Log4Shell was worse than Heartbleed and it doesn't seem totally outrageous to say that this might be worse than Log4Shell.
6 replies →
I think the exploit itself of Heartbleed was worse, but the impact size of this will be greater.
Measuring “worst” is hard.
I don't think a PoC was publicly available for Heartbleed before patches? I may be misremembering.
> Yeah this looks like it's going to go on history as the worst vulnerability ever.
Thanks, PHP.
> Yeah this looks like it's going to go on history as the worst vulnerability ever
Yeah no.
This is bad but doesn't even crack the top ten.
Which ones would you say are worse, and why?
2 replies →
The patches are out: https://www.php.net/archive/2026.php#2026-10-21-5
>PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
I get that maintenance teams need to have conviction in this approach, but this is definitely going to cause catastrophically large data breaches downstream.
Two bullet points down from where you’re quoting:
> Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
None of these 2 CVEs seem relate to POC spread in twitter. I'm not sure if the POC is something fake or they just unveil something within a few hours..
Scroll down in the actual patches to the weirdness of the multipart parser. That very much looks related to the what can be abused via the upload progress callbacks that had been discussed on (anti)social media.
I was hoping with the delay nixpkgs would come with a fix.
There aren't even official docker images yet
5 replies →
Where? Not out yet
Caching. Try adding a query parameter: https://www.php.net/archive/2026.php?a
https://www.php.net/archive/2026.php#2026-10-21-5
https://www.php.net/downloads.php?source=Y
It's really up.
1 reply →
[flagged]
Just made the call to take all my customers apps offline until this is fixed.
Can’t find any reliable information on what to do prior to the patch, seen some info that turning off session progress does not mitigate.
Anyway.. back to calling everyone
I took my services offline last night, wouldn't have been able to sleep otherwise. There has been core PHP members that have outright said the mitigation's currently doing the rounds won't help and even cloudflare can only mitigate against known attack payloads.
The maintainer's comments are singularly unhelpful - "there's nothing you can do, just curl up and die" is pretty useless when you're faced with "take the entire company site offline" vs "maybe get exploited."
8 replies →
Cloudflare: "We are seeing early attacks emerging and are updating mitigations as new vectors show up."
https://x.com/dok2001/status/2112811965735202970
When will they finally release the patch?!
Mindboggling, wtf don't they release it if its ready and exploit is in the wild, its a lot of time until 14:00 UTC and a lot of websites will be breached.
They should have shut up, released a new stealth PHP version and told everyone to update ASAP. They gave way to many details ahead allowing some AI agents to find the vulnerability within half an hour...
15 replies →
They'll probably release it earlier, that's what they said in the announcement in case the CVE got leaked sooner.
if the attacks are live then PHP should release the fix NOW.
The reason we (used to) have responsible disclosure timelines is so that the information & software to fix vulnerabilities can be assessed, organised, written up. Builds could get built, attackers and defenders find out at once. But crucially, defenders could use the normal channels to fix their installations and be sure they'd covered themselves.
When a PoC drops before that timeline is up (like now!) the attackers get a head start because they have less work to do - just figure out how to use it to their payload, start spraying it out.
Meanwhile maintainers don't want release an incomplete or misunderstood fix. Otherwise they'd risk people updating and believing that they're safe when they're not. Even a fragment of misinformation from an official channel will spread like wildfire. So when you demand fixes NOW you're demanding something that may not be completely understood.
So (I'm sure we'll find out but) I believe this 2pm timeline was already as soon as is human possible for the PHP team to do a repsonsible job, and not risk us having to come back tomorrow for a fix to the fix.
LLMs gives attackers the advantage for a while, and it means we'll have to tighten the secrecy around even the rumour of a vulnerability.
9 replies →
Or you release a "mitigation" immediately (turn off feature X usually) and then release the patch.
2 replies →
The global Cloudflare Web Application Framework rules in question: https://developers.cloudflare.com/waf/change-log/changelog/#...
I tried it on a personal site, was able to dump the entire database. Immediately shut all my sites down. This is bad.
Years ago I migrated all my personal sites to being statically generated, since they don't have actual dynamic content anyway. That was a good decision.
Same here. And for the dynamic content, I host dedicated, small services, or client side code.
Not only 10 years of no more security updates. But hosting static content is cheap, performant and sustainable. Bot literally (you can move the content anywhere, using any kind of server) and in energy sense.
While I understand it is not for everyone to write markdown files and run build commands, I strongly urge anyone with a WordPress or drupal site to give the various jamstacks, or static site builders and guis a test run.
How can I try this to see if I should shut things down myself. I run a 6 figure stealth and have a day job for fintech in 9 figures all php so kinda worried
Used this as a base: https://jackalsyn.com/posts/php-up-2026.html
But created my own based on it since it feels sketchy running someone else's exploit poc ya know. Ran it first in a vm before running it against a production site.
18 replies →
You make 9 figures at a fintech? Are you hiring?
7 replies →
You use PHP at a fintech?
2 replies →
Given that the base you ran against was faulty and not actually RCE, I'm starting to get sceptical of the truth of your highly upvoted comment.
Was apparently enough of a lead for codex to run with (daybreak). Haven’t woken up enough yet to compare it to anything released yet.
Does the exploit need a framework like laravel or can it work with just plain php
No, this happens sometime in the request parsing process, any exposed php URL would be vulnerable.
Meh, I'll just roll PROD back to our 4.7 image, then head down to the pub for a pint until this all blows over... Only 3 years of data will be missing... No biggie! LOL :P
The demo video has been going around Twitter today and apparently the proof of concept is privately being shared around too. The video shows pasting something in the URL and then gaining a shell on the server. It looks completely catastrophic.
I think the best course of action is to just shut your server down before the patch goes live and then bring it back after you have patched.
The URL is to show the effects of the exploit. The person's running a python script that runs the exploit and then makes the PHP installation execute an arbitrary shell command. The proof of concept involves writing "pwned" to a publicly accessible location on the web server, then they refresh the browser pointing at the URL to show it's been written.
https://x.com/k_firsov/status/2112641845926989944
This is gonna rinse so many LAMP WordPress installs where the PHP version is either not getting a patch or the hosting is managed by the user via a contractor or the hosting is managed by a company with a fleet of custom servers etc etc.
I can think of some really ancient phpBB boards that probably won't ever come back if they get hit.
1 reply →
It's sad how many wordpress installs haven't been patched in a decade. they're so old even new exploits aren't supported.
2 replies →
We almost need some bot that logs in to every vulnerable PHP server and turns it off to prevent it being properly exploited before the server admin updates it..
24 replies →
dozens of thousands if not hundreds of Drupal 7 sites running php 7
From what I can tell, Cloudflare has mitigated this via their WAF [0] (free and paid).
The Alpine GitLab[1] indicates the PHP versions to be released 21-10-2026 14:00:00 UTC are:
8.5.12 8.4.27 8.3.36 8.2.35
[0] https://developers.cloudflare.com/waf/change-log/changelog/
[1] https://gitlab.alpinelinux.org/groups/alpine/-/work_items?sh...
Release notes draft filenames (but not contents) are published to the mailing list: https://news-web.php.net/php.webmaster/34116
Wow, it's the first time that I see the Cloudflare-equivalent error page of Bunny.net.
That got nuked by the looks of it.
1 reply →
We observed this update ourselves and suspected it to be a mitigation when it was rolled, but I can't find any definitive record that these rules are about the PHP vulnerability. Do you have more info?
https://x.com/dok2001/status/2112802620029223193
Let's be clear here: they provided a waf rule. You need to actually have it enabled to be protected.
On the free Cloudflare tier its enabled and you cannot disable it. On Paid you can disable it.
They enable this kind of rules by default and for free.
It looks like bunny have added their waf rule too for mitigation.
https://x.com/BunnyCDN/status/2112867273333485634
I have sites behind Fastly and Akamai, and I would dearly love to hear from either of them.
https://www.fastly.com/blog/fastlys-proactive-protection-cri...
I have one site on WPEngine and they haven't said anything [that I've seen]
1 reply →
where is patch for alpine?
finally released
This is notable enough that the prime minister of Japan has tweeted about it: https://x.com/takaichi_sanae/status/2112890642590564386
The POC video did have an anime catgirl. Maybe we're finally getting the cyberpunk dystopia we were promised.
Here's what I did at least.
I initially updated the following php.ini setting and verified that it updated via phpinfo(). I understand this to be only a possible mitigation (see below).
According to someone stating they are one of the PHP release managers:
https://www.reddit.com/r/PHP/comments/1xb2utu/comment/phyu5m...
I use Apache, and added an htaccess rewrite rule in my base directory to block all requests containing multi-part headers. Rewrite rules can also be added into Apache virtual host blocks. Accepting file uploads are not a critical function of the app in my case. This blocks multi-part form requests before they reach PHP.
And verified the non-block vs. block case. https://freeimage.host/i/nOqumyN
I'm continuing to learn about the situation and may take the server offline as I learn more.
The writeup I found here:
https://jackalsyn.com/posts/php-up-2026.html
Content from a couple of my ChatGPT 6 Pro sessions about the issue:
https://chatgpt.com/share/6ad89ea3-b2f0-83ea-9c4c-2ecf5cc24b...
https://chatgpt.com/share/6ad8ad3d-3f6c-83e9-abf0-41da8a0d65...
https://en.wikipedia.org/wiki/PHP2Shell
On nginx a stop-gap measure is to block all multipart posts before they reach the php code.
Add this to nginx.conf (or drop as a text file into /etc/nginx/conf.d/) :
Then in every 'location /' block for every hosted server:
Then restart nginx.
I've tested the CVEs on PHP 8.5.11 and `session.upload_progress.enabled = Off` definitely increases safety but it doesn't guarantee it. Use of plugins can open up additional exposure.
If you're behind CloudFlare apparently they'll cover you, issue is, some people don't have their web servers configured to block traffic NOT from CloudFlare, so it is kind of a bandaid that's falling off I guess.
I'd check this carefully and make sure you have the WAF enabled. I seemed to always have plenty of weird looking PHP and WP requests happily forwarded by CloudFlare to my servers.
Users on the Free plan have access to the Cloudflare Free Managed Ruleset, a subset of the Cloudflare Managed Ruleset.
https://developers.cloudflare.com/waf/get-started/
1 reply →
They only block most common attempts they have seen.
They can't cover you. Only proper fix is updating your server.
the writeup you found has been updated to reflect the fact that the exploits provided by the author are not as severe as initially thought.
This suggests they might not have been exploits related to the CVE in question, so what you did might not be enough, be careful.
This makes me wonder if they really vibe coded the whole blog post without verifying anything by themselves. This should stop.
1 reply →
and for caddy
Next will be block everything but GET, then static site copy, then administratively down
If the rumors for these exploits being shared on Twitter are correct this is going to be a nightmare. I wouldn't be surprised if VPS hosts step in to mitigate it somehow since so many cheap/unmaintained LAMP installs are running on those servers.
Two things you can do now:
1. Turn off session upload progress
2. Block multipart requests at the web server
More info: https://www.vincentschmalbach.com/cve-2026-109618-and-cve-20...
If you can afford it, shut down your PHP apps now until the patch is out.
PHP core maintainers themselves have said that only upgrading PHP will be sufficient: https://phpc.social/@Girgias/117476477429221001
That's why I suggested blocking requests at the web server level so they don't even reach PHP.
>multipart requests
is this multipart request smuggling again?
I think I see a way to overwrite suitable memory in the parser, so smuggling (as in: confusing another parser) would be purely for bonus points.
I'm keeping a list [1] of all the (possible) precautions one can take, ahead of the patches appearing in a few hours. Exploits are now circulating, according to Cloudflare's CTO, so _any_ mitigation is worth investigating
https://ma.ttias.be/php-cve-2026-109618-early-mitigation/
Your article contains:
> Both block automated requests, so I could not check their text myself.
Are you automated?
There's a disclaimer at the top that anything below the intro was largely written by an LLM. That section is updated now
Good resource!
I'm not seeing any discussion here about woeful web application architectures from the 1990s still in use?
The single biggest problem I came across over a decade ago when maintaining an open source PHP web application was web applications at the time typically having access to a common database server role (often also common between users and administrators) which allowed a web application process to read and sometimes write to the entire database. No use of user-specific roles in database servers and row-level-security/column-level-security authorisation. At the time I don't think PostgreSQL even had row-level-security support built into it. A runaway PHP process could return the entire database to the attacker, or change every single row of data held within the database.
The second biggest and related problem was web applications accepting files uploaded from users, or having to generate reports (maybe with external software) and save them to disk for a user to download, and not being able to ensure a runaway PHP process can't just dump all of those files or reports to an attacker. You might have been able to store the user files (or at least a decryption key for the files) in a database but then you're back to dealing with problem (1) above.
Even a decade ago it was fairly common for web application developers (of the PHP sorts too) to be well aware of the need to make their web root read-only, put the web application source code into a read-only directory outside the web root, execute interpreters such as PHP with "nobody"-like permissions, launch a new interpreter process for each connection (not multiple threads within the same process), firewall off the server the web application sits on so a runaway PHP process can't connect to internal servers, etc. Outside of an attacker messing with a database, most other aspects of PHP web applications at the time were immutable if the web application developer / system administrator had setup the environment correctly.
Is there a solution for (1) and (2) for PHP web application development that has become popular in the proceeding decade?
edit: also nominating the shared $_SESSION state of PHP that was typical a decade ago to just be left to default (e.g. all PHP processes just read/write session files to a common /tmp directory). https://www.php.net/manual/en/function.session-set-save-hand... should probably instead be used by web application developers to somehow better isolate session state between users.
As far as I can tell none of this is related to the current vulnerability in PHP itself. Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.
A dynamic language having access to all of the files it has access to is not unique to PHP. Vulnerabilities are not unique to PHP, and I doubt the Dutch National Cyber Security Center took their website offline because they lack user-specific roles in the database: https://www.ncsc.nl/index-en.html
So maybe save your elitism for a day when so many of us aren't already putting out fires? Congratulations on not being part of the 75% of the internet affected.
PHP is definitely more at risk of this class of vulnerability because fatal errors are longjmps which skip resource clean-ups. In a runtime with real unwinding, this exploit class can't exist.
you could just use a MAC-framework? like recommended for years...
> Even having a site that just returns echo "phone us on XXXX" is vulnerable apparently.
Vulnerable but perhaps with no impact. If you've setup your web server well, the vulnerable PHP process is sandboxed, at least to some degree, and an attacker executing their own code within the compromised PHP process can't move laterally through your internal networks, write files to disk, read files from disk, etc because you've locked down the PHP process.
In 2026, perhaps it's possible to:
1. Use systemd socket activation with Accept=yes [1] and strict sandboxing applied to a systemd service that executes the PHP interpreter. The result being each incoming request is dealt with inside an isolated PHP process spawned specifically to handle the request. Compromise of a PHP process doesn't impact any other concurrent requests, or any future requests, except through defined sandbox interfaces such as access to a database server socket.
2. For each user of the web application (perhaps including an 'anonymous' user too if anonymous users have access to dynamic content), if using PostgreSQL, create a role in PostgreSQL for each web application user. Then use row-level-security permissions and security barrier views within the database, and have the PHP process accept credentials from the user which are then needed to be passed through to PostgreSQL to login as that individual user.
It's not without some significant downsides:
1. It's complex and you might be the only person in the world trying to use PHP in this secure way. And if you're going this far, for a complex web application, it'd be best to split it into smaller web applications each with their own systemd service defining specific sandboxing constraints. E.g. microservice architecture where "login", "file upload", "user administration" are all separated with different sandboxing constraints applied to each.
2. Performance will suffer and you'll need more resources--for spawning new PHP processes from scratch for each request (although this is already the case with php-fpm which is most widely used), and for dealing with row-level-security in PostgreSQL (see e.g. LEAKPROOF functions).
The more common pattern I've come across on public websites in recent times that might mirror some of the above is client-side JavaScript dynamic rendering with API calls to a GraphQL database exposed on the Internet (using e.g. field-level access control). The user isolation problem is essentially pushed from PHP+PostgreSQL to a GraphQL implementation.
[1] https://www.freedesktop.org/software/systemd/man/latest/syst...
It's not elitism to call out bad practices
2 replies →
This.
The one gripe I'll have is that rowlevel security is slow and messy to use. If a design allows skipping it, it should be skipped.
PHP has been the worst thing to happen to the web. It was insecure many decades ago and still is. Even CGI with C is probably more secure, never mind technologies like Java, ASP.NET and Rust with are far more secure.
I even have a preference for web stores which use ASP.NET or Java since I know my personal information are safe there.
There are probably thousands of web stores using PHP unwittingly too. I've noticed only about half of them have been taken offline.
Looks like news-web.php.net is offline now?
It has been offline for the latest 3 hours for me.
Hopefully it didn’t get hacked…
Kind of seems like they just shut down their PHP service like everyone else... If this is the case, hopefully they can set up a temporary static site to inform about relevant updates.
1 reply →
[flagged]
Node.js has also announced security releases: https://nodejs.org/en/blog/vulnerability/october-2026-securi...
Unrelated, the Nodejs patch is to strip the emudhra certs, which is its own separate security incident.
Strange coincidence? Can someone see a potential connection here?
Yes, the potential connection is the fact that we now live in the age of AI.
Could be related to the eMudhra Intermediate CA compromise.
https://emudhra.we-have-a-problem.com/
1 reply →
There’s already a Wikipedia page for it: https://en.wikipedia.org/wiki/PHP2Shell
Doesn't Wikipedia run on PHP? Wonder what their mitigation strategy is for this.
https://wikitech.wikimedia.org/wiki/Incidents/2026-10-21_PHP...
They got an early heads up and have already patched, is my understanding.
Talked to my clients this morning and persuaded most of them to shut down the services and wait for the patch. For most of them it's cheaper to lose a day of work than to pay for recovery. Scary to be in a situation where you have no fix/workaround in sight.
Surprising that this sort of vuln can exist for DECADES. Perhaps software really is too complex for all its behaviours to be outwardly visible. Many student-run services are down right now, even the lunch menu website is going down for maintenance.
I mean we do have examples of how to try to make actually proven and secure software (of course still not absolute), but this is simply deemed to expensive. It's basically the same for every other big problem. We do have examples how to not consume as much resources, as we do now, or how to not shoot explosives at each other. We simply do not want to do it, collectively speaking.
how does Docker not yet have a new, official PHP image ready? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are :20 minutes past due. Everyone had a multi-day heads up, this is negligence
It was merged a minute ago https://github.com/docker-library/official-images/pull/22541
Just shut down our MediaWiki site temporarily out of an abundance of caution. The twitter videos look scary...
Here's the video (I think): https://nitter.app/k_firsov/status/2112641845926989944#m
What an awful video, not only because of the content of many PHP-running sites being exploited, but also because of the awful glitching and vignette effect, an odd dancing anime girl at the bottom and the horrendous music.
2 replies →
This is so scary, I will have anime-girl hacking the planed - nightmares for months now.
For those of you using PECL as part of your image build pipeline. I'm seeing timeout issues downloading packages. PECL has been deprecated in favor of PIE. I'd recommend switching to PIE if your build relies on PECL. You don't want to run into this as you rush to update your images.
That is definitely very not good.
I got into software dev because of cyber sec, and almost everything I learned revolved around poorly implemented php, so I always stayed away from it when building
but this time it's php directly? that's scary
There are regular security patches for basically everything these days, including OSs. Why does this notice stand out to you? The post suggests that they're being proactive, and discovered and patched these before they were exploited. Rather they take this transparent approach, as opposed to being silent and/or doing nothing.
This one stands out because it's trivially exploited over the internet on the default configuration for all PHP versions. Most vulnerabilities require being able to run malicious code on the machine or using some rare configuration.
If the rumors going around are true this will be the worst computer security incident in history.
10 replies →
I'm glad to not maintaining PHP services right now, this will be a historic event.
If you use Nginx, you can temporarly block the subject by disallowing multipart sendings to PHP. This is quite a problem for a lot of forms, but way better that being hacked.
Here is an Nginx patch : if ($http_content_type ~* "multipart") { return 403; }
You can also turn of session progress in php.ini as mentionned but that does not seem to cover every cases : session.upload_progress.enabled = Off
PHP core maintainers themselves have said that only upgrading PHP will be sufficient: https://phpc.social/@Girgias/117476477429221001
Have you tested this against a POC to see if it actually mitigates? Seeing a lot of proposed mitigations but with very little detail about whether they worked or not.
After digging a little in the PoC code (here https://jackalsyn.com/posts/php-up-2026.html) I'm quite confident it's not a completely working one.
It assumes PHP frees the upload progress data when it reloads the session. But PHP 8.4 (the one we use is 8.4.24, i don't know for other versions) calls Z_TRY_ADDREF(progress->data) to keep that data alive. The fake function call also seems to contain invalid fields.
This makes me question this particular PoC, not the official PHP security warning. I have not reproduced the exploit, so this is a concern based on reading the code, not proof that the real vulnerabilities cannot be exploited.
But anyway the CVE still exists, and the exploitation is tied to multipart, disabling it seems the best thing you can do now without shutting everything down.
2 replies →
I just took down my 10 or so sites until the fix is out. A few hours of downtime versus worrying something got injected in my cache or db
Not only injected, but they may also steal all your database data by dumping it.
Took a quick peak at the relevant C code and what I think are the offending lines seem somewhat suspicious right off the bat.
Fil-C should have caught this right? I wonder if it would benefit the PHP ecosystem as a whole if the releases are built with it instead.
PHP as it is desperately needed the speedups in the 7 and 8 series releases to be relevant, performance loss of that magnitude is simply not going to be accepted anywhere
I help manage a few sites hosted on WPEngine, and taking them down is not an easy call to make. After making sure that our environments had the latest everything (WordPress version, PHP version, all plugins and themes on the latest), I contacted WPEngine support briefly.
They're on top of it as I would expect any major PHP hosting service to be. After asking if there was anything I could do to prep for php2shell (seemingly not), I just pleaded to be first in line when they apply patches and let them go.
How are others in similar situations handling this?
The exploits seem to rely on multipart form submissions. In a normal setup, I don’t believe PHP’s multipart parser processes GET requests.
Therefore, a temp mitigation that runs short of shutting your site down is to temporarily block POST requests until you can get the patches in place. This will screw up any form functionality, including your WP login form, but keeps your site presence up. A failed form submission is probably a better look than no site presence. You can affect this with Apache config or by using a WAF. For instance if you have cloudflare caching your domain, use a free security rule to block all POST requests until your patches are in. Something like `http.request.method in {"POST" "PUT" "PATCH" "DELETE"}`
I've used Cloudflare rules, thanks. I've chosen to be a little more conservative:
1 reply →
hmm... how credible is this? appears to not be fully fixed?
https://fedi.katze.sh/@elise/117479383739450605
I like PHP and I use it everyday. What concerns me about incidents like this isn't just the vuln itself, but how much access a compromised PHP process can have to the rest of the system.
Even without that, with so many monoliths in php-land it's way worse than other stacks
Is OpenBSD affected or have all their schizo mitigations finally paid off?
Someone on X mentioned the bug relies on some kind of ASLR bypass.
That rumor is false, probably because Calif, the firm that discovered the exploit also just published an OpenBSD ASLR bypass people think they must be connected.
Php2shell is completely language level. By the time the OS sees it it's just a function of the webserver.
I would really like a list of all major websites using PHP so I can continue to avoid ever using them again (something I already try to do). This whole situation should make it clear who was affected by their downtime in response.
Looks like Plesk will backport the patches to old PHP versions (7.4 to 8.1) https://support.plesk.com/hc/en-us/articles/44397729587351-V...
This has been out for hours! Why is this not the top post here? It's climbing, and hopefully will soon be, but... This is massive, right?
I had to shut down my own backend services. Luckily a big part of my service can run on a static website.
It is other way around, it was a top post, but AFAIK anti flamewar measures kick in when there are many comments compared to up votes. I mean it isn't bad heuristics when discussion already shifts in "PHP bad" direction.
It was top post
Management doesn't want us to disable our websites. We got hundreds of client facing apps. We're just waiting for the patch
Unsure what the correct response from the PHP team is here - I hope there's been plenty of work done behind the scenes to mitigate this on unpatched servers because there's not a chance defenders win the race everywhere it matters once the patches are out.
What steps can someone take to determine if they might have been hit?
So far, I have checked to see if any new files have been placed in our directories or if there have been any file changes. I've also looked at the access logs for unexpected POST requests.
Are there any other steps?
If your application is known to routinely "deserialize" (unsafe-eval) strings from a database or cache, an attacker might have placed a tiny backdoor that way, only to be used after the everyone has applied the PHP patches and attention levels & active staff are back to normal.
while waiting for the official patch, run this read-only script to check /var/www for changes and other things.
https://gist.github.com/SourceCodeplz/82f07c94ca7aa036875622...
I actually looked through PHP code responsible for parsing POST request body and it's pretty bad [1].
First, there is a huge function, that is hard to read and reason about. Second, instead of proper parsing of "Content-Type" header to extract "boundary" parameter, there is just a set of substring searches which is not correct. It doesn't mean there is a vulnerability but it means PHP can read the header in a way different from a standard-compliant implementation (such as web server, WAF etc).
[1] https://github.com/php/php-src/blob/master/main/rfc1867.c#L7...
There is also plenty of ways to confuse the WAF by simply sending multiple instances of of the relevant header and/or parameter..
In terms of taking sites/applications down, if you have a maintenance mode that serves only HTML does that seem sufficient at the moment, or is the mere presence of PHP on a server enough right now to warrant "entire server, off button"?
The previous presence of PHP and its oftentimes ridiculous common practices might mandate a maintenance mode that is a little more involved than just serving HTML.
e.g. if your site usually responds blank for https://site.example/database-passwords-and-other-goodies.ph... but under maintenance mode publishes the configuration verbatim, that would be quickly picked up the usual scanner bots.
Depends on how it is set up.
Many modern hosts run php in fcgi mode, where your app is a process that listens on some http port. And where the webserver is "just" a proxy and ssl termination. Shutting down the process is enough.
But traditionally, php was a module loaded into apache. Where apache not only handled ssl, http etc, but also compiled and ran php for you. With that setup, adding an html file, will keep the php runtime and app online.
It was suggested to only allow GET/HEAD requests. Works if you don't have login forms.
you need to block requests from being routed to your PHP interpreter
Strange to see this so far down the front page. If the rumors are true, it may be worse than Log4Shell.
[dead]
Dumb question: does this affect a backend even if behind an ouath wall?
If the oauth wall is managed by PHP, then it looks like the answer is yes, you’re vulnerable to client connections that haven’t logged in.
This looks like a bug in PHP’s assembly of multipart responses & you can feed one of those to the PHP backend with a simple web request, no auth required I think.
If the backend can be reached, yes.
If you put the oauth wall in front of the application before it can even reach PHP (i.e. in your nginx/caddy/apache config), then no, assuming all paths are covered.
Probably yes
If anyone can login, probably yes. If only trusted people can, probably no.
Just remember that your LLM doesn't count as trusted people.
According to this https://jackalsyn.com/posts/php-up-2026.html, you need the dtor to successfully replicate the RCE on a live server.
So, theoretically, if you wanted to hack a server but you don't know what OS/PHP, version they're running, you could compile a list of every delta for every litespeed release and then bruteforce it, right?
You could. Or maybe there's a way to leak the pointers too, which would work around the need for a database.
So, source-based distros get to shine?
Not necessarily. Most apps should build in reproducible way these days. That means you can compile the same versions and likely get the same offsets. (+/- custom options applied to your local system)
1 reply →
Correct.
https://gerrit.wikimedia.org/g/mediawiki/core says "Error: please contact the wikimedia SRE team to discuss a less disruptive approach at ..." Related?
Sounds like you're rate limited; working for me.
Only 53 comments for what's most likely going to be the biggest vulnerability in history? I don't understand how this isn't getting more attention. The exploit is already out and it's basically shell access on any php website out there.
It's also very early in EU and evening/night time in part of US. The information that was out earlier was on level "make sure you update tomorrow when the patch comes out", the actual details weren't out yet.
We're all busy turning off uploads on our servers
This currently returns
Must have been running on PHP.
Now it's up again (sometimes).
Edit: my message was wrong, see below.
[original: The Release Candidate for the patched version is out!]
https://hub.docker.com/_/php/tags?name=8.5
This is not an RC for the patched image.
8.5.12RC1 is a planned RC, see: https://discourse.thephp.foundation/t/php-php-8-5-12rc1-avai...
Has it been confirmed this RC contains the fix?
No.
A lot of people are going to be up late on account of this.
Must be a pretty serious one that can be exploited easily, I haven’t seen this type of pre-announcement of when something will be released before.
There are some vulns that warrant a pre-release announcement (in the Drupal community, this happened for a few of the more serious fixes). And prior to the public pre-announcement, there is often informal coordination between some of the larger hosting providers or giant companies who can help roll out the patch more quickly.
The proof of concept works against any PHP server (5 and up) running in the default configuration, leading directly to RCE without authentication. The PoC out there can be defeated by disabling multi part uploads.
The PoC also requires a known binary to exploit so custom PHP builds may be safe if you're lucky, but this seems to be an extremely bad one.
Apparently, any PHP server that accepts a POST request is vulnerable to arbitrary code execution on the host (from the FPM user?) with no defense. This is DEFCON 1 of internet security: 70% of all websites are currently vulnerable until 14:00 UTC tomorrow with zero escape hatch other than blocking traffic.
Check the Twitter linked video above. It's bad. Just having PHP running on the server is enough.
This is going to pop a lot of wordpress sites.
Invest in shopify stock this week then. I will tomorrow morning first thing.
I had my app running on unsupported php version for 'years', because i didn't have anyone handy to update it.
so even if it takes a few days to get my AI agent to do this, it's still a vastly more secure landscape for an amatuer like me
You should take your application offline until it’s updated. Otherwise it will be hacked immediately when this exploit comes out.
That's not likely to happen. You don't even know what the exploit is.
Anyway my point is I'm much less likely to get hacked in this new era of AI assistance, as I'm only a few days behind, rathe than a few months or years behind.
11 replies →
God damn Claude (Opus, Fable, either) is not even helping because of their god damn shitty safeguards. Thank you, Anthropic, for letting bad guys win. I can't tell you how much I want open-weight models to work at home that can handle this type of work in the future without bullshitting about safeguards.
Yeah I agree. Safeguards only bother normal people; evil actors will circumvent them anyway.
these safeguards are insane. codex would do some fix, them say "hm, my change has introduced a vulnerability. let me write a test for it and then do the fix" and the safeguard stops it.
Why do you need the open weight models to work at home? You can use them whenever you want.
At home as in home hardware.
Yep, had to switch to GLM 5.3 to help protect our platform. So annoying. Claude and Codex crashed out.
GLM 5.3 works just fine.
This seems serious enough that I've contacted a few less-technical loved ones about it. I'm warning them of possible scams in the next days, perhaps even hosted on otherwise official pages.
Hahaha, good morning Eastern Time folks. Heck of a day ahead.
Seems like even the EOL versions should get a patch for something like this.
But what would be the point of declaring something "EOL" then?
I agree with the thought, but sometimes things are so bad that it's worth an exception.
This looks like one of those things.
PHP don't support it and likely won't patch it (even though this is probably big enough that they should), it's up to your distribution whether or not they will.
They will if you use a supported OS.
TiDB, eMudhra CA, and this
I wonder if this is the new norm for LLM era...
Docker images are cooking https://github.com/docker-library/php/actions/runs/396158697...
Getting Bad Gateway.
It's going to be hilarious if I'm not vulnerable because I'm running PHP like it's 1995 via CGI and so get a brand new process per request and break ASLR infoleaks by side effect.
The release is now available: https://www.php.net/index.php#2026-10-21-5
Would blocking all multipart/formdata requests be a sufficient mitigation until the updated php version is available?
A PHP core dev suggested all the mitigations getting posted are not enough and that if possible you need to shut down any PHP app until the patch comes out https://phpc.social/@Girgias/117476510850918355
Yes that's what a lot of people are doing.
No. Take anything with PHP down until the patch if you can afford to do so.
I'm a sysadmin that manages several servers, I realized I was vulnerable and reproduced what I found on our systems, it appears that simply disabling progress with php_admin_flag session.upload_progress.enabled Off renders the exploit inert...
PHP dev and release manager claims differently
No hints as to what versions are affected?
> These vulnerabilities could affect all PHP versions from PHP 5 onwards
https://news.ycombinator.com/item?id=50167754)
I love the "affects PHP... 6" given we never had an official 6 release haha.
3 replies →
Discussions: https://news.ycombinator.com/item?id=50180836
I suspect we might be about to see a big Bitcoin mining boom...
More like Monero, but yes.
Uh oh, POC is already out there https://jackalsyn.com/posts/php-up-2026.html
It is not a complete proven PoC, have you read the REPORT_VALIDATION.md, especially section 7.
I haaaaaaate LLM slop. Barely readable due to low contrast and the first sentence already sets off my slop alarm:
> Two cached bucket pointers, one freed tree.
I've rarely been happier than now to have left IT for good...
I don't know if people understand that this actually lowers their reputation, instead of increasing it. Putting so important text as AI slop. Maybe it is not so important, if not worth of modifying themselves.
2 replies →
The writing is what you have a problem with, but the script kiddie h4xxor theme isn't?
1 reply →
Once the dust has settled, it would be interesting to give LLMs the pre-patch source code and see whether any of them can identify this chain of vulnerabilities. Even if they can't identify the full chain, can they at least spot one of the constituent bugs and recognise its seriousness?
If they can't, why not?
If they can, why haven't they already?
If you tell them where the problem is (even rough code area) - I'm 99% sure they can, and have.
If you only tell them to find issues in PHP - the strongest models probably still can, although they might find different issues ;)
I’d hazard a guess that’s how the bug was found in the first place?
LLMs probably found this multiple times.
The original exploit, and then when the rumors of a big critical patch got out, the people who are leaking the details online probably used an LLM to find the exploit again.
Just revealing that an unpatched exploit exists in $XYZ these days basically guarantees that a bunch of people are going to target $XYZ with LLMs looking for that exploit.
4 replies →
I would be astounded if labs were not already fine tuning on known vulnerabilities for their cyber models
Undoubtedly, but presumably not this specific set of vulnerabilities.
They can't, because the good guys get the LLM with restrictions.
The bad guys have invested the resources of the criminal enterprise into hardware running unrestricted models.
2027 is going to be crazy
Even next month is unfathomable
The official php advisory has been hugged to death? What a clusterfuck
Anyone have an archive link?
Wow, that's a terrible one. Shut down old apps (that I'd forked and upgraded to latest) I had that were PHP. Sadly, my blog was on Mediawiki and so I've got to turn that off too. Tomorrow we learn.
EDIT: Ha, Claude just took the blog and rendered all pages and now it is a static site! I'll restore the Mediawiki once I can fix the issue.
So all local universities have now essentially shut down their web-services for students. This is ... kind of curious because now you can not download recent updates (e. g. new .pdf files published) from that software.
We need a long-term solution with regards to PHP. PHP is a success story - so much web-software depends on it. But it also has become a liability when they are all now scared that the server can be easily taken over. This is not acceptable, PHP.
PHP has been a security dumpster fire for decades. It's just how the entire web ecosystem works: some web designer lacking any technical know-how is asked to make a site and dumps WordPress on it out of habit.
Even though there are much more secure CMS technologies out there like Umbraco or Piranha (both ASP.NET) and web stores like NopCommerce (ASP.NET also).
There are just too many technically clueless people building web sites and web stores.
i started seeing a lot of scans on my webservers:
That looks like pretty typical scanner traffic, especially the WP routes. I wouldn’t assume it’s necessarily specific to this exploit.
For this exploit you would expect POST requests
This has been the norm for years
Rather than taking your site down tonight, if you have cloudflare handling your DNS, orangeclouding your domain, you can use its free security rules to just block all post requests until tomorrow rather than taking your whole site offline. Drop this into a rule: `http.request.method in {"POST" "PUT" "PATCH" "DELETE"}`
Of course you can do this with web server (eg Apache) config as well, but the CF rule is something you can do now on your phone.
I’m not saying I know this works as a mitigation, but it seems like it could at least contribute to a temporary guard until you get patch in place. Everything I’ve seen about the exploits seem to revolve around multipart form submissions.
Don’t forget to firewall your webserver so it will only accept traffic that actually went through Cloudflare. This is the most false sense of security one can get.
You can also do the apache rule from your phone, via ssh, if you're any good.
Haha you’re right, but the skill you need to be good with is probably eye strain tolerance. But must needs and all. :) If you don’t use a WAF of some type, the risk is probably sufficient to warrant firing up the laptop tonight or worst case use the phone.
I am seeing a lot of words like "unconditional" thrown around but I remind that defense in depth is a thing and you can practice it, or should have been practicing it. You can, for example, disable the `system` function of PHP altogether. You can also arrange for your PHP to be running in a situation where there's no shell, or any other program, to exec. Or for that matter a filesystem.
It's a RCE bug, it does not matter if you disable php functions. It's not arbitrary PHP execution, it's an exploit chain resulting in arbitrary code execution.
Indeed, an attacker theoretically can access anything the PHP process has permission to access. However even without limiting permissions (also a good idea) that means the simple/published exploits won't work on your server, and there's a high chance criminals will look for other targets, assuming you're not targeted.
1 reply →
You know how "resulting in a shell" works?
7 replies →
no idea why this is downvoted. PHP runs typically on linux machines. If you depend on a language feature to prevent 'exploit' and don't utilize the operating systems features to limit access to data.
Shell access is not good, but in many places that wouldn't be the end of the world either.
Rethink your strategy
If your PHP application accesses a database, you've got exfiltration, it doesn't matter in this case. Unless your PHP application is just echoing non sensitive data (i.e. rendering md files)...
https://x.com/J4ck3LSyN/status/2112703096443097263 Already being exploited. They need to release the patch now, not later. This is already being deployed by attackers as we speak.
I suppose this will go down in history :|
Shit got real. All my favorite places are hunkering down, like https://www.vogons.org
<p>Due to an <a href="https://www.php.net/archive/2026.php#2026-10-20-1">upcoming significant vulnerability disclosure</a> with no official mitigation, services are currently offline as a precaution. Services will not be restored until at least later in the day on October 21. This time may also be spent on additional maintenance, so this message may be periodically unavailable.</p>
https://community.openstreetmap.org/t/secondary-service-offl...
> The OpenStreetMap.org operations team have decided to temporarily shutdown a number of key secondary OSM.org services due to a critical PHP security vulnerability.
Well we all got fucked by this cert issue.
They need to release it now.
There is allegedly a temporary mitigation: https://twitter.com/k_firsov/status/2112718728232329240
php.ini:
According to a PHP core dev, this is insufficient, but no details were provided. Probably can't hurt anyway.
https://phpc.social/@Girgias/117476477429221001
Just a heads up, as of my comment, this is not endorsed by PHP as a migration for the patch.
> as of my comment, this is not endorsed by PHP
Are you speaking officially here?
There are various mitigations suggested online, including completely blocking multipart requests at LB level. Is the combination of both effective?
3 replies →
I wouldn't skip updating, but is there anything else we can do, other than simply shutting down the web server until the fix is available?
3 replies →
The PoC says so.
I don't want to jinx it but... A discussion about, of all languages out there, PHP being the one hit by that and not, say, Go or Java or Rust or Haskell etc.?
Can we discuss that at least a tiny bit?
How do people feel about running servers with PHP today?
I don't think most people that use PHP use it because they love it and find it a great technical solution, it's mostly technical debt being maintained and the fact that PHP is available to host everywhere.
I mean no language is immune to issues. Java world constantly sees fixes for both JVM and libraries. For example, besides famous log4shell, you can see still see in HTTP access log that bots are checking for vulnerable Struts versions. On the other hand, Java pushed to 100% Java (no native code) database drivers, while PHP strongly relies on c/c++ extensions, cause PHP is/was too slow. If there is any other difference, I think it just comes to legacy PHP approach - memory management didn't matter if entire request (and forked process that handles it) was alive for maximum few seconds.
These issues tend to happen way more in languages that depend on a runtime, especially one with dynamic lookup capabilities. If I remember correctly, log4shell depended on dynamic class loading and a lot of runtime-dependent stuff. Languages that are statically-compiled and memory-safe (namely Go and Rust) don't have the runtime vector and don't generally have the memory safety vectors either. I feel a lot safer deploying services written in Go than JS, for example.
Anxious and slowly rewriting said services in other languages as time allows lol
Pure LOLPHP matrial
[dead]
[dead]
[dead]
Some more discussion: https://news.ycombinator.com/item?id=50171528
[flagged]
PHP is truly a garbage ecosystem. I thought log4shell was bad but this is 100X worse.
With vibe coded slop tools readily available, using php in 2026 is just laziness.
How is the patch still not out yet? This is another case of big tech players all colluding together leaving all the small guys out to dry.
At least this time we can have LLMs rediscover it and make patches ourselves.
Here is the patch I had an LLM come up with against master: https://pastebin.com/raw/EUCF0SR0 It at least stops the PoC which is better than nothing.
the php team should consider leveraging ai to rewrite the interpreter in rust like bun did recently
Surely you realize that the codebase behind the language powering 60% of the web is a bit more complicated than an experimental JS runtime?
it doesn't have to be done all at once
A rewrite would tackle the classic C-style W^X problems, at the expense of maintainability and focus on logic bugs and general oversights from inelegant (or lack of) design. And I'd bet PHP (and popular PHP software for reasons rooted in the language) still got plenty of the latter. You know, the "oops, that filename was client provided" kind of code execution that no amount of (un)safe blocks can help with.
Bun isn't an interpreter. It uses JavaScriptCore for that, which, you guessed it, is C++. As far as I know they have no plans of rewriting it in rust either. Your hot take doesn't seem to apply here.
A reminder, because it really needs to be said, that they spent millions of dollars in tokens for the claimed 11 day sprint, and then spent an additional 3.5 months fixing hundreds of issues it introduced before actually releasing it. Long-term maintainability remains to be seen.
I recently changed my mind here.
Why?
Because some upstream services here in central Europe, are closed down because of that PHP problem. So now I am annoyed since this disrupted my workflow.
PHP, please either get your act together - or disband.
"No way to prevent this" say users of only language where this regularly happens.
I think this one more great example what kind of a liability and ticking time-bomb memory-unsafe code is.
It is a yet another reminder why we should start new projects with Rust and dig C and C++. Why would anyone want to use C.
This might be the nail in the coffin for php.
I expect it will be the death of the C codebase which will get an oxidation push.
This is a joke, right? I can't tell if this is a joke.
It probably is but I am converting everything to python already.
3 replies →
Given the proven capabilities of LLMs in computer security, get ready for similar issues to affect NodeJS, Java, Go, Rust etc...
NodeJS and Java are in a similar place (this CVE is a memory safety issue in PHP's C-language interpreter) but Go's compiler/runtime is written in Go and is memory-safe all the way down to the assembly.
3 replies →
Don’t you mean WWZ ? Php is hardly dead – billions of installs.
I wish
“PHP is the cockroach of the internet”
[flagged]
Is there already a name for the vuln?
If not I suggest PHenomenalPhail.
PHP2Shell
Heap use after free?
No excuse whatsoever to not either rewrite your website of PHP or to rewrite PHP itself to Rust.
I hope that people will realize that PHP is unsuited for public websites and that they need to switch to secure technologies like Java, ASP.NET or Rust.
PHP contains an almost endless stream of vulnerabilities since its inception almost 3 decades ago. Proponents claim that it's getting better but this just goes to show that nothing's changed.
A user on X claims:
https://x.com/k_firsov/status/2112718728232329240#m
https://xitter.cf/k_firsov/status/2112718728232329240#m
Doesn’t work
Any details why not?
5 replies →
[dead]
Honest question, who uses php anymore?
I know there must be a ton of random sites which makes this a huge deal.
But, does it affect any big players? I think php is big at Meta but I would imagine its so heavily customized it might be safe from this.
4,384,302 PHP services on 1,886,612 unique hosts apparently[0]
[0] https://modat.io/blog/php-exposure-before-the-21-oct-2026-se...
Writers/editors really, really like Wordpress for some reason, which is like 40% of the Internet, add to that all the other Php stuff. At $DAY_JOB we have a Wordpress instance behind our VPN and use the json API to send the articles to a front-end server written in something else. Forces us to duplicate some of the front-end plugin code (and we try to not use many) but we get peace of mind in exchange.
There's a pretty huge UCaaS software suite that serves millions of seats across the US that runs on PHP 7.4.
Not really. Just little sites like Wikipedia.
And 70% of the web. Nothing important.
1 reply →
I use PHP.
Just as a scripting language on my own laptop, nothing prod. But one thing I notice, even coming back to it after a little while, even after using Python for everything, I find I am effortlessly productive with it.
There was an article I read recently about a blind developer who finds it easy to write in, as the "$" for the variable names makes it easier for him to identify what's going on in any given line of code.
Like any language it has advantages and disadvantages.
I think I found the article you alluded to: https://thephp.foundation/blog/2026/06/16/php-through-a-scre...
The "Syntax as landmarks" section sounds like he's comparing it particularly to Python. The quirk of `$` denoting a variable did kind of work out for him. Especially compared to Python where you declare a variable by assigning it. But it's not like PHP was designed with a special character for each syntax role. He still needs to use context to infer other roles.
PHP has the advantage of being preinstalled or easy to install in a lot of environments. I had to investigate the blind developer thing because I'm still on the hunt for a second advantage.
blind developer prefers PHP !? just wow
I think the ubiquiti edgerouter admin interfaces use PHP. I don’t know about mikrotik, but wouldn’t surprise me if there are a lot of those devices hanging off the internet on some nonstandard port.
Mikrotik developers would never stoop so low as to use a scripting language written by someone else.
Used to. Newer firmware stopped using PHP.
[flagged]
What are you gonna say when your favourite language gets a vulnerability report with an AI generated exploit chain?
1 reply →