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...
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.
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.
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 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.
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..
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?
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.
I am not affiliated with PHP in any way or sense, I am saying this as someone who is able to see PHP's announcements, and there was no patch or mitigation announced by PHP.
I don't think pulling mitigations from random users online during a developing situation is a good idea. I think shutting down ones PHP services for the time being is a very good idea if that's an option.
I applied the mitigation to all my servers when it was released, but now I've stopped all the httpds. A few hours of overnight downtime, vs potentially trying to restore everything from backups tomorrow. Everyone should weigh it up.
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.
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.
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)...
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...
Hopefully the industry will learn something about how withholding fixes to known vulnerabilities is, in fact, bad policy.
The police should wake them up.
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.
In March this year, German police set out to warn admins on a weekend.
German article: https://www.heise.de/news/WTF-Polizei-rueckte-Samstagnacht-w...
It could be just a friendly phone call to wake you up and read the news. Doesn't mean they are forcing you to do anything.
I tried it on a personal site, was able to dump the entire database. Immediately shut all my sites down. This is bad.
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.
A user on X claims:
https://x.com/k_firsov/status/2112718728232329240#mhttps://xitter.cf/k_firsov/status/2112718728232329240#m
Doesn’t work
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.
Mark Karpelès? Wow that's a name I haven't thought about since 2014.
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.
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.
https://x.com/k_firsov/status/2112641845926989944
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.
I can think of some really ancient phpBB boards that probably won't ever come back if they get hit.
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..
If people wait too long you could even have the bot use the exploit to update the PHP version.
Kindware instead of malware. Just goes around finding vulnerabilities and using them to patch things and improve security everywhere.
Benevolent worms.
https://www.schneier.com/blog/archives/2005/12/benevolent_wo...
Heheh that's cute.
I’ve thought about doing this in the past but have no trust in police to see it as a Good Samaritan act
Just shut down our MediaWiki site temporarily out of an abundance of caution. The twitter videos look scary...
Link to videos?
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?
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.
This might be the nail in the coffin for php.
This is a joke, right? I can't tell if this is a joke.
Don’t you mean WWZ ? Php is hardly dead – billions of installs.
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?
I am not affiliated with PHP in any way or sense, I am saying this as someone who is able to see PHP's announcements, and there was no patch or mitigation announced by PHP.
I don't think pulling mitigations from random users online during a developing situation is a good idea. I think shutting down ones PHP services for the time being is a very good idea if that's an option.
"LB"?
Load balancer!
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?
I do not have details about any mitigation. There are rumors that people have independently come across php2shell exploits.
I shut down my servers five hours ago. This might have seemed premature at the time.
I think the best course of advice for most people is to shut down their servers as soon as they possibly can.
I applied the mitigation to all my servers when it was released, but now I've stopped all the httpds. A few hours of overnight downtime, vs potentially trying to restore everything from backups tomorrow. Everyone should weigh it up.
You could disconnect the web server from the internet!
Uh oh, POC is already out there https://jackalsyn.com/posts/php-up-2026.html
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.
We're all busy turning off uploads on our servers
They need to release it now.
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.
Check the Twitter linked video above. It's bad. Just having PHP running on the server is enough.
Strange to see this so far down the front page. If the rumors are true, it may be worse than Log4Shell.
No hints as to what versions are affected?
> These vulnerabilities could affect all PHP versions from PHP 5 onwards
https://cert.europa.eu/publications/security-advisories/2026...
> affect PHP versions 5, 6, 7, and 8.
https://www.bleepingcomputer.com/news/security/php-warns-adm... (which references HN as a source - https://news.ycombinator.com/item?id=50167754)
I love the "affects PHP... 6" given we never had an official 6 release haha.
Yeah.. their text (unedited).. Maybe they meant 5.6? Only 8.x is "supported" currently, though. I wonder how 3&4 avoided it :)
> I wonder how 3&4 avoided it :)
Probably the same way log4j 1.x avoided log4shell: the vulnerable code was introduced on a later release.
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.
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.
You know how "resulting in a shell" works?
I can guarantee you that it's not because someone left system() enabled, it's much lower than that.
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.
Some more discussion: https://news.ycombinator.com/item?id=50171528