Hashicorp Consul Web UI and API access

Tenable plugin 111351 is not a software flaw with a fixed version; it is a configuration exposure finding for HashiCorp Consul. The risky pattern is: the Consul HTTP/UI listener is bound off-loopback via client_addr, the optional Web UI is enabled, and unauthenticated requests inherit permissions from either acl.tokens.default or the built-in anonymous token. HashiCorp documents that client_addr defaults to 127.0.0.1, the UI is not enabled by default for non-dev agents, and ACLs are what secure the API/UI/CLI.

Tenable's HIGH / 8.8 overstates reality for most enterprises because the attack path depends on multiple admin choices that are all non-default and deployment-specific: reachable network exposure, permissive token behavior, and in the worst case additional dangerous settings like enable_script_checks. If those prerequisites are all true on an internet-facing node, the risk climbs fast; but as a fleet-wide patching priority this behaves like a context-heavy hardening issue, not a universally exploitable RCE.

Why this verdict

• Downward pressure: requires reachable Consul API/UI. If the listener is left at the documented default 127.0.0.1, the attack chain dies immediately.
• Downward pressure: requires permissive effective token behavior. Unauthenticated requests only matter if acl.tokens.default or anonymous has useful rights; a deny-by-default anonymous token turns this into noise.
• Downward pressure: host takeover is not intrinsic. Tenable hints at service registration and remote access, but that escalated outcome generally needs extra risky features like enable_script_checks or remote exec-related capabilities.
• Upward pressure: if exposed, the intel value is real. Even read-only catalog/KV visibility can materially aid lateral movement by mapping services, nodes, health, and trust edges.
• Upward pressure: Consul is high-value control-plane tech. Bad permissions here can let an attacker manipulate discovery and traffic decisions, so you should not ignore confirmed unsafe instances.

Why not higher?

This is not a universal unauthenticated RCE and not even a universal unauthorized read. It depends on a stack of non-default conditions: off-loopback binding, network path, permissive token semantics, and possibly additional dangerous features for execution impact.

Why not lower?

A confirmed exposed Consul API with inherited read or write permissions is not harmless. Because Consul is a service-discovery/control-plane component, even partial anonymous access can expose topology or let an attacker poison service state in ways that matter operationally.

1. Bind Consul back to loopback where possible — Set client_addr to loopback or remove the override so the documented default applies. This is the cleanest risk kill-switch and, for a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but confirmed externally reachable cases should be corrected much sooner as operational hardening.
2. Strip permissions from unauthenticated paths — Ensure unauthenticated requests fall to a tightly restricted anonymous token and avoid assigning broad rights to acl.tokens.default. This limits exposure even when the API must remain reachable for operational reasons; complete within the same remediation cycle.
3. Require TLS and trusted network paths — Use TLS for API access and restrict ingress with host firewall rules, security groups, or cluster-only service exposure. This reduces opportunistic discovery and credential leakage while you normalize Consul configs across the fleet.
4. Keep script-based execution paths off — Verify enable_script_checks is disabled unless there is a documented exception, prefer enable_local_script_checks when needed, and keep remote exec disabled. This prevents the finding from turning into a much nastier execution path.
5. Alert on anonymous API use — Log and alert on requests lacking X-Consul-Token or bearer auth, plus PUT operations to service/check registration endpoints. This gives you immediate detection value even if the configuration cannot be changed in one maintenance window.

Run this on the target Consul host as root or with enough privileges to read Consul config files and inspect listening sockets. Example: sudo bash ./check_consul_exposure.sh /etc/consul.d; it checks whether Consul is bound off-loopback and whether unauthenticated reads succeed against the local API.

#!/usr/bin/env bash
# check_consul_exposure.sh
# Exit codes:
#   0 = PATCHED (not vulnerable based on current checks)
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u
CONFIG_DIR="${1:-/etc/consul.d}"
API_PORT="8500"
HTTPS_PORT="8501"
status="UNKNOWN"
reason=""

have_cmd() { command -v "$1" >/dev/null 2>&1; }

json_get_http_code() {
  local url="$1"
  curl -ksS -o /tmp/consul_check_body.$$ -w "%{http_code}" "$url" 2>/dev/null || echo "000"
}

cleanup() {
  rm -f /tmp/consul_check_body.$$ 2>/dev/null || true
}
trap cleanup EXIT

if ! have_cmd curl; then
  echo "UNKNOWN - curl not found"
  exit 2
fi

# 1) Check listening addresses for Consul on 8500/8501.
listen_non_loopback=0
if have_cmd ss; then
  if ss -lntp 2>/dev/null | grep -E ':(8500|8501)\b' | grep -vqE '127\.0\.0\.1:|\[::1\]:'; then
    listen_non_loopback=1
  fi
elif have_cmd netstat; then
  if netstat -lntp 2>/dev/null | grep -E ':(8500|8501)\b' | grep -vqE '127\.0\.0\.1:|::1:'; then
    listen_non_loopback=1
  fi
else
  echo "UNKNOWN - neither ss nor netstat found"
  exit 2
fi

# 2) Query unauthenticated local endpoints.
# If HTTP is disabled locally, try HTTPS.
code_catalog="$(json_get_http_code "http://127.0.0.1:${API_PORT}/v1/catalog/services")"
if [[ "$code_catalog" == "000" ]]; then
  code_catalog="$(json_get_http_code "https://127.0.0.1:${HTTPS_PORT}/v1/catalog/services")"
fi

code_self="$(json_get_http_code "http://127.0.0.1:${API_PORT}/v1/agent/self")"
if [[ "$code_self" == "000" ]]; then
  code_self="$(json_get_http_code "https://127.0.0.1:${HTTPS_PORT}/v1/agent/self")"
fi

# 3) Optional config hints.
ui_enabled="unknown"
client_addr_external="unknown"
default_token_present="unknown"
script_checks_enabled="unknown"

if [[ -d "$CONFIG_DIR" ]]; then
  if grep -RqsE 'ui_config\s*\{[^}]*enabled\s*=\s*true|^\s*-ui\b|^\s*ui\s*=\s*true' "$CONFIG_DIR" 2>/dev/null; then
    ui_enabled="true"
  else
    ui_enabled="false"
  fi

  if grep -RqsE 'client_addr\s*=\s*"(0\.0\.0\.0|[^1][^"]*|{{.*}})"' "$CONFIG_DIR" 2>/dev/null; then
    client_addr_external="true"
  else
    client_addr_external="false"
  fi

  if grep -RqsE 'tokens\s*\{[^}]*default\s*=' "$CONFIG_DIR" 2>/dev/null; then
    default_token_present="true"
  else
    default_token_present="false"
  fi

  if grep -RqsE 'enable_script_checks\s*=\s*true' "$CONFIG_DIR" 2>/dev/null; then
    script_checks_enabled="true"
  else
    script_checks_enabled="false"
  fi
fi

# 4) Decision logic.
if [[ "$listen_non_loopback" -eq 1 && ( "$code_catalog" == "200" || "$code_self" == "200" ) ]]; then
  status="VULNERABLE"
  reason="Consul listens off-loopback and unauthenticated API reads succeeded"
elif [[ "$listen_non_loopback" -eq 0 ]]; then
  status="PATCHED"
  reason="Consul listener appears loopback-only"
elif [[ "$listen_non_loopback" -eq 1 && ( "$code_catalog" == "403" || "$code_self" == "403" ) ]]; then
  status="PATCHED"
  reason="Consul is reachable locally but unauthenticated requests are denied; exposure remains a hardening concern if network-published"
else
  status="UNKNOWN"
  reason="Could not conclusively verify listener exposure and unauthenticated access"
fi

echo "${status} - ${reason} | ui_enabled=${ui_enabled} client_addr_external=${client_addr_external} default_token_present=${default_token_present} script_checks_enabled=${script_checks_enabled} http_catalog=${code_catalog} http_self=${code_self}"

case "$status" in
  VULNERABLE) exit 1 ;;
  PATCHED) exit 0 ;;
  *) exit 2 ;;
esac

Sources

1. Tenable Nessus Plugin 111351
2. HashiCorp Help Center: Consul Web UI and API is Accessible Remotely if not Configured Properly
3. HashiCorp Consul UI documentation
4. HashiCorp Consul security architecture
5. HashiCorp HTTP API structure and authentication
6. HashiCorp ACL token documentation
7. HashiCorp default token and anonymous token relationship
8. HashiCorp health checks and script-check security warning