Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming

Posted by petecooper 1 day ago

A reliable source has indicated an announcement is scheduled for 22 October 2026 at 18:00 CEST regarding 2x PHP RCEs with a CVSS score of 10.0.

I have no evidence beyond "source: trust me, bro", but if you're running PHP in production, be ready to update as a priority.

These CVEs reportedly relate to remote code execution in all affected PHP versions from PHP 5 onwards.

These are the two reserved CVEs for the reported upcoming announcement:

CVE-2026-109618

CVE-2026-109619

Comments

Comment by lol768 1 day ago

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.

Comment by jwitthuhn 1 day ago

Seems like some of the people engaging in "responsible disclosure" were not very responsible and it leaked out.

With that info public they do really need to just release the fix, assuming that tweet is accurate.

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

Comment by lol768 1 day ago

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

I think this is only partial mitigation: https://x.com/Dinosn/status/2112717168349712734

I have additionally followed the advice to just ban multipart uploads before the request even touches PHP (luckily my app doesn't use them at all). I do now know if this conclusively resolves it.

Comment by Webfiletools_de 1 day ago

One gotcha for anyone applying this tonight: on a lot of Debian/Ubuntu-style setups the CLI and PHP-FPM read different php.ini files (for example /etc/php/8.x/cli/ vs /etc/php/8.x/fpm/), so "php -i" from a shell can show it Off while the web side still has it On. Check it through a phpinfo() page or the FPM binary itself, and remember to reload php-fpm afterwards. On shared hosting where you can't touch the main ini, it should be settable per directory in .user.ini, but that file is cached for a few minutes by default, so give it time before testing. And as others said, treat it as a stopgap until the actual patch lands.

Comment by devttyeu 1 day ago

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

Comment by extraduder_ire 1 day ago

@dang is a no-op, you need to email him or the hn@ycombinator.com address

Comment by phab 1 day ago

Tweet allegedly showing exploit at work:

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

(video). Yikes

Comment by 1over137 1 day ago

This seems to work without an X account: https://nitter.app/k_firsov/status/2112641845926989944

Comment by uncletammy 1 day ago

But not with a vpn

Comment by Jotalea 1 day ago

nitter instance: https://twitter.jotalea.com.ar/k_firsov/status/2112641845926...

Comment by koolala 1 day ago

This video is iconic

Comment by samueloph 1 day ago

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.

Comment by beberlei 1 day ago

It was leaked

Comment by Operyl 1 day ago

Where?

Comment by walth 1 day ago

Here

https://news.ycombinator.com/item?id=50167754

Comment by Operyl 1 day ago

I don't see any details of the vulnerability leaked except "code execution"...?

Comment by tossit444 1 day ago

It got flagged already, can't see it.

Comment by solyin 1 day ago

Whew! Imagine if the details were documented in the clear on HN for anyone to see.

Comment by dang 21 hours ago

(We've since merged the threads)

Comment by nullbio 1 day ago

It's already been found and shared on X. It's only a matter of hours before untold numbers of sites are hacked.

Comment by samueloph 1 day ago

exactly, that's why in my opinion the patches should have been made available straight away instead of doing this, it made it worse.

Comment by vincent_s 1 day ago

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

Comment by Svip 1 day ago

Or:

3. Disable PHP entirely on your server, and live with broken sites until the patch arrives.

That's what I did; I can live with my sites being down until it's possible to patch PHP. Though, there are likely others who cannot. The CERT-EU advisory is basically advising the same thing[1].

[1] https://cert.europa.eu/publications/security-advisories/2026...

Comment by trollbridge 1 day ago

I maintain one old site in PHP. This just got way easier to communicate with my users when I can communicate that major government services are also offline.

Our current plan is to refactor this into Rust using a coding agent. It looks feasible to get this done today.

Comment by potaytopotahto 1 day ago

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

Comment by 4lun 1 day ago

Not enough apparently

> The PHP 8.6 release manager is on Reddit saying this can’t be fixed with ini settings alone, and needs PHP to be patched

https://x.com/johnplaysdf/status/2112737802379047099?s=46

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

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

Comment by rbarden 1 day ago

The person who posted the main video that's getting shared confirmed this as well: https://twitter.com/k_firsov/status/2112718728232329240

Comment by unreal37 1 day ago

This was supposed to be embargoed.

So your reliable source can't keep a secret.

Comment by JonKF 1 day ago

Responsible disclosure is broken in 2026. All it takes is a vague implication that a vulnerability exists and there are enough people with enough AI tokens that it will be found quickly.

Comment by 1 day ago

Comment by petecooper 1 day ago

Yeah, she lied when I asked if it was under responsible disclosure/co-ordinated disclosure -- otherwise I wouldn't have posted it!

Comment by 1 day ago

Comment by reddalo 1 day ago

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

Comment by lioeters 1 day ago

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!

Comment by jesseschalken 5 hours ago

> Guess it's time to rewrite PHP in Rust.

The Truffle Framework on GraalVM is a better approach to writing interpreters these days, because you get a JIT and lots of language interop for free.

There was a PHP implementation here: https://github.com/abertschi/graalphp

Comment by iheartrms 10 hours ago

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.

Comment by 1 day ago

Comment by Amsozzer 1 day ago

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

Comment by HotGarbage 1 day ago

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

Comment by SchizoDuckie 1 day ago

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

My guess is on some request filtering thing

Comment by reddalo 1 day ago

Yes, it's on core. All versions from PHP 5 onwards. Only PHP 8 will be patched.

Comment by joshuat 1 day ago

So a few million WordPress sites are just going to be overnight targets.

Although I guess that's not a dramatic change in the status quo.

Comment by trollbridge 1 day ago

It's not. I maintain some WP sites, including one that is so custom that it can't be run on a service like WPEngine. I just assume it will be hacked on a regular basis.

Large swaths of the filesystem are chattr +i'd, non-writeable by the user PHP runs as. I have capabilities and network rules applied so that that context can't communicate outbound on the network. I have a WAF that restricts outbound traffic (normal users never download something as big as even 1 megabyte). I have a set of firewall rules to tarpit any automated scans that come near the site.

Nowadays, I run an AI agent continuously that scans the VM everything is hidden in for any signs of an intrusion, plus the host that contains the VM as well. I make sure that agent is sandboxed as well. (This only costs a few dollars a day in tokens which I bill to the customer.)

After this next world-wide intrusion, I may finally be able to convince the client they need to get off the WordPress e-commerce site that they got a teenage girl to do for free a decade ago.

Comment by Yiin 1 day ago

surely not only 8, that would be insane

Comment by rpeden 1 day ago

Everything before 8.2 is past EOL.

Comment by brazzy 1 day ago

This is serious enough that EOL should not matter. Of course, if someone is still running PHP 7 or even older, they're probably not updating anyway.

Comment by dwm 1 day ago

Details are due for disclosure at 1400hrs UTC tomorrow. That timeline may yet change.

Comment by ShowalkKama 1 day ago

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

Comment by dylanpyle 1 day ago

It sounds like the upcoming ones are 2026-109618/109619, not 9618/9619

Comment by ShowalkKama 1 day ago

I even double checked, I'm so blind.

Comment by Numerlor 1 day ago

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

Comment by potaytopotahto 1 day ago

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

Comment by qingcharles 1 day ago

Sadly this says it's probably not enough:

https://phpc.social/@Girgias/117476477429221001

Comment by bpbp-mango 1 day ago

session.use_strict_mode = 1 as well. some advice around disabling multipart uploads too.

Comment by EGreg 1 day ago

I have heard Kirill Firsov say that, but does anyone even know the vulnerabilities? Could be a meme.

Comment by potaytopotahto 1 day ago

Yes its two hanging pointers related to the upload progress handler that can be used for RCE after some heap grooming, disabling upload progress means that the function that contains the vulnerable code never runs.

Comment by kevinday 1 day ago

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

Comment by gnabgib 1 day ago

Yes it's now Wednesday, but Thursday was originally correct. Because of this HN post, it's been moved up to tomorrow.

Comment by archon810 1 day ago

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

Comment by consocio 22 hours ago

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

Comment by 1 day ago

Comment by kevbo823 1 day ago

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

Comment by MuteXR 1 day ago

...100%?

Comment by unethical_ban 1 day ago

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.

Comment by Jotalea 1 day ago

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.