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
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.
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
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.
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.
https://x.com/k_firsov/status/2112641845926989944
(video). Yikes
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...
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...
Our current plan is to refactor this into Rust using a coding agent. It looks feasible to get this done today.
So your reliable source can't keep a secret.
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!
> 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...
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...
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
Am I missing something?
https://nvd.nist.gov/vuln/detail/cve-2026-9618 https://nvd.nist.gov/vuln/detail/cve-2026-9619
My guess is on some request filtering thing
Although I guess that's not a dramatic change in the status quo.
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.
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.
>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.