r/netsec • u/Wploplin • 1d ago
PHP rce CVE-2026-109618
https://watchtowr.com/intelligence/php-cve-2026-109618-faq/5
u/_vavkamil_ 9h ago edited 6h ago
What a shit show :)
- 2019 - Related PHP memory-handling bug reported
- 2020 - Bug fixed and closed
- 2024 - PHP rediscovers a related bug, considers RCE theoretical, won't fix
2026
- July 30 - Calif starts auditing PHP through OpenAI's Patch the Planet
- August 1 - Calif discovers RCE paths using OpenAI's GPT-5.6 Sol
- August 11 - Calif reports the RCE to PHP
- August 11 - OpenAI's Codex Security independently reports the same root cause
- August 14 - Calif provides a working RCE PoC
- August 19 - Wiz independently discovers related PHP vulnerabilities using Gemini
- August 24 - Wiz reports its findings to PHP
Patch release scheduled for October 22
- October 20, 15:20 UTC - Hacker News user leaks embargoed CVE details
- October 20, 18:26 UTC - watchTowr publicly confirms the embargo
- October 20, 19:33 UTC - PHP announces an emergency security release forward by one day
- October 20, 20:00 UTC - Calif mistakenly publishes a PHP2Shell PoC video on X
- October 21, 03:02 UTC - Cloudflare activates PHP2Shell WAF protection by default
- October 21, 07:41 UTC - Chainguard prematurely publishes container images containing the security fix
- October 21, 07:43 UTC - Cloudflare publicly reports early exploitation attempts
- October 21, 13:32 UTC - Wiz announces its PHP2Shell research on X and takes the spotlight
- October 21, 13:34 UTC - PHP publishes GitHub security advisories
- October 21, 13:36 UTC - PHP publishes its official security announcement
- October 21, 14:00 UTC - Scheduled PHP security release
- October 21, 14:06 UTC - PHP GitHub releases published for all four patched versions
EDIT:
- October 21, 14:19 UTC - PHP Docker pipeline triggered
- October 21, 14:31 UTC - PHP Docker pipeline finished
- October 21, 14:52 UTC - GitHub goes down
- October 21, 15:59 UTC - Patched images were being built
- October 21, 16:30 UTC - First patched Docker images reportedly become available
- October 21, 16:57 UTC - GitHub starting to recover
- October 21, 16:57 UTC - GitHub mostly recovered
- October 21, 17:55 UTC - All of Docker Hub's patched tags available
What a day ...
EDIT2: Moved to my blog, might revisit tomorrow https://vavkamil.cz/blog/2026-10-21-timeline-of-php2shell/
4
u/Syntax418 9h ago
You’re missing the following crash out because of the slow pipeline that publishes official php docker images
7
u/vincent_sch 15h ago
Once the fixed build is installed, check that PHP-FPM restarted after the update. With mod_php, Apache needs the restart. You should also restart PHP queue workers and schedulers still using the old build.
17
u/sylvester_0 1d ago
Lol what a useless page at this point "An RCE is coming in a couple of days" basically.
14
3
u/breakingcups 17h ago
Useless to you,, maybe. Not to organizations big and small who can now make sure everyone is at the helm to update as soon as the patches come out.
8
u/blobCabbage 1d ago
Still useful to know that a fix will be published on Wednesday. Especially nowadays, when AI-aided researchers will reverse the fix and publish a PoC within hours.
-1
u/ReferenceVisual663 17h ago
Hours? Most of the internet will have been probed by bots attempting the exploit by then.
4
-7
u/dack42 22h ago
Full PoC is already public, but I won't link it here.
5
7
u/LevalloisTechnique 17h ago
3
u/math1985 14h ago
My first impression is that this is AI slop. It even says at the bottom (under Validation Receipts) it's not a vulnerability / not RCE.
-1
u/LevalloisTechnique 14h ago
Oh, I have little doubts that the author is one of these depressingly common morons that uses LLMs, and I suspect they were used for the code itself as well; the fact remains, the provided exploit works (assuming you have the correct offset).
Weirdly, the author just took the exploit down, and then reupped another version.
3
u/math1985 14h ago
Did you test the exploit yourself? I didn’t test it. I suspect it doesn’t work, given the fact that it says itself in the documentation that it doesn’t work, but if you can get it to work I’m convinced.
3
u/LevalloisTechnique 13h ago
I did and it did make a FPM worker crash; but no RCE. I assumed this was because I had a slightly different version of PHP but the fact the author rollbacked "their own" exploit (using quotes here as I'm starting to believe it's all LLM generated, doubly so given some claude-related paths they forgot to remove in the new version) suggests you may be right.
2
u/dack42 12h ago
Yes, I assume it's only working with the specific environment they used. That is pretty typical, and it could be adapted for other environments. LLM generated is expected. Obviously anyone coming out with something quickly is going to be using LLMs. What's important for defenders is just the fact that an exploit is public.
1
u/math1985 8h ago
Just for the avoidance of doubt: did you actually verify that the FPM worker crash on the server? Or did you just assume it crashed based on the error that the script gave?
-16
-3
u/Old_Adeptness5169 16h ago edited 10h ago
Update after PHP's advisories: the session upload-progress handler is one of the confirmed routes, but not the only one. The advisories also describe out-of-memory tricks in the multipart parser, plus some routes no extension can close. v3 carries the fixed multipart parser with a memory guard and keeps the upload-progress handler out, which on typical PHP-FPM hosting closes the routes that work before any application code runs. Still a stopgap: update to 8.5.12/8.4.27/8.3.36/8.2.35 (or your distro's backport) as soon as you can. Thanks to everyone who pushed back today.
Disclosure: Hosted Power (hosting company). Looking for review of a stopgap, not a replacement for the patch.
ext/session installs php_session_rfc1867_callback into the global php_rfc1867_callback at MINIT; main/rfc1867.c NULL-checks that pointer before each of its call sites. An extension with ZEND_MOD_OPTIONAL("session") that NULLs the pointer in its own MINIT should make the handler, where the reproductions place both UAFs, unreachable for the process lifetime, without touching multipart parsing itself. Unlike session.upload_progress.enabled=Off (PHP_INI_PERDIR, so .user.ini/.htaccess can re-enable it), nothing at the site level can undo it.
Open questions we'd value eyes on: is there any route into the upload-progress state that doesn't go through this callback, and any SAPI where module init order would break the assumption?
https://github.com/HOSTED-POWER/php_uploadprogress_guard
It only helps as far as the bugs live in that handler; we'll compare against the advisory at 14:00 UTC.
29
u/orangesnz 1d ago
looks like it's been reverse engineered already https://x.com/J4ck3LSyN/status/2112703096443097263