You misread. He is saying that the multipart UAF vulnerability part of the overall exploit can't be fixed by session.upload_progress.enabled = off or any other ini option for that matter.

the future is now, eh.

Yeah, the circuit breaker is the best firewall!

This one claims to actually be an exploit. The other was an announcement from PHP without details.

How is this a better source, the current post is a PoC? This is just a warning...

You're not even reading the things you're saying are worse, and reccomending things that arent what you say they are (because you didnt read those either)

After digging a little in the PoC code (here https://jackalsyn.com/posts/php-up-2026.html) I'm quite confident it's not a completely working one.

It assumes PHP frees the upload progress data when it reloads the session. But PHP 8.4 (the one we use is 8.4.24, i don't know for other versions) calls Z_TRY_ADDREF(progress->data) to keep that data alive. The fake function call also seems to contain invalid fields.

This makes me question this particular PoC, not the official PHP security warning. I have not reproduced the exploit, so this is a concern based on reading the code, not proof that the real vulnerabilities cannot be exploited.

But anyway the CVE still exists, and the exploitation is tied to multipart, disabling it seems the best thing you can do now without shutting everything down.

Block it at your web server before it reaches PHP. Ctrl+F "nginx" or ".htaccess" in this thread for configs.

https://x.com/dok2001/status/2112702593705312467

"We got you covered" - Dane Knecht (Cloudflare CTO)

CF in front can mess about with L7?

I think putting my PHP site behind Cloudflare would be the least I would do if I wanted to keep it online before PHP can be patched. The other alternative is trying to block multi-part uploads before they reach PHP.

This appears to have global effect if placed in a <Location> block in the root apache2.conf:

  # PHP 20261020 Remediation (Global)
  <Location />
    <If "req('Content-Type') =~ /multipart/i">
        Require all denied
    </If>
  </Location>

On Reddit they stated that Ondrej is aware of the issue

Why would they hand code a website for an exploit that they probably found 15 minutes before and will be fixed in a few hours? The copy should have been better though.

It may have made sense when finding exploits required some skill and time so 24 hours would be safe enough but now when anyone can just point an LLM at it...

It's things like "under the attacker's feet" which completely throw me off. While trying to parse the text, my brain tries to imagine a surprised hacker.

It reads like the average PR summary I had to review every day. ‘Had’, because I stopped doing that after being blessed by LGTM https://m.youtube.com/watch?v=3TNpOD6bov8&pp=ygUEbGd0bQ%3D%3...

It really reads like it was passed 3 times through Claude.

I just wrote almost the same thing (I start to write my comments before I read what others say, so that it is not influenced directly what I write). I am glad to come to the same conclusion - this website is both visually interesting as well as very annoying.

The font is terrible on mobile, cannot tell then difference between a comma and a fullstop at all

yeah agreed.

Ctrl-Alt-R for reader view in Firefox, not that it makes the whole thing much more interesting to look at - we'll forget about it all soon enough anyway. Don't forget to tweak the default settings for reader view for a better experience.

Maybe that’s because you’ve only worked with WordPress with tons of unpatched plugins.

Every programming language has security vulnerabilities. PHP doesn’t have any more than others.