The following is tested on: Apache/2.4.29 (Ubuntu) Apache/2.4.25 (Debian) Apache/2.4.18 (Ubuntu) Fresh install's with multiviews enabled like this: <Directory /var/www/html> Options Multiviews </Directory> Create a file "/var/www/html/dir/test.png" Try to access the following URL http://192.168.1.32/dir/test/fake.png You get the following 404 error: Not Found The requested URL /dir/test.png/fake.png was not found on this server. Apache/2.4.29 (Ubuntu) Server at 192.168.1.32 Port 80 This also works if you use a different extension like this: Try to access the following URL http://192.168.1.32/dir/test/fake.html You get the following 404 error: Not Found The requested URL /dir/test.png/fake.html was not found on this server. Apache/2.4.29 (Ubuntu) Server at 192.168.1.32 Port 80 Is this working as intended? or is this a bug/information disclosure? Richard
Side note: requests to https://192.168.1.30/dir/test/fake.html Bypass the .htaccess "ErrorDocument 404" and have the wrong port number? Not Found The requested URL /dir/test/fake.html was not found on this server. Apache Server at 192.168.1.30 Port 80
And on the live server (HTTPS): Forbidden You don't have permission to access /.htaccess/testing on this server. Apache Server at www.xxx.com Port 80
The above totally bypassing the custom 404 setups. And confirming that the file exists.
Please report security issues directly and individually to security@apache.org in the future.
This behavior looks entirely correct. If you do not want files of another extension to be shown, turn off multiviews. Httpd will always convey these names to the client, to help the cache disambiguate between different representations. It is certainly confusing, but that isn't due to multiviews. You have tripped over AcceptPathInfo, a different feature which exposes paths beneath any type of resource. http://svn.apache.org/viewvc/ is but one example; those svn files are all served by the viewvc script. If you believe there is still an issue after disabling these features, you can reach out to security@httpd.apache.org, but I see no reason not to discuss the confusion here.