Rendered at 05:07:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
bwoebi 2 hours ago [-]
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...
jwitthuhn 1 hours ago [-]
Hopefully the industry will learn something about how withholding fixes to known vulnerabilities is, in fact, bad policy.
baggy_trough 2 hours ago [-]
The police should wake them up.
27183 2 hours ago [-]
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.
jyunwai 7 minutes ago [-]
A civilian government official outside of law enforcement could be a safer pick. A CISA representative (or any non-US country's equivalent department/ministry of cybersecurity) could achieve the same outcome, or even better, as they'd have more technical background to explain what's going on.
zeeZ 1 hours ago [-]
In March this year, German police set out to warn admins on a weekend.
Depends on the tone of the police, but if they’re just waking you up and make sure you take a call from your boss, then are on their way, why not.
Beats panicked boss banging on the door. If there’s one thing I cannot handle while doing something critical in production, it’s panicked boss in the same room as me.
redox99 1 hours ago [-]
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.
Georgelemental 34 minutes ago [-]
There is no such thing as a "friendly phone call" at the middle of the night from a police officer you don't know.
OrderlyTiamat 8 minutes ago [-]
If it's just a phone call, why involve the police at all? But if that doesn't work, and it's critical that someone is woken up and no one is near, I could see the police as a reasonable option.
I agree with GP that my first instinct would be "lawyer", but I'm imagining the police at the door saying something like "hey we're here to inform you there's an urgent xyz, we'll now be on our way" and leaving. At that point that's the police matter resolved, no?
I tried it on a personal site, was able to dump the entire database. Immediately shut all my sites down. This is bad.
burnJS 54 minutes ago [-]
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.
burnJS 27 minutes ago [-]
I tried this more simplistic variant https://pastebin.com/kggc4q1T which supposedly would crash php but it was rejected by my CSRF middleware...
afdbcreid 14 minutes ago [-]
If you maintain a 9 figures business, I would recommend to not rely on that and shut it down or at least do more.
stackghost 30 minutes ago [-]
You make 9 figures at a fintech? Are you hiring?
burnJS 26 minutes ago [-]
Fintech makes 9 figures. I make 6 there and 6 at my stealth :-)
theteapot 26 minutes ago [-]
You use PHP at a fintech?
burnJS 26 minutes ago [-]
One of many languages. It has its role.
lolakutty 23 minutes ago [-]
>It has its role...
Of being a hole...
redox99 2 hours ago [-]
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.
spenvo 2 hours ago [-]
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.
defgeneric 12 minutes ago [-]
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.
int32_64 1 hours ago [-]
Mark Karpelès? Wow that's a name I haven't thought about since 2014.
joshuat 3 hours ago [-]
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.
Gigachad 6 hours ago [-]
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.
philipwhiuk 4 hours ago [-]
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.
qingcharles 1 hours ago [-]
I can think of some really ancient phpBB boards that probably won't ever come back if they get hit.
Gigachad 3 hours ago [-]
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..
afdbcreid 6 minutes ago [-]
Nice idea, but I don't think you would want e.g. your hospital to have their systems suddenly turn off.
lioeters 2 hours ago [-]
Kindware instead of malware. Just goes around finding vulnerabilities and using them to patch things and improve security everywhere.
If people wait too long you could even have the bot use the exploit to update the PHP version.
stackghost 2 hours ago [-]
I’ve thought about doing this in the past but have no trust in police to see it as a Good Samaritan act
jtchang 4 minutes ago [-]
This is going to pop a lot of wordpress sites.
ernubufiei 21 minutes ago [-]
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.
enews01 2 hours ago [-]
Just shut down our MediaWiki site temporarily out of an abundance of caution. The twitter videos look scary...
Dumb question: does this affect a backend even if behind an ouath wall?
afdbcreid 5 minutes ago [-]
If anyone can login, probably yes. If only trusted people can, probably no.
redox99 19 minutes ago [-]
Probably yes
dangoodmanUT 2 hours ago [-]
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
mircerlancerous 2 hours ago [-]
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.
Gigachad 2 hours ago [-]
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.
afdbcreid 11 minutes ago [-]
It's not "trivially exploitable". Two or three years ago, this would be a critical issue but require quite some expertise to exploit and exploits definitely wouldn't spread like that. LLMs are shaking the entire security industry.
alberth 58 minutes ago [-]
A user on X claims:
Temporaly mitigation
php.ini: session.upload_progress.enabled = Off
Several people who work on PHP have said it's not enough, that only the patch will do, but, they're staying silent otherwise
ndbe 48 minutes ago [-]
[dead]
aksss 17 minutes ago [-]
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. 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.
barelysapient 2 hours ago [-]
This might be the nail in the coffin for php.
mappu 21 minutes ago [-]
I expect it will be the death of the C codebase which will get an oxidation push.
lolakutty 17 minutes ago [-]
People ll continue to use it for fear of hurt feelings...
skoskie 2 hours ago [-]
This is a joke, right? I can't tell if this is a joke.
aussieguy1234 48 minutes ago [-]
Given the proven capabilities of LLMs in computer security, get ready for similar issues to affect NodeJS, Java, Go, Rust etc...
tonymet 2 hours ago [-]
Don’t you mean WWZ ? Php is hardly dead – billions of installs.
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?
afdbcreid 3 minutes ago [-]
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 ;)
shepherdjerred 25 minutes ago [-]
I would be astounded if labs were not already fine tuning on known vulnerabilities for their cyber models
simondotau 18 minutes ago [-]
Undoubtedly, but presumably not this specific set of vulnerabilities.
marcins 42 minutes ago [-]
I’d hazard a guess that’s how the bug was found in the first place?
georgemcbay 22 minutes ago [-]
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.
simondotau 16 minutes ago [-]
I would have expected there to be a hundred entities running every single model over major code like PHP, and clang, and pretty much any behemoth open source project the world relies on. This is the sort of thing the model makers should be doing as a matter of course, as part of routine testing of their new models.
georgemcbay 10 minutes ago [-]
> I would have expected there to be a hundred entities running every single model over major code like PHP, and clang, and pretty much any behemoth open source project the world relies on. This is the sort of thing the model makers should be doing as a matter of course, when they’re testing their new models.
Well, that would be super nice of them.
From a Machiavellian standpoint it may benefit the people with the most powerful models to let some serious RCEs like this PHP one get widely exploited in damaging ways to further their regulatory capture argument that open weight models have to be legally banned and only locked down models with enforced guardrails around usage can be allowed.
t1234s 38 minutes ago [-]
Would blocking all multipart/formdata requests be a sufficient mitigation until the updated php version is available?
Gigachad 14 minutes ago [-]
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
adventured 17 minutes ago [-]
No. Take anything with PHP down until the patch if you can afford to do so.
Just a heads up, as of my comment, this is not endorsed by PHP as a migration for the patch.
lol768 2 hours ago [-]
> 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?
lynndotpy 2 hours ago [-]
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.
1over137 1 hours ago [-]
"LB"?
pickledish 1 hours ago [-]
Load balancer!
ThePowerOfFuet 45 minutes ago [-]
The PoC says so.
LoganDark 3 hours ago [-]
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?
lynndotpy 3 hours ago [-]
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.
qingcharles 1 hours ago [-]
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.
xena 3 hours ago [-]
You could disconnect the web server from the internet!
bakugo 3 hours ago [-]
Strange to see this so far down the front page. If the rumors are true, it may be worse than Log4Shell.
aaron695 12 minutes ago [-]
[dead]
jacquesm 3 hours ago [-]
A lot of people are going to be up late on account of this.
stingraycharles 3 hours ago [-]
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.
geerlingguy 60 minutes ago [-]
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.
SyneRyder 3 hours ago [-]
Check the Twitter linked video above. It's bad. Just having PHP running on the server is enough.
hparadiz 2 hours ago [-]
They need to release it now.
jamesfinlayson 3 hours ago [-]
No hints as to what versions are affected?
gnabgib 3 hours ago [-]
> These vulnerabilities could affect all PHP versions from PHP 5 onwards
I love the "affects PHP... 6" given we never had an official 6 release haha.
gnabgib 2 hours ago [-]
Yeah.. their text (unedited).. Maybe they meant 5.6? Only 8.x is "supported" currently, though. I wonder how 3&4 avoided it :)
cesarb 1 hours ago [-]
> 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.
jeffbee 2 hours ago [-]
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.
Operyl 2 hours ago [-]
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.
afdbcreid 2 hours ago [-]
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.
jeffbee 2 hours ago [-]
You know how "resulting in a shell" works?
bulatb 12 minutes ago [-]
By corrupting memory and causing the CPU to jump from the intended instruction to a different one controlled by the attacker, at which point their instructions control what your process does next.
You could root an internet-connected toaster with a JPEG. The system() function has nothing to do with it.
Operyl 1 hours ago [-]
I can guarantee you that it's not because someone left system() enabled, it's much lower than that.
calvinmorrison 2 hours ago [-]
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
Operyl 1 hours ago [-]
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)...
redox99 1 hours ago [-]
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.
buzer 48 minutes ago [-]
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 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...
German article: https://www.heise.de/news/WTF-Polizei-rueckte-Samstagnacht-w...
Beats panicked boss banging on the door. If there’s one thing I cannot handle while doing something critical in production, it’s panicked boss in the same room as me.
I agree with GP that my first instinct would be "lawyer", but I'm imagining the police at the door saying something like "hey we're here to inform you there's an urgent xyz, we'll now be on our way" and leaving. At that point that's the police matter resolved, no?
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...
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.
Of being a hole...
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.
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://www.schneier.com/blog/archives/2005/12/benevolent_wo...
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
If the rumors going around are true this will be the worst computer security incident in history.
https://xitter.cf/k_firsov/status/2112718728232329240#m
https://phpc.social/@Girgias/117476510850918355
https://old.reddit.com/r/PHP/comments/1xb2utu/comment/phyu5m...
If they can't, why not?
If they can, why haven't they already?
If you only tell them to find issues in PHP - the strongest models probably still can, although they might find different issues ;)
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.
Well, that would be super nice of them.
From a Machiavellian standpoint it may benefit the people with the most powerful models to let some serious RCEs like this PHP one get widely exploited in damaging ways to further their regulatory capture argument that open weight models have to be legally banned and only locked down models with enforced guardrails around usage can be allowed.
php.ini:
https://phpc.social/@Girgias/117476477429221001
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 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 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.
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)
Probably the same way log4j 1.x avoided log4shell: the vulnerable code was introduced on a later release.
You could root an internet-connected toaster with a JPEG. The system() function has nothing to do with it.
Shell access is not good, but in many places that wouldn't be the end of the world either.
Rethink your strategy
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.
With vibe coded slop tools readily available, using php in 2026 is just laziness.
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.