React on Rails HN RSC Demo

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

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

lol768 6h 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.

Webfiletools_de 6h 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.

vincent_s 2h 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...

phab 8h ago

Tweet allegedly showing exploit at work:

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

(video). Yikes

1over137 5h ago

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

koolala 5h ago

This video is iconic

potaytopotahto 7h 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

4lun 3h 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...

rbarden 7h ago

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

lioeters 7h 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!

unreal37 10h ago

This was supposed to be embargoed.

So your reliable source can't keep a secret.

petecooper 2h ago

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

reddalo 11h 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...

HotGarbage 11h ago

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

ShowalkKama 11h 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

dylanpyle 11h ago

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

ShowalkKama 11h ago

I even double checked, I'm so blind.

SchizoDuckie 14h ago

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

My guess is on some request filtering thing

reddalo 11h ago

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

joshuat 9h 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.

Yiin 7h ago

surely not only 8, that would be insane

rpeden 7h ago

Everything before 8.2 is past EOL.

brazzy 1h 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.

dwm 11h ago

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

archon810 8h ago

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

kevinday 9h 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

gnabgib 7h ago

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

kevbo823 4h 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?

MuteXR 1h ago

...100%?

coderdiaz 6h ago

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

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