[1] https://www.vdoo.com/blog/vdoo-discovers-significant-vulnera...
1. It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists.
2. This rerouting was supposed to happen only for admins, but the authorization failed, due to a different bug, CVE-2018-10661.
3. The attack then depended on a bug in dbus, CVE-2018-10662
4. Finally it depended on a third flaw, CVE-2018-10660, having to do with shell-script injection.
So I don't think any of this should scare away a person from using MultiViews for .php scripts, which makes setting up clean, maintainable routes easier than any other technique I've seen.
The request to a.srv (in their example) was only authorized because a request to /index.html/a.srv looked like a request to /index.html to the auth module because the auth module did not check PATH_INFO. The request was then passed to the ssid daemon (not shell script) over a UNIX socket.
a.srv ended up in PATH_INFO because index.html existed.
The developer(s) of the auth module only checked SCRIPT_NAME and index.html was valid for unauthed users.
They could have done further configuration to let HTML files take PATH_INFO, but this Rube Goldberg machine of multiple mistakes bears no more connection to MultiViews than mod_rewrite. In fact, I see no mention in the article of MultiViews or its module, mod_negotiation. So how do we know they were using MultiViews and not mod_rewrite, which people use much more often for this amount of indirection?
Either way, this exploit is impossible in the original suggestion, to just use MultiViews with PHP files to remove the ".php"