There comes at point at which it is better for everyone to just disclose the details and pursue Full Disclosure. I think we reached that point hours ago.

It has been incredibly frustrating watching Twitter and that (potentially, I don't know how reliable the leaks are) being a better information source than anything else, at least so that those of us hosting stuff ourselves can try and explore if there are any defensive measures that can be put in place in lieu of any actual fixed builds being released.

I suspect this is already being actively exploited now.

https://x.com/J4ck3LSyN/status/2112703096443097263

They've now posted a proof of concept as well.

@dang if the speculations circulating around are anything to go by this is apocalyptic and deserves to be amplified such that the right people see this before it’s too late.

CERT-EU even suggests isolating any systems that may be exposed and can’t be patched quickly.

Speculation is that the affected subsystem runs before any application code and affects all default installs.

Deciding to announce it like this is wild, it's an invitation for everyone to put their agents to work in order to find out what the vulnerability is and exploit it, while nobody is allowed to patch it until tomorrow.

Tweet allegedly showing exploit at work:

https://x.com/k_firsov/status/2112641845926989944

(video). Yikes

Rumored mitigation from other HN threads:

Mitigation for impacted versions is to set `session.upload_progress.enabled = Off` in php.ini

It's a feature my wiki doesn't use, so even though I'm patching ASAP it did me no harm in flipping that bit. In fact, I could probably just shut down my server for the day...

edit: I simply shut down my dokuwiki for the day. No one uses it but me anyway.

edit2: https://old.reddit.com/r/PHP/comments/1xb2utu/upcoming_criti...

Someone claiming to be a releng for PHP says INI settings won't save you.

Looks like details about the exploits have already leaked on twitter, if the info is correct then it can be mitigated by setting session.upload_progress.enabled = Off until you get the opportunity to update

This was supposed to be embargoed.

So your reliable source can't keep a secret.

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

This vulnerability has already been reproduced by a third party with LLM assist. And of course they posted the details on Twitter - and someone else posted the link here just now. So the cat's out of the bag.

That means roughly 70% of all websites (WordPress, Laravel, Drupal, Joomla, Magento) are currently open to remote code execution. About half of that is running an older PHP 5 and 7 that apparently will not receive the urgent security patch.

Two heap use-after-free primitives in PHP's `session.upload_progress` handler

Guess it's time to rewrite PHP in Rust. Claude, make no mistakes, you can do it!

Official statement released by PHP: https://www.php.net/archive/2026.php#2026-10-20-1

Statement by CERT-EU: https://cert.europa.eu/publications/security-advisories/2026... :

Where immediate patching is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is available.

It seems serious. Well, good luck isolating all PHP applications from the public internet...

Well great thanks. I need details now. Where, core? Extensions? What config?

My guess is on some request filtering thing

Those CVEs refer to vulnerabilities in wordpress plugins (not php) and the vulnerabilities are not RCEs.

Am I missing something?

https://nvd.nist.gov/vuln/detail/cve-2026-9618 https://nvd.nist.gov/vuln/detail/cve-2026-9619

Hey guys,

I have a long day tomorrow auditing all our php websites and so I wrote a simple CLI tool that finds every place php version is mentioned in a repo eg (Dockerfile tags, compose/k8s images, setup-php in CI, .tool-versions, distro php packages, composer) and flags the end of life branches now.

Floating tags and distro packages can't be labelled deterministically since the tool only reads the files right now so they get labelled "check manually"

I will also update the package as soon as the fixes drop with the updated versioning which will not require anything on the users end (no updates required)

Till then check out npx php2shell-repo-audit . https://github.com/Amsozzer1/php2shell-repo-audit

Well this is about as bad as it gets, so I guess the internet will get a bit of test and old forums will turn into a botnet

Details about the exploits have already been leaked on twitter, don't want to put the details here but if its correct then it can be mitigated by setting session.upload_progress.enabled = Off

This is why I abandoned PHP years ago. All of my stuff is static site now. Generated by Pelican.

PHP has an abominable security history. I thought it was actually falling out of fashion. I was shocked today to hear it powers 69% of the web still.

https://github.com/consocio/php2shell-audit/ GLM 5.3 just wrote it to audit all my php sites. I hope it is useful to you

Quick correction to the text above, PHP says the patch/announcement will be available Wednesday, 21 October 2026 at 14:00 UTC.

https://www.php.net/archive/2026.php#2026-10-20-1

Here's the alleged demo video. It's called php2shell https://x.com/k_firsov/status/2112641845926989944 and it's scary as hell.

If you don't do local file include (LFI) esp. from a $_GET or $_POST then to what degree would the site be impacted?

well, until the patch drops I'm pretty much vulnerable.

I went and disabled my websites that run on PHP, and I will most likely migrate it to a VPS. maybe even another language like golang.

The full details will be available on 8:00 AM at Mexico City