HTTP TRACE / TRACK Methods Allowed

Tenable plugin 11213 is not a software-version bug so much as a web-tier configuration finding: the server answers HTTP TRACE and/or IIS TRACK requests. Any stack that reflects the request body or headers back to the client can trigger it if the method is enabled, which means the affected range is effectively any web server, proxy, or application tier that still permits these methods rather than a neat product/version list.

The vendor's MEDIUM label is too generous for enterprise patch triage. TRACE by itself does not execute code, bypass auth, or dump data; it is mostly an attack amplifier for a second flaw such as same-origin XSS or a proxy desync/smuggling condition. Modern browsers also treat TRACE as a forbidden method, which kills the classic cross-site tracing path in many real deployments, so this belongs in backlog hardening, not in front of exploitable edge RCEs.

Why this verdict

• Downgrade for attacker position: unauthenticated remote reachability is easy, but the next prerequisite usually implies another vulnerability already exists. Requiring XSS or desync means this is not a true one-step compromise.
• Downgrade for exposure reality: the classic XST path depends on browser behavior that modern platforms largely block because TRACE is a forbidden method. That sharply narrows the reachable population compared with what a raw web-scan count suggests.
• Keep it above IGNORE: TRACE still leaks request-path behavior to non-browser clients and can materially help niche proxy-smuggling chains. On internet-facing apps with brittle proxies, it remains worth cleaning up as hardening debt.

Why not higher?

There is no direct code execution, auth bypass, or data dump here in isolation. A high-severity score would overstate the real enterprise risk because the attack chain usually depends on a prior app-layer flaw or advanced proxy behavior that should be scored separately.

Why not lower?

It is not pure noise: a server that truly reflects TRACE is exposing unnecessary attack surface and can leak request metadata. In edge cases involving legacy browsers, internal tooling, or request-desync conditions, the method meaningfully amplifies another weakness, so LOW is the floor I would use rather than IGNORE.

1. Disable TRACE and TRACK at the edge and origin — Block the verbs on the load balancer, reverse proxy, WAF, and origin server so a single drifted tier does not re-expose them. Because this is a LOW finding, there is no formal SLA; handle it as backlog hardening in the next normal web-tier change window.
2. Validate with live requests, not just scanner output — Retest every exposed hostname with an actual TRACE request and confirm you receive 403, 405, or 501 rather than a reflected body. Do this before closing tickets because false positives from OPTIONS/Allow behavior are common.
3. Prioritize paired app findings on the same host — If the same application also has confirmed XSS, request smuggling, or cache poisoning exposure, promote the combined case locally even though this plugin alone stays LOW. There is no separate mitigation SLA for LOW, but the chained vulnerability should inherit the higher-risk item's deadline.
4. Alert on rare HTTP verbs — Create detections for TRACE, TRACK, CONNECT, and other uncommon methods at the reverse proxy or WAF. This is cheap visibility and helps catch both probing and accidental reintroduction during config drift.

Run this from an auditor workstation or CI runner that can reach the target URL over the same path your users hit. Invoke it as bash trace_check.sh https://app.example.com with no special privileges; it uses curl to test live TRACE and TRACK behavior and prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# trace_check.sh
# Verify whether a web endpoint allows HTTP TRACE or TRACK.
# Usage: bash trace_check.sh https://app.example.com
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / usage / network failure

set -u

URL="${1:-}"
if [[ -z "$URL" ]]; then
  echo "UNKNOWN - usage: bash trace_check.sh https://host.example" >&2
  exit 2
fi

if ! command -v curl >/dev/null 2>&1; then
  echo "UNKNOWN - curl not found" >&2
  exit 2
fi

MARKER="noisgate-trace-check-$(date +%s)"
TMPDIR="$(mktemp -d 2>/dev/null || mktemp -d -t noisgate-trace)"
trap 'rm -rf "$TMPDIR"' EXIT

check_method() {
  local method="$1"
  local hdr="$TMPDIR/${method}.headers"
  local body="$TMPDIR/${method}.body"

  curl -ksS -o "$body" -D "$hdr" \
    -X "$method" \
    -H "User-Agent: noisgate-trace-check/1.0" \
    -H "X-Noisgate-Test: $MARKER" \
    --max-time 15 \
    "$URL" >/dev/null 2>&1
  local rc=$?
  if [[ $rc -ne 0 ]]; then
    return 20
  fi

  local status
  status="$(awk 'toupper($1) ~ /^HTTP\// {code=$2} END{print code}' "$hdr")"
  [[ -z "$status" ]] && return 21

  # Strong vulnerable signal: success plus reflected marker or request line.
  if [[ "$status" =~ ^2[0-9][0-9]$ ]] && \
     (grep -qi "$MARKER" "$body" || grep -qi "^${method}[[:space:]]" "$body"); then
    return 10
  fi

  # Some stacks return 200 with empty/non-reflective body; still suspicious.
  if [[ "$status" =~ ^2[0-9][0-9]$ ]]; then
    return 11
  fi

  # Typical blocked responses.
  if [[ "$status" == "403" || "$status" == "405" || "$status" == "501" ]]; then
    return 0
  fi

  # Anything else is ambiguous and needs human review.
  return 21
}

vuln=0
unknown=0
notes=()
for method in TRACE TRACK; do
  check_method "$method"
  rc=$?
  case "$rc" in
    10)
      vuln=1
      notes+=("$method reflected request data")
      ;;
    11)
      vuln=1
      notes+=("$method returned 2xx")
      ;;
    0)
      notes+=("$method blocked")
      ;;
    20|21)
      unknown=1
      notes+=("$method ambiguous")
      ;;
  esac
done

if [[ $vuln -eq 1 ]]; then
  echo "VULNERABLE - ${notes[*]}"
  exit 1
fi

if [[ $unknown -eq 1 ]]; then
  echo "UNKNOWN - ${notes[*]}"
  exit 2
fi

echo "PATCHED - ${notes[*]}"
exit 0

Sources

1. Tenable Nessus Plugin 11213
2. Tenable WAS Plugin 98048
3. OWASP Cross Site Tracing
4. PortSwigger TRACE desync research
5. Apache TraceEnable directive
6. Microsoft IIS Request Filtering
7. MDN HTTP TRACE method reference
8. CISA Known Exploited Vulnerabilities Catalog