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/
