← Back to context

Comment by fredsted

15 hours ago

There's an exploit freely available already, by the way. You can't contain things like this.

If not, you or our agent could build an exploit from the information that's already out.

7 comments

fredsted

Reply
cinpol  15 hours ago

Are you 100% sure? I have tested 2 PoC's against my dev environment, no luck so far. So I am not sure if there is working exploit already.

TekMol  15 hours ago

I have not seen confirmation that the exploit is for the bug that is going to be patched.

It seems the published exploit can be easily prevented by filtering out multipart post requests. So people actively watching the situation can already prevent that issue by filtering those.

system2  15 hours ago

I was able to cook up something in less than 10 minutes and tested many sites. There is a page with enough explanations to do it.

  • rtuin  15 hours ago

    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  15 hours ago

      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.

      2 replies →