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?
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...
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.
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.
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.
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.
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.
How are the policemen waking you up if not pounding on your door or breaking it down? Or if they found a key under a mat and are beside your bed shaking you awake.
In those cases I'd rather the boss pounding at the door at least I could call the police and have them removed.
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?
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.
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.
Facebook hasn't used PHP for a very long time. It's been using Hack for over 12 years, which was initially based off PHP but it's deviated quite significantly now. It's now nearly entirely statically-typed, and has a bunch of features that PHP doesn't have. IO is fully asynchronous using async/await syntax (like C# or JavaScript), functions can be marked as pure, and a bunch of other things useful in large codebases.
It still uses the same request model as PHP, since that's genuinely useful for web requests. It's easier to avoid memory leaks if each request is entirely self-contained and there's no global state persisted between requests (other than APC and opcode caches)
This link gets me a shitton of extremely intrusiv ads, some of which look like malware (auto-downloading an "OperaSetup.exe"). Is pastebin already compromised?
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..
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.
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.
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.
log4shell was easier to exploit.
It also come with an initial patch that turned out to be incomplete, so everyone had to urgently patch every java web app twice!
Log4Shell required that the attacker be able to generate a log message containing specific parameters. It was a severe exploit, but not one that worked in every Java application with the affected Log4j versions. Attackers had to find calls that logged user submitted text or query paths first. So the list of prerequisites was larger: had to be using Log4j and had to have logging of user generated text.
Still a very large attack surface, but not nearly as ubiquitous as this one.
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.
It's trivially exploitable because it requires no special set up, no special credentials, no privileged access of any kind. If you can call a PHP server and you have the exploit script, you can execute arbitrary code as their `www-data` user.
Usually, attacks are at least conditional and require something that weakens security guarantees.
Yes but that means it is trivially exploitable today since anyone can get access to a LLM and where to point it towards. 2-3 years ago, things were different, that is also correct but that doesn't mean things stay frozen in time.
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"}`
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
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?
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.
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.
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.
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.
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.
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.
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
Off-topic but Reddit now requires sign-in to see old.reddit. They destroyed it, "to keep us safe".
Further more, if in Australia or a few other places like Brazil, UK, France, reddit won't let you sign in at all unless you're proven to be over 16. Bottom line, linking to old.reddit is similar to linking to a paywalled article.
They degraded old.reddit even for logged in users - images show as <image>and when you click the link you are redirected to new reddit layout just to see the picture
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.
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.
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.
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.
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.
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.
Exactly. I thought this is exactly what Anthropic's Project Glasswing was meant to be, and targeted at critical internet infrastructure.
Either Mythos is useless and didn't find this (hint: Opus 5.5 will find this once it knows where to look)... or, they did find it, and this is one of many vulnerabilities they're covering up via "guardrails".
I'll be a lot happier if I wake up tomorrow and find this was found with help from Anthropic (or even OpenAI) but I won't hold my breath.
> 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.
From a marketing standpoint, having the first model to find a bug of this magnitude and severity would be a pretty damn impressive proof of capability. Finding previously unknown, critical vulnerabilities in widely used open-source software could become a gold-standard test of frontier AI competence.
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 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.
Presumably this makes SELinux enabled distros like fedora are significantly less vulnerable, as the PHP process can only access files in a few contexts?
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. Getting shell does not mean getting it to feed a spicy string to system(), it means tricking something in the process into overwriting memory with bytes that, if read as instructions, tell the CPU to make a system call to spawn a different process running arbitrary code.
You could do that to an internet-connected toaster with a JPEG. The system() function has nothing to do with it.
What is lower than what? This exploit causes the flow of control to reach zend_call_function with the argument "system". It works at the PHP level and having disabled that function is an absolute defense against the exploit.
It isn't 1998 any more and you can no longer just inject shell code on the heap.
Look, at the end of the day, every major security researcher is going "oh shit" and no amount of tweaks to your configuration is going to limit the blast radius in a way that will actually matter. You're going to need to update PHP, that's the _only_ solution to this problem.
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>
I am used to Python. Hard to switch to something else until I am forced to. I am trying to manage agentic coding at least to the point where I can identify bugs with my own eyes instead of purely believing the LLMs. I know I will cheat and let an LLM take over the entire Rust app if I tried.
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.
Much of Node’s standard library is written in JavaScript, which can’t go on to exploit V8 vulnerabilities even given similar types of bugs, so I wouldn’t say it’s in a similar place. Not as familiar with Java, but I expect PHP is in a class of its own here.
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.
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.
I don't have a "favorite" language. I see languages and communities having strengths and weakness..I evaluate languages as being suitable or unsuitable for certain job..
If a language gets frequently get vulnerability reports, it will change my evaluation...
Php's should have been evaluated out for web applications a long time ago, if the development community was rational, but sadly its made up of far too many emotional people who takes everything personal...
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...
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...
anything that narrows the searchspace
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.
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.
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.
In those cases I'd rather the boss pounding at the door at least I could call the police and have them removed.
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 had to shut down my own backend services. Luckily a big part of my service can run on a static website.
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.
why it would be a thing, beyond "serious problem"?
lol no.
I feel old. Heartbleed was 2014.
Yeah no.
This is bad but doesn't even crack the top ten.
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.
It still uses the same request model as PHP, since that's genuinely useful for web requests. It's easier to avoid memory leaks if each request is entirely self-contained and there's no global state persisted between requests (other than APC and opcode caches)
Of being a hole...
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...
Turning it off may cause deaths. Letting it get ransomwared may cause more. Do you pull the lever to turn it off?
You make sure www-data CANNOT write ANYWHERE on disk. Not /tmp/ Not to /var/www/. No where.
Then make sure your sudoers has nothing weird in it.
Finally disable www-data's ability to run basically anything that isn't required for the operation of your httpd or php-fpm et al.
You then harden it further and further until an RCE does not matter because it's incapable of doing anything.
tldr always treat httpd as untrusted.
Someone on X mentioned the bug relies on some kind of ASLR bypass.
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...
is this multipart request smuggling again?
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
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.
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.
log4shell was easier to exploit. It also come with an initial patch that turned out to be incomplete, so everyone had to urgently patch every java web app twice!
Still a very large attack surface, but not nearly as ubiquitous as this one.
Usually, attacks are at least conditional and require something that weakens security guarantees.
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?
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"}`
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.
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?
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.
> Two cached bucket pointers, one freed tree.
I've rarely been happier than now to have left IT for good...
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.
https://xitter.cf/k_firsov/status/2112718728232329240#m
https://phpc.social/@Girgias/117476510850918355
https://old.reddit.com/r/PHP/comments/1xb2utu/comment/phyu5m...
Further more, if in Australia or a few other places like Brazil, UK, France, reddit won't let you sign in at all unless you're proven to be over 16. Bottom line, linking to old.reddit is similar to linking to a paywalled article.
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.
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.
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.
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.
Either Mythos is useless and didn't find this (hint: Opus 5.5 will find this once it knows where to look)... or, they did find it, and this is one of many vulnerabilities they're covering up via "guardrails".
I'll be a lot happier if I wake up tomorrow and find this was found with help from Anthropic (or even OpenAI) but I won't hold my breath.
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.
From a marketing standpoint, having the first model to find a bug of this magnitude and severity would be a pretty damn impressive proof of capability. Finding previously unknown, critical vulnerabilities in widely used open-source software could become a gold-standard test of frontier AI competence.
You could do that to an internet-connected toaster with a JPEG. The system() function has nothing to do with it.
It isn't 1998 any more and you can no longer just inject shell code on the heap.
Shell access is not good, but in many places that wouldn't be the end of the world either.
Rethink your strategy
<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>
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.
With vibe coded slop tools readily available, using php in 2026 is just laziness.
https://nodejs.org/en/blog/vulnerability/october-2026-securi...
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.
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.
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.
If a language gets frequently get vulnerability reports, it will change my evaluation...
Php's should have been evaluated out for web applications a long time ago, if the development community was rational, but sadly its made up of far too many emotional people who takes everything personal...