If you use Nginx, you can temporarly block the subject by disallowing multipart sendings to PHP. This is quite a problem for a lot of forms, but way better that being hacked.

Here is an Nginx patch : if ($http_content_type ~* "multipart") { return 403; }

You can also turn of session progress in php.ini as mentionned but that does not seem to cover every cases : session.upload_progress.enabled = Off

▲

top_sigrid 6 minutes ago | parent | next [-]

PHP core maintainers themselves have said that only upgrading PHP will be sufficient: https://phpc.social/@Girgias/117476477429221001

▲

trog 4 hours ago | parent | prev [-]

Have you tested this against a POC to see if it actually mitigates? Seeing a lot of proposed mitigations but with very little detail about whether they worked or not.

▲

Mooty 4 hours ago | parent [-]

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.

	▲	cinpol 2 hours ago \| parent \| next [-]
		I have tried the so-called-POC of the URL you linked, it seems it is not a full POC. I have tested it against my local PHP instances; it does not work.
	▲	nikanj 4 hours ago \| parent \| prev [-]
		The php devs claim that the only workaround is going to be a new php version https://phpc.social/@Girgias/117476477429221001