I legitimately wish that there were procedures and infrastructures in place for the core teams of things like Drupal to exploit such RCE vulnerabilities themselves (finding installations by the standard means that the bad guys also use) with a payload that applies a suitable patch to fix the vulnerability (definitely in a very-cautious way, e.g. only if the entire file to be patched matches an expected checksum), and then email the site owner if possible to declare what has been done.
That auto-updating is even possible from the web server process is itself a very severe security vulnerability. I haven’t used Drupal since the 6 days, but back then and earlier the recommended deployment policy had the files directory (for uploads) as the only directory that the server process could write to—the code was definitely to be read-only. I think this was also checked by the system so that it would produce a warning were it not so.
In such a world, RCE isn’t quite so scary. Not quite. (Yeah, PHP code in the database and all that.)
In practice, shared hosting doesn’t tend to take kindly to genuine read-only-ness, and so the grand ideal of not being able to inject persistent code doesn’t work quite so well.
I really don’t like the way Wordpress does it, but the way Drupal does it also isn’t great. I don’t like the security models of any of these PHP things.
I can easily see why such a thing is unlikely to happen; yet it is demonstrably pro bono—the bad guys will exploit it, and you are simply protecting the innocent.
