Many here call for an earlier release of the patch.

But it is not clear if releasing the fix early would make the damage smaller or larger.

Having the patch probably makes creating an exploit easier. So the number of attacks would increase.

There is no way to coordinate the whole world on an earlier time. I would guess the number of people who have to patch their instances is in the hundreds of thousands.

Everybody who actively watches the topic already has the option to shut down their instances.

So ringing the bell and getting as many people as possible to shut down their webservers now and patch at 14:00 might be the best in terms of damage minimisation.

By the way, it is not enough to just "shutdown -h now" and then later restart and "apt update && apt upgrade". The moment the machine comes back, it can get hacked. So you should make sure the webserver does not start after the next boot. For Apache this would be something like "rm /etc/systemd/system/multi-user.target.wants/apache2.service" and then after patching recreate the symlink via something like "ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/apache2.service".

Fixed versions have been released slightly early, along with full technical details:

https://www.php.net/archive/2026.php#2026-10-21-5

RCE via OOM corruption - https://github.com/php/php-src/security/advisories/GHSA-w8hw...

RCE via stale global state - https://github.com/php/php-src/security/advisories/GHSA-6wmf...

DigiD.nl (login to government services), RTL (major broadcaster) and parliament shut down their websites. https://nos.nl/liveblog/2636066-websites-kwetsbaar-voor-soft...

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

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.

Given that this affects every PHP version from the past decade, and that the exploit instructions are circulating at the top of twitter, and that there's no fix available yet, it doesn't seem outrageous to assume every major PHP website is already compromised?

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

I tried it on a personal site, was able to dump the entire database. Immediately shut all my sites down. This is bad.

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.

Cloudflare: "We are seeing early attacks emerging and are updating mitigations as new vectors show up."

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

When will they finally release the patch?!

Just made the call to take all my customers apps offline until this is fixed.

Can’t find any reliable information on what to do prior to the patch, seen some info that turning off session progress does not mitigate.

Anyway.. back to calling everyone

From what I can tell, Cloudflare has mitigated this via their WAF [0] (free and paid).

The Alpine GitLab[1] indicates the PHP versions to be released 21-10-2026 14:00:00 UTC are:

8.5.12 8.4.27 8.3.36 8.2.35

[0] https://developers.cloudflare.com/waf/change-log/changelog/

[1] https://gitlab.alpinelinux.org/groups/alpine/-/work_items?sh...

The patches are out: https://www.php.net/archive/2026.php#2026-10-21-5

If the rumors for these exploits being shared on Twitter are correct this is going to be a nightmare. I wouldn't be surprised if VPS hosts step in to mitigate it somehow since so many cheap/unmaintained LAMP installs are running on those servers.

Two things you can do now:

1. Turn off session upload progress

2. Block multipart requests at the web server

More info: https://www.vincentschmalbach.com/cve-2026-109618-and-cve-20...

Here's what I did at least.

I initially updated the following php.ini setting and verified that it updated via phpinfo(). I understand this to be only a possible mitigation (see below).

  session.upload_progress.enabled = Off
  file_uploads = Off

According to someone stating they are one of the PHP release managers:

  "INI settings alone won't protect you. You need to patch PHP."

https://www.reddit.com/r/PHP/comments/1xb2utu/comment/phyu5m...

I use Apache, and added an htaccess rewrite rule in my base directory to block all requests containing multi-part headers. Rewrite rules can also be added into Apache virtual host blocks. Accepting file uploads are not a critical function of the app in my case. This blocks multi-part form requests before they reach PHP.

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

And verified the non-block vs. block case. https://freeimage.host/i/nOqumyN

I'm continuing to learn about the situation and may take the server offline as I learn more.

The writeup I found here:

https://jackalsyn.com/posts/php-up-2026.html

Content from a couple of my ChatGPT 6 Pro sessions about the issue:

https://chatgpt.com/share/6ad89ea3-b2f0-83ea-9c4c-2ecf5cc24b...

https://chatgpt.com/share/6ad8ad3d-3f6c-83e9-abf0-41da8a0d65...

  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.

https://en.wikipedia.org/wiki/PHP2Shell

This is notable enough that the prime minister of Japan has tweeted about it: https://x.com/takaichi_sanae/status/2112890642590564386

I'm keeping a list [1] of all the (possible) precautions one can take, ahead of the patches appearing in a few hours. Exploits are now circulating, according to Cloudflare's CTO, so _any_ mitigation is worth investigating

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

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.

Strange to see this so far down the front page. If the rumors are true, it may be worse than Log4Shell.

I'm not seeing any discussion here about woeful web application architectures from the 1990s still in use?

The single biggest problem I came across over a decade ago when maintaining an open source PHP web application was web applications at the time typically having access to a common database server role (often also common between users and administrators) which allowed a web application process to read and sometimes write to the entire database. No use of user-specific roles in database servers and row-level-security/column-level-security authorisation. At the time I don't think PostgreSQL even had row-level-security support built into it. A runaway PHP process could return the entire database to the attacker, or change every single row of data held within the database.

The second biggest and related problem was web applications accepting files uploaded from users, or having to generate reports (maybe with external software) and save them to disk for a user to download, and not being able to ensure a runaway PHP process can't just dump all of those files or reports to an attacker. You might have been able to store the user files (or at least a decryption key for the files) in a database but then you're back to dealing with problem (1) above.

Even a decade ago it was fairly common for web application developers (of the PHP sorts too) to be well aware of the need to make their web root read-only, put the web application source code into a read-only directory outside the web root, execute interpreters such as PHP with "nobody"-like permissions, launch a new interpreter process for each connection (not multiple threads within the same process), firewall off the server the web application sits on so a runaway PHP process can't connect to internal servers, etc. Outside of an attacker messing with a database, most other aspects of PHP web applications at the time were immutable if the web application developer / system administrator had setup the environment correctly.

Is there a solution for (1) and (2) for PHP web application development that has become popular in the proceeding decade?

edit: also nominating the shared $_SESSION state of PHP that was typical a decade ago to just be left to default (e.g. all PHP processes just read/write session files to a common /tmp directory). https://www.php.net/manual/en/function.session-set-save-hand... should probably instead be used by web application developers to somehow better isolate session state between users.

Just shut down our MediaWiki site temporarily out of an abundance of caution. The twitter videos look scary...

Node.js has also announced security releases: https://nodejs.org/en/blog/vulnerability/october-2026-securi...

It's going to be hilarious if I'm not vulnerable because I'm running PHP like it's 1995 via CGI and so get a brand new process per request and break ASLR infoleaks by side effect.

That is definitely very not good.

I got into software dev because of cyber sec, and almost everything I learned revolved around poorly implemented php, so I always stayed away from it when building

but this time it's php directly? that's scary

There’s already a Wikipedia page for it: https://en.wikipedia.org/wiki/PHP2Shell

Talked to my clients this morning and persuaded most of them to shut down the services and wait for the patch. For most of them it's cheaper to lose a day of work than to pay for recovery. Scary to be in a situation where you have no fix/workaround in sight.

Surprising that this sort of vuln can exist for DECADES. Perhaps software really is too complex for all its behaviours to be outwardly visible. Many student-run services are down right now, even the lunch menu website is going down for maintenance.

Looks like news-web.php.net is offline now?

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

I'm glad to not maintaining PHP services right now, this will be a historic event.

For those of you using PECL as part of your image build pipeline. I'm seeing timeout issues downloading packages. PECL has been deprecated in favor of PIE. I'd recommend switching to PIE if your build relies on PECL. You don't want to run into this as you rush to update your images.

how does Docker not yet have a new, official PHP image ready? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are :20 minutes past due. Everyone had a multi-day heads up, this is negligence

I just took down my 10 or so sites until the fix is out. A few hours of downtime versus worrying something got injected in my cache or db

Took a quick peak at the relevant C code and what I think are the offending lines seem somewhat suspicious right off the bat.

Fil-C should have caught this right? I wonder if it would benefit the PHP ecosystem as a whole if the releases are built with it instead.

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?

This currently returns

    502 Bad Gateway

According to this https://jackalsyn.com/posts/php-up-2026.html, you need the dtor to successfully replicate the RCE on a live server.

So, theoretically, if you wanted to hack a server but you don't know what OS/PHP, version they're running, you could compile a list of every delta for every litespeed release and then bruteforce it, right?

Discussions: https://smackernews.com/item/50172041 HN

https://smackernews.com/item/50176077 HN

https://smackernews.com/item/50180836 HN

Is OpenBSD affected or have all their schizo mitigations finally paid off?

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

I actually looked through PHP code responsible for parsing POST request body and it's pretty bad [1].

First, there is a huge function, that is hard to read and reason about. Second, instead of proper parsing of "Content-Type" header to extract "boundary" parameter, there is just a set of substring searches which is not correct. It doesn't mean there is a vulnerability but it means PHP can read the header in a way different from a standard-compliant implementation (such as web server, WAF etc).

[1] https://github.com/php/php-src/blob/master/main/rfc1867.c#L7...

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.

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.

This has been out for hours! Why is this not the top post here? It's climbing, and hopefully will soon be, but... This is massive, right?

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

Seems like even the EOL versions should get a patch for something like this.

I like PHP and I use it everyday. What concerns me about incidents like this isn't just the vuln itself, but how much access a compromised PHP process can have to the rest of the system.

Dumb question: does this affect a backend even if behind an ouath wall?

So all local universities have now essentially shut down their web-services for students. This is ... kind of curious because now you can not download recent updates (e. g. new .pdf files published) from that software.

We need a long-term solution with regards to PHP. PHP is a success story - so much web-software depends on it. But it also has become a liability when they are all now scared that the server can be easily taken over. This is not acceptable, PHP.

I suspect we might be about to see a big Bitcoin mining boom...

Looks like Plesk will backport the patches to old PHP versions (7.4 to 8.1) https://support.plesk.com/hc/en-us/articles/44397729587351-V...

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.

A lot of people are going to be up late on account of this.

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.

Management doesn't want us to disable our websites. We got hundreds of client facing apps. We're just waiting for the patch

while waiting for the official patch, run this read-only script to check /var/www for changes and other things.

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

This is going to pop a lot of wordpress sites.

https://gerrit.wikimedia.org/g/mediawiki/core says "Error: please contact the wikimedia SRE team to discuss a less disruptive approach at ..." Related?

https://x.com/J4ck3LSyN/status/2112703096443097263 Already being exploited. They need to release the patch now, not later. This is already being deployed by attackers as we speak.

What steps can someone take to determine if they might have been hit?

So far, I have checked to see if any new files have been placed in our directories or if there have been any file changes. I've also looked at the access logs for unexpected POST requests.

Are there any other steps?

Docker images are cooking https://github.com/docker-library/php/actions/runs/396158697...

In terms of taking sites/applications down, if you have a maintenance mode that serves only HTML does that seem sufficient at the moment, or is the mere presence of PHP on a server enough right now to warrant "entire server, off button"?

Shit got real. All my favorite places are hunkering down, like https://www.vogons.org

<p>Due to an <a href="https://www.php.net/archive/2026.php#2026-10-20-1">upcoming significant vulnerability disclosure</a> with no official mitigation, services are currently offline as a precaution. Services will not be restored until at least later in the day on October 21. This time may also be spent on additional maintenance, so this message may be periodically unavailable.</p>

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 had my app running on unsupported php version for 'years', because i didn't have anyone handy to update it.

so even if it takes a few days to get my AI agent to do this, it's still a vastly more secure landscape for an amatuer like me

Edit: my message was wrong, see below.

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

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

hmm... how credible is this? appears to not be fully fixed?

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

This seems serious enough that I've contacted a few less-technical loved ones about it. I'm warning them of possible scams in the next days, perhaps even hosted on otherwise official pages.

Hahaha, good morning Eastern Time folks. Heck of a day ahead.

TiDB, eMudhra CA, and this

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

Getting Bad Gateway.

Would blocking all multipart/formdata requests be a sufficient mitigation until the updated php version is available?

No hints as to what versions are affected?

The official php advisory has been hugged to death? What a clusterfuck

Anyone have an archive link?

Uh oh, POC is already out there https://jackalsyn.com/posts/php-up-2026.html

I would really like a list of all major websites using PHP so I can continue to avoid ever using them again (something I already try to do). This whole situation should make it clear who was affected by their downtime in response.

There is allegedly a temporary mitigation: https://twitter.com/k_firsov/status/2112718728232329240

php.ini:

    session.upload_progress.enabled = Off

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.

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?

The release is now available: https://www.php.net/index.php#2026-10-21-5

2027 is going to be crazy

I don't want to jinx it but... A discussion about, of all languages out there, PHP being the one hit by that and not, say, Go or Java or Rust or Haskell etc.?

Can we discuss that at least a tiny bit?

How do people feel about running servers with PHP today?

i started seeing a lot of scans on my webservers:

  ==> /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 "-" "-"

They need to release it now.

I suppose this will go down in history :|

Well we all got fucked by this cert issue.

Pure LOLPHP matrial

Some more discussion: https://smackernews.com/item/50171528 HN

"No way to prevent this" say users of only language where this regularly happens.

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

It is a yet another reminder why we should start new projects with Rust and dig C and C++. Why would anyone want to use C.

PHP is truly a garbage ecosystem. I thought log4shell was bad but this is 100X worse.

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

the php team should consider leveraging ai to rewrite the interpreter in rust like bun did recently

Is there already a name for the vuln?

If not I suggest PHenomenalPhail.

This might be the nail in the coffin for php.

Heap use after free?

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

I recently changed my mind here.

Why?

Because some upstream services here in central Europe, are closed down because of that PHP problem. So now I am annoyed since this disrupted my workflow.

PHP, please either get your act together - or disband.

How is the patch still not out yet? This is another case of big tech players all colluding together leaving all the small guys out to dry.

At least this time we can have LLMs rediscover it and make patches ourselves.

Here is the patch I had an LLM come up with against master: https://pastebin.com/raw/EUCF0SR0 It at least stops the PoC which is better than nothing.

I hope that people will realize that PHP is unsuited for public websites and that they need to switch to secure technologies like Java, ASP.NET or Rust.

PHP contains an almost endless stream of vulnerabilities since its inception almost 3 decades ago. Proponents claim that it's getting better but this just goes to show that nothing's changed.

A user on X claims:

  Temporaly mitigation

  php.ini: session.upload_progress.enabled = Off

https://x.com/k_firsov/status/2112718728232329240#m

https://xitter.cf/k_firsov/status/2112718728232329240#m

Honest question, who uses php anymore?

I know there must be a ton of random sites which makes this a huge deal.

But, does it affect any big players? I think php is big at Meta but I would imagine its so heavily customized it might be safe from this.