If a malicious plugin or bad script exists on disk and is executing, it’s already too late. Malicious PHP running under the guise of an authorized plugin does not necessarily gain more privileges by calling other malicious PHP, so preventing this does not provide any sort of guarantee of damage mitigation.
So on a conceptual level I consider this strategy to be fairly bunk. On top of that, the actual rewrite does not serve the purpose you describe, anyway. If the idea is to limit PHP from executing outside of wp-admin, that’s hopelessly failed. Your rewrite does not prevent someone from uploading to /foo/bar/index.php and calling /foo/bar to run the index file. It does not, on its own, prevent someone from uploading to wp-admin in the first place either.
Additionally, the most overwhelmingly common form of the rewrite I’ve seen in the past has been the following v1 Caddyfile syntax:
rewrite {
if path not_match ^\/wp-admin
to {path} {path}/ /index.php?{query}
}
This is even further than the intent that you suggest. And why is this a regular expression? Further indication of cargo cult behaviour, in my opinion; someone sitting down and thinking through what they’re trying to achieve here, with a real understanding of the functionality available, would be able to do a much better job overall - in particular, a substring match would be optimal here.
In short, it seems very likely to me that many people have taken this solution and worked their way backwards to the problem, convincing themselves it is common and necessary, instead of going about things from the start with the identification of a problem and then incorporating a solution.
This particular problem - the concept of trying to limit damage from malicious PHP - starts and stops at the upload process. WordPress already denies uploading arbitrary PHP through its own uploader. Don’t install untrustworthy plugins, or you’re already pwned the moment they run - and they can hook arbitrary code into any page request.
If you truly want to enact this as a security measure, there’s a slightly more focused bit of config that also floats its way around:
rewrite {
r /uploads\/(.*)\.php
to /
}
Both this and the above are even on our community-maintained v1 configuration examples list! But this one, at least, is much clearer about its purpose. It’s still pretty suboptimal, though. I’d rather do something like this:
rewrite /wp-content/uploads {
ext .php
to /
}
Or in v2 maybe something like this:
route /wp-content/uploads {
rewrite *.php /
}
But again I strictly would not put these in my WordPress Caddyfiles because I know that in the scenario where they may be useful my site is already compromised and they will… not be useful.
Edit: And why only Caddy? Not necessary for functionality; not proven to be more secure - in concept OR in practice; not commonly found in comparable config for any other web server. It’s just… been hanging around since the early Caddy v1 days.
