Redis Server Unprotected by Password Authentication

Tenable plugin 100634 fires when a Redis service answers without requiring AUTH or ACL-based authentication. In practice, this affects any Redis deployment the scanner can reach that accepts unauthenticated commands, regardless of branch version; newer Redis releases added protected-mode, but that only helps when admins leave the safer defaults in place and do not bind broadly or disable the protection.

Tenable rates this plugin Critical, and that is too aggressive as a fleet-wide default. The real risk hinges on *who can reach port 6379 from where*: if it is internet-facing, this is absolutely a live-fire incident; if it is only reachable on an internal app segment, it is still bad but usually a post-initial-access lateral-movement problem rather than an enterprise-wide pre-auth internet RCE.

Why this verdict

• Baseline down from Tenable Critical: this is a misconfiguration requiring network reachability, not a wormable product bug that self-executes across every deployment.
• Exposure fraction matters: a large share of enterprise Redis nodes live on private app segments, so many 100634 hits imply post-initial-access lateral movement rather than unauthenticated internet compromise.
• Immediate abuse once reachable: if an attacker can talk to the service, they can usually read or tamper with data right away with redis-cli; there is essentially zero exploit complexity at that point.
• Active exploitation keeps it high: HeadCrab and RedisRaider show this condition is not theoretical, so I will not score it as medium backlog hygiene.
• OS compromise is conditional, not automatic: classic cron, authorized_keys, replication, or module-loading abuse depends on command availability, runtime privileges, and filesystem conditions.

Why not higher?

I did not keep Tenable's Critical rating because the plugin does not prove internet exposure, and it does not prove guaranteed host-level code execution. In many enterprises, an attacker must already be on an internal network path to reach Redis at all, which compounds downward pressure on severity.

Why not lower?

I did not drop this to Medium because unauthenticated access to a live data store is still direct compromise of confidentiality and integrity from any reachable segment. Public threat reporting shows real, ongoing abuse of exposed Redis, so treating it as routine hardening would understate the operational risk.

1. Block untrusted network paths — Restrict TCP/6379 and any nonstandard Redis ports to known application sources only. Because exposed Redis is actively exploited, deploy this immediately, within hours, rather than waiting for the normal HIGH-window.
2. Enforce Redis authentication — Enable Redis 6+ ACLs where supported, or legacy requirepass where that is what the application stack uses, then retest from the same network path Nessus used. Apply this immediately, within hours on any externally reachable or shared-segment instance.
3. Verify protected-mode and bind settings — Confirm Redis is not listening broadly with unsafe bind settings and that protected-mode has not been disabled in a way that defeats default safety rails. Do this within hours for internet-facing estates and within 30 days for the rest of the HIGH population.
4. Constrain dangerous command paths — Use ACLs to remove or tightly limit high-risk capabilities such as CONFIG, replication control, MODULE, and script execution for application identities. Roll this out within 30 days to reduce the chance that a data-plane exposure turns into host persistence.
5. Hunt for post-exploitation artifacts — Check affected Linux hosts for suspicious cron entries, altered Redis save directories, unexpected modules, miner processes, and unauthorized SSH keys. Prioritize this immediately, within hours for anything internet-exposed or recently reachable from untrusted networks.

Run this from an auditor workstation or jump host on the same network path Nessus used, not just from localhost on the target, because reachability is the key risk variable. Invoke it as ./check_redis_noauth.sh 10.0.12.34 6379; it needs redis-cli installed and no special privileges.

#!/usr/bin/env bash
# check_redis_noauth.sh
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

HOST="${1:-}"
PORT="${2:-6379}"
TIMEOUT="${TIMEOUT:-3}"

if [[ -z "$HOST" ]]; then
  echo "UNKNOWN"
  exit 2
fi

if ! command -v redis-cli >/dev/null 2>&1; then
  echo "UNKNOWN"
  exit 2
fi

OUT="$(timeout "$TIMEOUT" redis-cli -h "$HOST" -p "$PORT" --raw PING 2>&1 || true)"

# Vulnerable: unauthenticated command execution succeeded.
if echo "$OUT" | grep -Eq '^PONG$'; then
  echo "VULNERABLE"
  exit 1
fi

# Patched / not exploitable from this vantage point.
if echo "$OUT" | grep -Eiq 'NOAUTH|WRONGPASS|NOPERM|Authentication required|DENIED Redis is running in protected mode'; then
  echo "PATCHED"
  exit 0
fi

# Connection/path ambiguity.
if echo "$OUT" | grep -Eiq 'Connection refused|Operation timed out|No route to host|Could not connect|Name or service not known'; then
  echo "UNKNOWN"
  exit 2
fi

# Fallback: try INFO to handle odd responses.
OUT2="$(timeout "$TIMEOUT" redis-cli -h "$HOST" -p "$PORT" --raw INFO server 2>&1 || true)"
if echo "$OUT2" | grep -Eiq '^redis_version:'; then
  echo "VULNERABLE"
  exit 1
fi
if echo "$OUT2" | grep -Eiq 'NOAUTH|WRONGPASS|NOPERM|Authentication required|DENIED Redis is running in protected mode'; then
  echo "PATCHED"
  exit 0
fi

echo "UNKNOWN"
exit 2

Sources

1. Tenable Nessus Plugin 100634
2. Redis official security documentation
3. Redis official administration notes
4. Censys exposed Redis analysis
5. Aqua Security HeadCrab analysis
6. Datadog Security Labs RedisRaider analysis