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.

Did this with my parents websites and they are quite happy and I get basically no support calls (and can read threads like this one out of interest only, thankfully)

And also relies on the target being patched against any Linux EoP...

Also: https://stopdisablingselinux.com/ - SELinux can mitigate this.

"How to make your site cost unlimited money and have terrible performance". People did this in the Web 1.0 days on occasion and it leads to all kinds of problems for any site with any kind of traffic.

>Or you make an exception for them.

Useless. All you need to do at that point is chain a priv-esc to your existing exploit and you get root.

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.

B: "5.6, 7, 8“

A: fixes a "typo" ok so "5, 6, 7, 8"

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.

php.ini:

    session.upload_progress.enabled = Off

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.

> Two cached bucket pointers, one freed tree.

I've rarely been happier than now to have left IT for good...

But I'm reading a website for getting information, not LLM fluff.

You immediately know you're likely to get clear, technical, actionable info instead of some corporate bullshit

Not so with LLM usage

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.

And he went to prison for a few years for it. So he knows something about PHP exploits.

why it would be a thing, beyond "serious problem"?

Yeah no.

This is bad but doesn't even crack the top ten.

At the end of the day, nobody gives a shit if another WordPress blog gets hacked.

lol no.

I feel old. Heartbleed was 2014.

Extremely legacy software wasn't affected either (log4j v1 or apache commons-logging!). Lots of automated scanners flagging the idle jar as well (when the app used Logback for example as the SLF4J implementer, but the scanner saw a transitive for the log4j jar and would scream at you - that's when I stopped caring about github vuln scans btw, it was a shitshow).

Like dont get me wrong, it was a bad vuln, but to me it seems like it was more hype machine and internet screaming than actual vulnerable applications. I do recall Minecraft was vulnerable though, that one was indeed a big target given publicly exposed servers and such.

Measuring “worst” is hard.

Thanks, PHP.

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.

Usually, attacks are at least conditional and require something that weakens security guarantees.

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.

It isn't 1998 any more and you can no longer just inject shell code on the heap.

You could do that to 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.

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...

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.

What they have achieved by delaying the patch is that exploits are now available publicly before a patch.

Surely this is the worse outcome.

Also not announce it beforehand…

German article: https://www.heise.de/news/WTF-Polizei-rueckte-Samstagnacht-w...

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?

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.

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.

Why would you implicitly take them at their word?

as it stands though, what i replied to wasn't a useful addition to the discussion. it could easily become so by either being made contingent upon the possibility of that being a lie, or being bundled with an assertion like yours that chainguard is not to be taken at their word. doing neither and simply responding as if a causally opposite statement had been made is just a non sequitur.

Even then, it implies more than it says. It's often used to suggest the exploit came from a remote system one does not directly control and was deployed, successfully, against another system one does not directly control. But even that does not necessarily have to be true, as people can use it, without any bad faith and not trying to twist the phrase, in cases where only one of those conditions hold, e.g. against a system one does directly control where the exploit attempt was unsuccessful.

Breaching an embargo, makes reverse engineering easier. We don't need to analyse motives or pontificate. Disrupting the supply chain... Disrupts the supply chain.

If you want to 'adopt' a new reality, you talk to all parties, and everyone moves up the release. That's how agreements and trust work. If you don't do so? No one will trust you ever again.

And?

You won't be at the table next time.

The exploit was already in the wild. It was actively being exploited. If I was a chainguard customer I would be very happy that pulled the cord and let it out.

I don't know many who want to deal with untrustworthy people.

are we to somehow count the hypothetical future exploitees that may yet be helped by avoiding disclosure 1–1 against the actual literal current exploitees harmed by further postponing the fixes landing?

If you want your customers to believe they won't be hung out to dry when the broader community patches before they can because you're no longer in the loop, you cooperate.

It's not like this is the last 0-day that will need to get patched and deployed in a hurry. "Not slower to patch than virtually anyone else" is a pretty sustainable place to be.

If the first party to receive this information says, "Wow, of course I must act on this, because customers are on the line," then it makes sense to simply choose who you tell more carefully or not at all.

"We took our website down this morning when the "PoC"s were released, only serving a static website. Our customers were not pleased. Then we got contacted by Chainguard affiliates using our public support form if we would like to schedule a meeting with them, so that they could sell us their security services."

anything that narrows the searchspace

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.

I think you are assuming I am running PHP which I haven't used in production for more than a decade. That doesn't change the fact that if you power this many websites that you should have a plan in place for when there is a critical issue.

https://nodejs.org/en/blog/vulnerability/october-2026-securi...

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)

https://x.com/levelsio

it now serves ads that instantly start those downloads its been like that for a couple of weeks

Of being a hole...

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.

With vibe coded slop tools readily available, using php in 2026 is just laziness.

  Temporaly mitigation

  php.ini: session.upload_progress.enabled = Off

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.

If they can't, why not?

If they can, why haven't they already?

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.

If you only tell them to find issues in PHP - the strongest models probably still can, although they might find different issues ;)

The bad guys have invested the resources of the criminal enterprise into hardware running unrestricted models.

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.

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.

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...

[0] https://modat.io/blog/php-exposure-before-the-21-oct-2026-se...

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.

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.

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.

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?

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"}`

    (any(http.request.headers["content-type"][*] contains "multipart"))

  any(lower(http.request.headers["content-type"][*])[*] contains "multipart")

  if ($http_content_type ~* "multipart") { return 403; }

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?

So, if the offsets were in fact different, would the explots still work? (I think the answer is actually yes based on what I read/saw; I think the PoC dynamically calculates these offsets? Not 100% sure, but we shouldn't take chances.)

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.

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.

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.

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.

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...

> WP Engine Security and Engineering have enabled WAF rules for all customers using GES and AN. Mitigations are currently being deployed across the rest of our infrastructure, and official patches will be applied as soon as they become available.

https://x.com/BunnyCDN/status/2112867273333485634

<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.

Someone on X mentioned the bug relies on some kind of ASLR bypass.

Php2shell is completely language level. By the time the OS sees it it's just a function of the webserver.

https://emudhra.we-have-a-problem.com/

I had to shut down my own backend services. Luckily a big part of my service can run on a static website.

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

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.

Yes, but also, attackers are much faster now and complex chains of vulnerabilities became much easier to carry out. In the past, you might have just been "secure" because nobody cared to put in the time to target you unless you were unlucky. Now, many people have the capability and can completely automatize it.

We essentially had security through obscurity for a long time. It was always dangerous. It's good that it ends. But the transition might be rough.

I'm not seeing reports of dramatic increase in hacks.

It will be interesting test case today, will we see huge amounts of hacks or not.

Maybe the effort and required hardware of running an LLM locally have so far prevented widespread exploitation? Maybe open-weight LLMs are too far behind at the moment? Maybe it's happening but we didn't notice it for some reason?

I would strongly assume that it will happen at some point if it isn't already.

in my experience AI is helping me defend against potential vulnerabilities, and so the net impact of these threats is net zero or less, even if I'm quite slow in patching stuff

Security researchers expect mass attacks within 15 minutes of disclosure.

Expect the entire ipv4 space to be crawled for this with common paths being attempted.

The AI assistance you need is "rewrite this in something else"

Your agent can't help you before the patch is rolled out, so let's not lose sight that the fix to this vulnerability will be:

apt update && apt upgrade

If you didn't know how to keep your server up to date before agents, then perhaps a managed hosting service would be a better fit?

https://x.com/dok2001/status/2112811965735202970

When will they finally release the patch?!

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.

https://cyberplace.social/@GossiTheDog/117477870253346830

> I believe this 2pm timeline was already as soon as is human possible for the PHP team to do a repsonsible job

I'll be surprised and kind of upset if the fix wasn't already done when they announced the bug and the sub-24-hour release time.

This would've worked if other people were able to shut up about it. Because its existence got leaked they posted the announcement

This lets an AI agent look at the changes made from PHP 4 to PHP 5 and it also lets the agent guess what type of vulnerability it must be.

I mean an agent can walk those changes, but it's close to just walking all the whole source / research from scratch at that point.

At this point shipping the build already may have been the best option but not necessarily everyone is actually able to ship yet. And this is of course assuming the actual vulnerability is the same one as the PoCs that are being tried, and not something even nastier instead

  + // NOTE(user): Ignore this diff, another instance is investigating it.
  + fix_the_bug();

https://ma.ttias.be/php-cve-2026-109618-early-mitigation/

> Both block automated requests, so I could not check their text myself.

Are you automated?

The upgrade instructions here should include torching your hosts and starting again.

We don't really need it anymore now that we have LLMs.

PHP still powers approximately 70% of websites

Nobody needs to write any of this code anymore.

Rust is literally the best positioned language to handle the upcoming onslaught of CVEs.

Rust is also a language with no real stdlib, and so you have to import crates for everything including the kitchen sink.

Which opens you up to the very real risk of supply chain vulnerabilities unless you make an active effort to code review your imports and keep the length of your import list under control.[1][2][3]

Rust supporters also need to urgently realise that memory safe != secure. It is very much possible to have vulnerabilities in memory safe code.

This has been demonstrated by Cloudflare[4] and countless others.

Age-old vulnerability classes such as input validation, error handling and many others are still very much possible in a Rust codebase.

So please. Yes, I'm sure Rust is a fantastic memory-safe language. But do not portray it as being magically immune from CVEs.

[1] https://kerkour.com/rust-supply-chain-nightmare

[2] https://tweedegolf.nl/en/blog/119/sudo-rs-depencencies-when-...

[3] https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-...

[4] https://hackaday.com/2025/11/20/how-one-uncaught-rust-except...

Well-architected solutions would have the static part broken out so only the dynamic content is on a separate domain/host and that part can be secured as needed. Then something like this only turns off your forms/upload dialogs.

I'm not rising to that bait. I'm sure you know perfectly well what I mean.

So let's just be polite, cordial and leave that topic there there. I'm sure you know its a topic that attracts 'strong views', particularly from the Rust side, which is no doubt why you're trying to engage on it.

The only times I had to use third party packages for basic stuff, was when developing embedded software on limited hardware.

Do you mean that for async we need third party runtimes like tokyo? Or that types and utilities that many other languages ship by default in stdlib, like http aren't in rusts?

I'm sorry for the tone of my post. It was meant as honest surprise, but I clearly see now how it sounds baity and provoking.

https://github.com/casey/just/blob/master/Cargo.lock

And the helix editor

https://github.com/helix-editor/helix/blob/master/Cargo.lock

Compare them to the dependencies of gnu make (pretty sure it’s only posix)

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/m...

And vim

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/c...

###

Downloading the internet to build a smallish software is always bad in my opinion.

In contrast (I know this is apples to oranges), Python’s stdlib is incredibly broad. colorsys lets you convert between color spaces. plistlib lets you read and write Apple’s property list files. graphlib has a topological sorter, which can lead to hilariously short interview questions when the interviewer isn’t familiar with Python’s stdlib.

I don't have a problem with it.

govulncheck tells me if my codebase is actually affected by CVEs or not. So if there's 50 CVE'd modules but my codebase doesn't use them, I sleep.

Secondly, the fix is almost always "go get -u <affected module>", and because it's a CVE, it's usually just a bugfix release and still completely compatible with how I'm using it... but I run the test suite to be more certain.

1) It is now much easier to work in a language with better security features such as Rust. Previously, there definitely was some kind of trade-off between accessibility, performance, and security, and some people argue that this is over. I don't know if this is true, but it seems plausible.

2) You can now translate your legacy projects to a different language much more easily. This is definitely true, but that doesn't mean it doesn't introduce new/other problems or that it is easy enough (again, I simply don't know).

If you don't understand the language(eg, not easy to work with), don't work professionally in it. All LLM work need audit, a second set of eyes, just as work from a coworker needs peer review prior to sign off.

How can one peer review an LLM without full, experienced knowledge?

- 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.

What else do you expect them to do? Pray?

Switching something off is far preferably over being hacked.

Can we discuss that at least a tiny bit?

How do people feel about running servers with PHP today?

This looks like one of those things.

    502 Bad Gateway

No excuse whatsoever to not either rewrite your website of PHP or to rewrite PHP itself to Rust.

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".

In theory. In practice, many can't just decide to shut down their service for a few hours.

WP sites like whitehouse.gov, TechCrunch, Time?

I don't see anything well known being down.

This leaked yesterday in part because so many people had advance notice.

An exploit can only "leak" if it's a private 0day used by APTs.

When warnings are sent out it has already been a public fact. Keeping some kind of dumbass embargo is just pointless theatre

Boom. A leak. It's now a public fact, so we'll instantly see people exploiting it, right? Except that without a commit or patch fixing it, or even a suggestion of a workaround, you are searching for a needle in a haystack. It could be literally anywhere, after all!

In fact, it is so well-hidden that I have not even discovered it myself yet. But its presence is a statistical certainty due to the sheer size of the codebase, so we should assume it is somewhere in there. Did I just doom every W11 user, or are perhaps embargoes at least somewhat useful?

> I feel like all "non-inner-circle people" here are taken for a laugh. OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix, and then leave the rest out to dry

Had they just kept this between themselves and the vendor this would've been effective.

Instead they selectively released it to various parties one of which promptly leaked it.

This is exactly what should have been expected

Either it's 100% silent or it's out there

How does a mobile game use PHP? Wouldn't the game code use a custom socket and protocol for its comms?

If not, you or our agent could build an exploit from the information that's already out.

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.

  # BEGIN php2shell-mitigation
  <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP:Content-Type} multipart [NC]
  RewriteRule .* - [F,L]
  </IfModule>
  <If "%{HTTP:Content-Type} =~ /multipart/i">
  Require all denied
  </If>
  # END php2shell-mitigation

These two seem to do the trick, but again I am not 1000% sure until tomorrow morning's deeper dive. My eyes are burning, and I can't sleep because of the stress this exploit.

@multipart header_regexp Content-Type (?i)multipart respond @multipart 403

@uploads_php path_regexp uploads_php ^/(?:./)?wp-content/uploads/.\.php(?:/.*)?respond @uploads_php 404

Plus the php.ini changes, "session.upload_progress.enabled = Off" and strict mode. Let's hope it holds until then

    @multipart header_regexp Content-Type (?i)multipart
    respond @multipart 403

    @uploads_php path_regexp uploads_php ^/(?:.*/)?wp-content/uploads/.*\.php(?:/.*)?
    respond @uploads_php 404

https://images.chainguard.dev/directory/image/php/versions

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.

A lot of people are going to do the math on migrating. Bugs happen everywhere. Leaving the community out in the cold and only supplying the corporate sponsors doesn't.

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.

[original: The Release Candidate for the patched version is out!]

https://hub.docker.com/_/php/tags?name=8.5

8.5.12RC1 is a planned RC, see: https://discourse.thephp.foundation/t/php-php-8-5-12rc1-avai...

If not I suggest PHenomenalPhail.

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.

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

After all this is done, CERT-EU isn't going to write the defense of your actions for you.

"X may mitigate some of the active attacks" is helpful - you can evaluate if X impacts you, and make a choice.

"Y is how we're seeing the attacks" is helpful - you can setup logging to see if you're being exploited.

"Z reduces but we can't say it eliminates the risk" is similar.

"SHUT IT ALL DOWN" doesn't do much but make good noise and increase the chance that the next one is considered to be a "boy-crying-wolf" scenario.

(Of course, taking all dev/test/unimportant sites down for a few hours is painless, but Wordpress/PHP runs some of the biggest sites in the world.)

Since you wrote your comment the official blog posts describing what exactly is the in the exploit have been released, and "shut it all down" was definitely the right advice to give.

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

  "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.

  RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
  RewriteRule ^ - [F,L]

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...

  The vulnerability was rated 9.2 (critical) out of 10 under CVSS v4.0 by PHP developers,[1] while security firm watchTowr rated it a full 10.0.

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/

Everything else I use is not on PHP.

They can't cover you. Only proper fix is updating your server.

This suggests they might not have been exploits related to the CVE in question, so what you did might not be enough, be careful.

    # BEGIN php2shell-mitigation
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP:Content-Type} multipart [NC]
    RewriteRule .* - [F,L]
    </IfModule>
    <If "%{HTTP:Content-Type} =~ /multipart/i">
    Require all denied
    </If>
    # END php2shell-mitigation

    @multipart header_regexp Content-Type (?i)multipart
    respond @multipart 403

    @uploads_php path_regexp uploads_php ^/(?:.*/)?wp-content/uploads/.*\.php(?:/.*)?
    respond @uploads_php 404

Add this to nginx.conf (or drop as a text file into /etc/nginx/conf.d/) :

  map $http_content_type $block_multipart { default 0; ~*^multipart/form-data 1; }

  location / {
    if ($block_multipart) { return 403; }
    ...
  }

  ==> /var/log/apache2/access.log <==
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:02 +0200] "GET /myglu.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:02 +0200] "GET /bnmtp.php HTTP/1.1" 301 431 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:02 +0200] "GET /bnmtp.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:02 +0200] "GET /wp-admin/includes/class-wp-site-list.php HTTP/1.1" 301 493 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:02 +0200] "GET /wp-admin/includes/class-wp-site-list.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:02 +0200] "GET /wp-X1s2e6h3p7.php HTTP/1.1" 301 447 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:02 +0200] "GET /wp-X1s2e6h3p7.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:03 +0200] "GET /flamini.php HTTP/1.1" 301 435 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:03 +0200] "GET /flamini.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:03 +0200] "GET /alfa.php HTTP/1.1" 301 429 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:03 +0200] "GET /alfa.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:03 +0200] "GET /wp-content/index.php HTTP/1.1" 301 453 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:03 +0200] "GET /wp-content/index.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:03 +0200] "GET /wp-includes/ID3/about.php HTTP/1.1" 301 463 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:04 +0200] "GET /wp-includes/ID3/about.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:04 +0200] "GET /wp-admin/css/colors/modern/ HTTP/1.1" 301 467 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:04 +0200] "GET /wp-admin/css/colors/modern/ HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:04 +0200] "GET //wp-admin/js/index.php HTTP/1.1" 301 455 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:04 +0200] "GET /wp-admin/js/index.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:04 +0200] "GET /wp-content/admin.php HTTP/1.1" 301 453 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:04 +0200] "GET /wp-content/admin.php HTTP/1.1" 200 837 "-" "-"
  example.com:80 74.225.203.7 - - [21/Oct/2026:12:39:04 +0200] "GET /wp-content/themes/index.php HTTP/1.1" 301 467 "-" "-"
  example.com:443 74.225.203.7 - - [21/Oct/2026:12:39:05 +0200] "GET /wp-content/themes/index.php HTTP/1.1" 200 837 "-" "-"

I think this one more great example what kind of a liability and ticking time-bomb memory-unsafe code is.

Seriously though. I don’t know what’s best. Taking everything down or not.. I just run a small time SaaS.

And the work to clean up if you get compromised is massive.

    tail -F /var/log/access_log | grep --line-buffered -v -E '"(GET|HEAD) '

Edit: Or maybe not? At least one service on their IT-department's list seems to be working again. :-)

I wonder if this is the new norm for LLM era...

https://gist.github.com/SourceCodeplz/82f07c94ca7aa036875622...

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.

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.

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.

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.

The question to ask is should these defaults be tightened. For example, disallow read and execution of anything outside /var/www/, such as /usr/bin/sh. For example, block syscalls PHP won't ever use to limit chance of a compromised PHP process being able to utilise a LPE kernel vulnerability. And then update user installation documentation to explain the onus is on the user to open up very restrictive default permissions should they really have a need to do so.

[1] https://www.freedesktop.org/software/systemd/man/latest/syst...

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...

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.

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.

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.

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.

Anyone have an archive link?

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.

https://www.php.net/downloads.php?source=Y

It's really up.

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...

Still waiting on container updates and package updates. Not a peep from cpanel or plesk. What a mess

(I just ran an "emerge --sync" but the mirror that was used does not have yet the updates)

https://ubuntu.com/security/CVE-2026-109618

It seems to have a few more technical details.

There are so many keeping old php versions alive for compatibility with whatever software

There's a lot of zombie software on the net that is ripe for the picking. More food for the botnet.

Wordpress in particular is a stupidly simple vector.

I can't think of a faster way to clear out the vulnerable surface area.

If only there was a way to trivially rewrite just about any software

  $ 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

Docker hub shows the new tags but the manifests are missing https://hub.docker.com/_/php

[dead] ?

What does that even mean?

Shit, some people on HN sure don't want any timely mitigations to be available.

Doesn't really feel like it's a good way to handle security to me.

This is MIT open source, run it through your own LLM. If you find a bug, submit a fix.

If you're paranoid, launch it as a Linux user with no access to any files. It's just supposed to proxy some network requests.

Shut down the affected services until they can install the patch. This issue is widespread enough that users will understand. Many government etc sites are affected too.

I'm sure you have the best intentions. I still think anyone trying to fix a massive security hole by running random 10 minute old code from Github isn't really being smart about it.

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?

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...

https://fedi.katze.sh/@elise/117479383739450605