Comment by lol768
1 day 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.
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
> 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.
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.