Did you successfully run a RCE test, or only a vulnerability check? So far all write-ups and PoC's i've found fail to "cash in" on the RCE part.

▲ system2 2 hours ago | parent [-]

I was able to bring it to the point of memory corruption. It is 3 am where I am now; I will continue in the morning. As a precaution, I configured .htaccess rule.

  # 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

I added a rewritecond to ignore multipart before php-fpm receives anything. I did a similar thing for nginx servers. Also in .user.ini added "session.upload_progress.enabled = Off".

These two seem to do the trick, but again I am not 1000% sure until tomorrow morning's deeper dive. My eyes are burning, and I can't sleep because of the stress this exploit.

▲ Macuyiko 2 hours ago | parent [-]

I've done the same in 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

Plus the php.ini changes, "session.upload_progress.enabled = Off" and strict mode. Let's hope it holds until then

	▲	bombcar 40 minutes ago \| parent [-]
		`@multipart header_regexp Content-Type (?i)multipart respond @multipart 403 @uploads_php path_regexp uploads_php ^/(?:./)?wp-content/uploads/.\.php(?:/.*)? respond @uploads_php 404`