SSL/TLS Services Support RC4

Tenable plugin 106458 is a configuration finding, not a product-specific RCE bug: a scanned SSL/TLS service still advertises one or more RC4 cipher suites. Any server or appliance version is effectively affected if its TLS stack or front-end config still allows RC4 during handshake negotiation; there is no single vulnerable software version range, and there is usually no one-click vendor patch because the decisive fix is to remove RC4 from the offered cipher list.

The vendor's MEDIUM label is directionally fair on paper, but in real enterprise risk terms this skews lower unless the service is both internet-facing and serving legacy clients that can still negotiate RC4. Real exploitation requires an attacker to sit on-path or passively capture traffic, force or observe RC4 negotiation, and collect very large numbers of encryptions of repeated plaintext; that is a lot more friction than a scanner finding implies. The real problem here is crypto hygiene and PCI scope, not broad, low-effort compromise.

Why this verdict

• Requires more than reachability: the attacker needs on-path visibility or passive capture, not just an exposed port.
• Negotiation narrows the population: server-side RC4 support matters only when a real client still offers RC4, which modern mainstream clients usually do not.
• Exploit complexity is high: published attacks need repeated plaintext and very large numbers of captured encryptions, which is far from one-shot exploitation.
• Impact is confidentiality-only: no direct integrity or availability impact, and no clean path to code execution or host takeover.
• Still worth fixing for compliance and crypto hygiene: if the service is PCI-scoped or serving legacy systems, the business risk rises even though exploitability stays limited.

Why not higher?

This is not an auth bypass, RCE, or privilege escalation. The chain assumes a constrained attacker position, a shrinking client population that can still negotiate RC4, and a high-volume traffic collection requirement; those are compounding brakes on real-world exploitation.

Why not lower?

It should not be ignored because RC4 is formally prohibited in TLS by RFC 7465 and fails modern crypto expectations, especially in PCI-relevant environments. If a public-facing endpoint or payment-adjacent service still negotiates RC4, you have a real confidentiality weakness and a likely compliance finding even if the exploit path is awkward.

1. Disable RC4 suites — Remove all RC4 cipher suites from the server, proxy, load balancer, and CDN policy. For a LOW verdict there is no SLA pressure, so do this in the next normal hardening change window; if the endpoint is PCI-scoped, close it as a compliance exception in that same cycle.
2. Fence legacy clients — If an old dependency still needs weak crypto, isolate it behind a dedicated listener, VIP, or transitional reverse proxy rather than leaving RC4 available broadly. For LOW, treat this as backlog hygiene and complete it during planned modernization work, not emergency maintenance.
3. Log negotiated ciphers — Turn on TLS handshake logging at the edge so you can prove whether RC4 is actually being used versus merely offered. That lets you identify the exact client populations blocking cleanup and resolve them in the next remediation cycle.
4. Raise the minimum TLS baseline — Use a modern TLS profile that removes RC4 and other legacy ciphers in one pass, ideally at the central termination layer. For LOW, there is no separate mitigation deadline, so fold this into your normal standards rollout.

Run this from an auditor workstation or scanning node that can reach the target service, not from the target host. Invoke it as ./check-rc4.sh example.com 443; it needs no privileges beyond network access, but it does require nmap with the ssl-enum-ciphers script available.

#!/usr/bin/env bash
# check-rc4.sh
# Detect whether a remote TLS service still advertises RC4 cipher suites.
# Usage: ./check-rc4.sh <host> <port>
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

HOST="${1:-}"
PORT="${2:-}"

if [[ -z "$HOST" || -z "$PORT" ]]; then
  echo "UNKNOWN - usage: $0 <host> <port>"
  exit 2
fi

if ! command -v nmap >/dev/null 2>&1; then
  echo "UNKNOWN - nmap is required"
  exit 2
fi

TMP_OUT="$(mktemp 2>/dev/null || echo /tmp/check-rc4.$$)"
trap 'rm -f "$TMP_OUT"' EXIT

# Use a short timeout to avoid hanging on dead hosts.
if ! nmap -Pn -p "$PORT" --script ssl-enum-ciphers --script-timeout 45s "$HOST" >"$TMP_OUT" 2>/dev/null; then
  echo "UNKNOWN - nmap scan failed"
  exit 2
fi

# If the port is closed or filtered, we cannot determine cipher support.
if grep -Eqi "${PORT}/tcp\s+(closed|filtered)" "$TMP_OUT"; then
  echo "UNKNOWN - port $PORT is not reachable"
  exit 2
fi

# If nmap found no TLS details, the service may not be TLS on this port.
if ! grep -qi "ssl-enum-ciphers" "$TMP_OUT"; then
  echo "UNKNOWN - no TLS cipher data returned"
  exit 2
fi

# RC4 appears in cipher names when supported.
if grep -Eqi '\bRC4\b' "$TMP_OUT"; then
  echo "VULNERABLE - RC4 cipher suite advertised by ${HOST}:${PORT}"
  exit 1
fi

# If we got TLS cipher data and no RC4 strings, treat as patched.
echo "PATCHED - no RC4 cipher suites advertised by ${HOST}:${PORT}"
exit 0

Sources

1. Tenable Nessus Plugin 106458
2. RFC 7465 - Prohibiting RC4 Cipher Suites
3. PCI SSC FAQ - Does PCI DSS define which versions of TLS must be used?
4. NIST SP 800-52 Rev. 2
5. USENIX - On the Security of RC4 in TLS
6. NVD - CVE-2013-2566
7. NVD - CVE-2015-2808
8. RC4 NOMORE