HN Explorer

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

1 points by petecooper ↗ HN
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 additional evidence to back this up beyond "source: trust me, bro", but if you're running PHP in production it would be prudent to be ready to update as a matter of 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

53 comments

[ 4.5 ms ] story [ 36.7 ms ] thread
SchizoDuckie
Well great thanks. I need details now. Where, core? Extensions? What config?

My guess is on some request filtering thing

dwm
Details are due for disclosure at 1400hrs UTC tomorrow. That timeline may yet change.
reddalo
Yes, it's on core. All versions from PHP 5 onwards. Only PHP 8 will be patched.
joshuat
So a few million WordPress sites are just going to be overnight targets.
trollbridge
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.

Yiin
surely not only 8, that would be insane
rpeden
Everything before 8.2 is past EOL.
brazzy
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.
unreal37
This was supposed to be embargoed.

So your reliable source can't keep a secret.

[deleted]
(comment deleted)
petecooper
Yeah, she lied when I asked if it was under responsible disclosure/co-ordinated disclosure -- otherwise I wouldn't have posted it!
JonKF
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.
potaytopotahto
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
lol768
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

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

Webfiletools_de
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.
lioeters
This vulnerability has already been reproduced by a third party with LLM assist. And of course they posted the details on Twitter.

So roughly 70% of all websites 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.

Earlier today I wrote (and didn't post) a comment on a thread about Drupal, saying nobody in their right mind should be writing new PHP code. I deleted it because it sounded too harsh, but unfortunately it turned out to be a correct assessment.

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

coderdiaz
The full details will be available on 8:00 AM at Mexico City
gumigumi
If this RCE is real, massive global DDoS attacks are going to take down the internet and critical infrastructure, wiping out humanity. October 21, 2026 will literally be doomsday. 地球最後の告白を R.I.P.
kevbo823
If you don't do local file include (LFI) esp. from a $_GET or $_POST then to what degree would the site be impacted?
vincent_s
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...

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

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

[deleted]
(comment deleted)
Amsozzer
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

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

[deleted]
(comment deleted)
iheartrms
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.