Apache Multiviews Arbitrary Directory Listing

This finding maps to CVE-2001-0731: Apache HTTP Server 1.3.20 and possibly some earlier 1.3.x builds, when MultiViews is used to negotiate the directory index, can return a directory listing instead of the intended index page if the attacker requests a URI with the query string M=D. Apache's own historical advisory says 1.3.20 is affected and earlier 1.3.x may also be affected; the security fix shipped in 1.3.22. In practice, the bug is only meaningful if the target path is web-reachable, MultiViews is enabled there, and the directory would otherwise have been masked by an index file.

The vendor's MEDIUM rating is technically fair in a vacuum because the attack is unauthenticated and remote. In real enterprise fleets, though, this is overstated: the blast radius is usually limited to filename and directory enumeration, not arbitrary file read or code execution; the vulnerable population is essentially legacy Apache 1.3.x; and if you actually still run 1.3.20, this specific bug is not your main problem. Treat it as a low-priority hardening / legacy eradication issue, unless the exposed directory names themselves are materially sensitive in your environment.

Why this verdict

• Start from vendor MEDIUM: unauthenticated remote web exposure deserves a baseline score because the request is cheap and public-facing.
• Downward adjustment — legacy population: real exploitation requires Apache 1.3.20 / early 1.3.x, which should be nearly extinct in managed enterprises; if it's still present, broader platform risk eclipses this specific bug.
• Downward adjustment — config friction: the path must use MultiViews for directory index negotiation, which meaningfully narrows reachable deployments.
• Downward adjustment — impact ceiling: the usual outcome is directory listing / filename disclosure, not arbitrary file read, not authentication bypass, and not RCE.
• Downward adjustment — chain dependency: meaningful business impact usually arrives only if the listing reveals another weak asset such as a backup, admin endpoint, or source archive.

Why not higher?

This is not an RCE, privilege-escalation, or arbitrary file-read primitive. The exploit chain is short but the payoff is usually just reconnaissance, and the affected software population is overwhelmingly legacy.

Why not lower?

It is still a real unauthenticated remote disclosure condition, and in badly managed docroots a directory listing can reveal backup files, admin scripts, or hidden content that materially assists later compromise. If the scanner validated the behavior on a live internet-facing path, you should not dismiss it as pure noise.

1. Disable MultiViews where unnecessary — Remove +MultiViews from the affected <Directory> or vhost scope when the application does not explicitly need content negotiation. For a LOW verdict there is no noisgate mitigation SLA; handle this as normal hardening backlog, but do it immediately if the finding is verified on an internet-facing path.
2. Turn off autoindexing — Ensure Options -Indexes is set so a fallback directory listing cannot be rendered even if negotiation or routing behaves unexpectedly. Again, LOW means backlog hygiene rather than an SLA-driven fire drill.
3. Add explicit index files — Place intentional index.html / index.php resources in directories that should never expose contents. This reduces the chance that odd path-handling behavior reveals the directory view.
4. Log and alert on ?M= probes — Add a lightweight WAF or log analytics rule for requests containing ?M=A, ?M=D, or similar directory-sort parameters against paths that should never expose listings. This helps catch opportunistic reconnaissance with almost no operational cost.
5. Retire Apache 1.3.x outright — If any host is genuinely on Apache 1.3.x, stop debating this CVE and treat the server as a legacy exception needing replacement. That is platform-risk reduction, not just fixing one medium-ish web bug.

Run this on the target Apache host as a local auditor or via your config-management agent. Invoke it as bash check_apache_multiviews_cve2001_0731.sh /etc/httpd /etc/apache2 on Linux/Unix; it needs read access to Apache binaries and configs, so root is preferred but not strictly required if the files are world-readable.

#!/usr/bin/env bash
# check_apache_multiviews_cve2001_0731.sh
# Detect likely exposure to CVE-2001-0731 / Tenable 10704.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

BIN=""
VERSION=""
CONFIG_DIRS=()
MULTIVIEWS_FOUND=0
INDEXES_DISABLED=0
LEGACY_VULN_VERSION=0

for c in "$@"; do
  CONFIG_DIRS+=("$c")
done

if [ ${#CONFIG_DIRS[@]} -eq 0 ]; then
  CONFIG_DIRS=(/etc/httpd /etc/apache2 /usr/local/apache/conf)
fi

find_bin() {
  for b in apache2ctl apachectl httpd apache2; do
    if command -v "$b" >/dev/null 2>&1; then
      echo "$b"
      return 0
    fi
  done
  return 1
}

version_lt() {
  # returns 0 if $1 < $2 using sort -V
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ] && [ "$1" != "$2" ]
}

get_version() {
  local out
  out="$($1 -v 2>/dev/null || true)"
  echo "$out" | sed -n 's/.*Apache\/\([0-9][0-9.]*\).*/\1/p' | head -n1
}

BIN="$(find_bin || true)"
if [ -z "$BIN" ]; then
  echo "UNKNOWN - Apache binary not found"
  exit 2
fi

VERSION="$(get_version "$BIN")"
if [ -z "$VERSION" ]; then
  echo "UNKNOWN - Unable to determine Apache version from $BIN"
  exit 2
fi

# Historical fixed version is 1.3.22. Modern branches are not affected by this specific CVE.
if [[ "$VERSION" =~ ^1\.3\. ]]; then
  if version_lt "$VERSION" "1.3.22" || [ "$VERSION" = "1.3.20" ]; then
    LEGACY_VULN_VERSION=1
  fi
else
  echo "PATCHED - Apache version $VERSION is not in the vulnerable 1.3.x line for CVE-2001-0731"
  exit 0
fi

# Search configs for MultiViews and Indexes controls.
for d in "${CONFIG_DIRS[@]}"; do
  [ -d "$d" ] || continue
  while IFS= read -r -d '' f; do
    if grep -Eqi '^[[:space:]]*Options[[:space:]].*\+?MultiViews' "$f" 2>/dev/null; then
      MULTIVIEWS_FOUND=1
    fi
    if grep -Eqi '^[[:space:]]*Options[[:space:]].*-Indexes' "$f" 2>/dev/null; then
      INDEXES_DISABLED=1
    fi
  done < <(find "$d" -type f \( -name '*.conf' -o -name 'httpd.conf' -o -name '.htaccess' -o -name '*.include' \) -print0 2>/dev/null)
done

if [ "$LEGACY_VULN_VERSION" -eq 1 ] && [ "$MULTIVIEWS_FOUND" -eq 1 ]; then
  if [ "$INDEXES_DISABLED" -eq 1 ]; then
    echo "UNKNOWN - Legacy Apache $VERSION with MultiViews found; -Indexes reduces exposure, but live HTTP validation is still recommended"
    exit 2
  else
    echo "VULNERABLE - Legacy Apache $VERSION with MultiViews enabled and no clear -Indexes safeguard found"
    exit 1
  fi
fi

if [ "$LEGACY_VULN_VERSION" -eq 1 ] && [ "$MULTIVIEWS_FOUND" -eq 0 ]; then
  echo "PATCHED - Apache $VERSION is legacy, but no MultiViews directive was found in the inspected configs"
  exit 0
fi

echo "UNKNOWN - Inconclusive result; inspect vhost-specific config and validate over HTTP with a test request ending in ?M=D"
exit 2

Sources

1. Tenable plugin 10704
2. Tenable CVE page for CVE-2001-0731
3. Apache HTTP Server 1.3 vulnerability history
4. NVD CVE-2001-0731
5. Bugtraq discussion confirming MultiViews as the trigger/fix path
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS project