Comment by richardbarosky

On nginx a stop-gap measure is to block all multipart posts before they reach the php code.

Add this to nginx.conf (or drop as a text file into /etc/nginx/conf.d/) :

  map $http_content_type $block_multipart { default 0; ~*^multipart/form-data 1; }

Then in every 'location /' block for every hosted server:

  location / {
    if ($block_multipart) { return 403; }
    ...
  }

Then restart nginx.

I've tested the CVEs on PHP 8.5.11 and `session.upload_progress.enabled = Off` definitely increases safety but it doesn't guarantee it. Use of plugins can open up additional exposure.

If you're behind CloudFlare apparently they'll cover you, issue is, some people don't have their web servers configured to block traffic NOT from CloudFlare, so it is kind of a bandaid that's falling off I guess.

the writeup you found has been updated to reflect the fact that the exploits provided by the author are not as severe as initially thought.

This suggests they might not have been exploits related to the CVE in question, so what you did might not be enough, be careful.

    # BEGIN php2shell-mitigation
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP:Content-Type} multipart [NC]
    RewriteRule .* - [F,L]
    </IfModule>
    <If "%{HTTP:Content-Type} =~ /multipart/i">
    Require all denied
    </If>
    # END php2shell-mitigation

and for caddy

    @multipart header_regexp Content-Type (?i)multipart
    respond @multipart 403

    @uploads_php path_regexp uploads_php ^/(?:.*/)?wp-content/uploads/.*\.php(?:/.*)?
    respond @uploads_php 404

Next will be block everything but GET, then static site copy, then administratively down