> Over the past two months, we led a coalition of maintainers, researchers, and security providers to address critical vulnerabilities in PHP, an open-source programming language used to run websites and web applications.
And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
It can mean either, it's a consequence of how github optimized their backend storage so a 100 forks of a repo initially take up the same space as 0 forks
So far Ubuntu LTS isn’t picking up the new packages for me via apt update, and Laravel Forge appears completely unresponsive as a result of being flooded by people trying to update their servers.
Since I have to go through a bunch of php repos today at work I ended up releasing a CLI tool that automates that process by listing out the steps you need to take to stay away from the vulnerability.
Here's the link incase it helps anyone https://github.com/Amsozzer1/php2shell-repo-audit
i just took down all my PHP sites for the last few hours. they’re proxied behind Cloudflare so i know there were mitigations, but infrastructure can’t be breached if it isn’t running!
>Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
Many vendors do it, but on a set schedule "patch Tuesday" and some will release vague "mitigation steps" but honestly those usually come with the patch.
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests." -Rasmus Lerdorf
What I did on our WordPress boxes while waiting for distro packages (CVE-2026-109618 / CVE-2026-109619)
1. session.upload_progress.enabled = Off, in php.ini and as php_admin_flag in every FPM pool, so per-directory config can't turn it back on. It's one of the two confirmed consumers in GHSA-6wmf, and the validated FPM path depends on it. Almost nobody uses it, and the advisory suggests leaving it off even after patching.
2. Refuse multipart request bodies at the web server, before PHP parses them. All of the GHSA-w8hw out-of-memory strategies go through multipart parsing. On Apache it's a rewrite rule matching a Content-Type of multipart/form-data that returns 403. On Caddy it's a header matcher that responds 403. The cost: every browser upload breaks (media library, plugin zips, importers). Check your public forms first.
3. Check your SAPI. Both bugs have confirmed RCE against mod_php. FPM is narrower: the validated path needs upload_progress, and the early INI consumer only applies if your front end sends PHP_VALUE/PHP_ADMIN_VALUE. To check, grep your Apache, nginx and Caddy configs for it, and run apache2ctl -M | grep php.
4. pm.max_requests = 1 in the pools. A worker serves one request and exits, which breaks the stale-state chain: the "producer" and "consumer" requests must land on the same worker. It costs a fork per request.
5. Lower max_input_nesting_level and post_max_size, per the advisory.
6. Housekeeping that should already be done: no .php served from uploads directories, and remove any stray phpinfo.php. Scanners request it constantly, and it tells an attacker your exact build.
I wrote it so I could deploy it myself on our old nginx + php-fpm setups, thought I would share. It should work with all top servers (nginx, apache, caddy etc)
You know, normally I'd be okay with these comments, but in this case you're actively hurting a lot of people by this bullshit. Many people need something other than patching PHP.
It's free and MIT licensed, open source and it is currently the only alternative to patching your PHP. The "profit" is for people who don't get PWNED today!!!
Many people can't patch your PHP. If you can't be bothered to even look at the repo, you may want to sit this one out.
https://www.php2shell.com/
https://www.wiz.io/blog/php2shell-php-rce
https://calif.io/php2shell/
https://openai.com/index/coordinated-disclosure-of-critical-... (not yet live)
https://thephp.foundation/blog/2026/10/21/todays-php-securit... (not yet live)
And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
August 24, 2026: Wiz Research reports the vulnerabilities to the PHP security team.
September 21, 2026: PHP acknowledges the reports and begins developing a coordinated fix.
https://github.com/php/php-src/security/advisories/GHSA-w8hw...
https://github.com/php/php-src/security/advisories/GHSA-6wmf...
Well off to a good start here.
> This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Glorious. Today of all days it would genuinely give me pause for caution.
edit: yeah, really not feeling that: https://github.com/php/php-src/compare/php-8.2.34..php-8.2.3...
Hopefully just a mistake? But looks like a botched release at the least
Is it perhaps a bit misleading, and only means that there's no branch containing that commit?
https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
awake2death or something
https://www.php.net/archive/2026.php#2026-10-20-1
Now are available in the php-src github
https://github.com/php/php-src/tags
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests." -Rasmus Lerdorf
Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?
What everyone is looking for.
I assume it just got pushed?
1. session.upload_progress.enabled = Off, in php.ini and as php_admin_flag in every FPM pool, so per-directory config can't turn it back on. It's one of the two confirmed consumers in GHSA-6wmf, and the validated FPM path depends on it. Almost nobody uses it, and the advisory suggests leaving it off even after patching.
2. Refuse multipart request bodies at the web server, before PHP parses them. All of the GHSA-w8hw out-of-memory strategies go through multipart parsing. On Apache it's a rewrite rule matching a Content-Type of multipart/form-data that returns 403. On Caddy it's a header matcher that responds 403. The cost: every browser upload breaks (media library, plugin zips, importers). Check your public forms first.
3. Check your SAPI. Both bugs have confirmed RCE against mod_php. FPM is narrower: the validated path needs upload_progress, and the early INI consumer only applies if your front end sends PHP_VALUE/PHP_ADMIN_VALUE. To check, grep your Apache, nginx and Caddy configs for it, and run apache2ctl -M | grep php.
4. pm.max_requests = 1 in the pools. A worker serves one request and exits, which breaks the stale-state chain: the "producer" and "consumer" requests must land on the same worker. It costs a fork per request.
5. Lower max_input_nesting_level and post_max_size, per the advisory.
6. Housekeeping that should already be done: no .php served from uploads directories, and remove any stray phpinfo.php. Scanners request it constantly, and it tells an attacker your exact build.
https://news.ycombinator.com/item?id=50180987
https://github.com/Qbix/proxy
I wrote it so I could deploy it myself on our old nginx + php-fpm setups, thought I would share. It should work with all top servers (nginx, apache, caddy etc)
It's free and MIT licensed, open source and it is currently the only alternative to patching your PHP. The "profit" is for people who don't get PWNED today!!!
Many people can't patch your PHP. If you can't be bothered to even look at the repo, you may want to sit this one out.
https://github.com/Qbix/proxy