So as most people have correctly identified, this defect has existed
for an incredibly long time.
But how it is triggered and avoided would help us to correctly study
unexpected behaviors.
OPTIONS * - won't trigger the defect, .htaccess should not be examined.
OPTIONS / - may trigger the defect, because the path is traversed and
one or more .htaccess files may be processed.
In all versions, <Limit > of the standard methods do not trigger the
defect. Only <Limit > of any unregistered methods in an allowed
.htaccess file will trigger the defect.
In 2.4.23 and prior including all 2.2/2.0, "HEAD" was not registered,
but would not be registered by <Limit because we first tested method
number (which returned the GET method ID.) In 2.4.25 and 2.4.26, HEAD
was registered but the Allow header constructor duplicated GET -> HEAD
and HEAD --> HEAD resulting in four methods listed, fixed already in
2.4.27.
In order to avoid the defect with trusted .htaccess authors;
In 2.2.31 and prior (all 2.0) or 2.4.23 and prior we can use an
otherwise no-op <Limit block in the global httpd.conf for non-standard
methods that are expected to occur in .htaccess - this avoids
registering them at request time.
In 2.2.32+ / 2.4.25+ we can use RegisterHttpMethod in the global
httpd.conf for non-standard methods in .htaccess - this avoids
registering them at request time.
It is not possible to avoid this defect with untrusted/malicious
.htaccess authors without disabling .htaccess files, patching or
upgrading to version 2.4.28.
Provided AllowOverride is None, and AllowOverrideList does not include
"<Limit", the server should be protected, but I haven't played with
this theory; https://httpd.apache.org/docs/2.4/mod/core.html#allowoverridelist
The httpd server cannot ever address every possible aspect of
malicious .htaccess authoring, and the project has reiterated this
message multiple times, leading to a vulnerability assessment of 'low'
severity in all cases that weren't disputed as not vulnerabilities
whatsoever;
https://www.cvedetails.com/cve/CVE-2011-3607/
https://www.cvedetails.com/cve/CVE-2011-4415/
https://www.cvedetails.com/cve/CVE-2009-1195/
https://www.cvedetails.com/cve/CVE-2004-2343/
https://www.cvedetails.com/cve/CVE-2004-0747/
for an incredibly long time.
But how it is triggered and avoided would help us to correctly study
unexpected behaviors.
OPTIONS * - won't trigger the defect, .htaccess should not be examined.
OPTIONS / - may trigger the defect, because the path is traversed and
one or more .htaccess files may be processed.
In all versions, <Limit > of the standard methods do not trigger the
defect. Only <Limit > of any unregistered methods in an allowed
.htaccess file will trigger the defect.
In 2.4.23 and prior including all 2.2/2.0, "HEAD" was not registered,
but would not be registered by <Limit because we first tested method
number (which returned the GET method ID.) In 2.4.25 and 2.4.26, HEAD
was registered but the Allow header constructor duplicated GET -> HEAD
and HEAD --> HEAD resulting in four methods listed, fixed already in
2.4.27.
In order to avoid the defect with trusted .htaccess authors;
In 2.2.31 and prior (all 2.0) or 2.4.23 and prior we can use an
otherwise no-op <Limit block in the global httpd.conf for non-standard
methods that are expected to occur in .htaccess - this avoids
registering them at request time.
In 2.2.32+ / 2.4.25+ we can use RegisterHttpMethod in the global
httpd.conf for non-standard methods in .htaccess - this avoids
registering them at request time.
It is not possible to avoid this defect with untrusted/malicious
.htaccess authors without disabling .htaccess files, patching or
upgrading to version 2.4.28.
Provided AllowOverride is None, and AllowOverrideList does not include
"<Limit", the server should be protected, but I haven't played with
this theory; https://httpd.apache.org/docs/2.4/mod/core.html#allowoverridelist
The httpd server cannot ever address every possible aspect of
malicious .htaccess authoring, and the project has reiterated this
message multiple times, leading to a vulnerability assessment of 'low'
severity in all cases that weren't disputed as not vulnerabilities
whatsoever;
https://www.cvedetails.com/cve/CVE-2011-3607/
https://www.cvedetails.com/cve/CVE-2011-4415/
https://www.cvedetails.com/cve/CVE-2009-1195/
https://www.cvedetails.com/cve/CVE-2004-2343/
https://www.cvedetails.com/cve/CVE-2004-0747/