SSL Weak Cipher Suites Supported

Tenable plugin 26928 is not a single product CVE; it is a configuration finding that fires when a scanned TLS/DTLS service will still negotiate weak cipher suites. In practice that means any product or version on the affected port can be flagged if it accepts suites like RC4, 3DES, DES, NULL, EXPORT, or other low-strength combinations, even when the same service also offers strong TLS 1.2/1.3 ciphers.

Tenable's MEDIUM label is reasonable as generic crypto hygiene, but it overstates the operational urgency for most enterprises. Real abuse usually requires the attacker to be an active client using a legacy offer set or to hold an on-path/MITM position, and the usual outcome is a confidentiality downgrade rather than host compromise, so for a 10,000-host patch queue this belongs in LOW unless the service is internet-facing, business-critical, and intentionally supports legacy clients.

Why this verdict

• Start from Tenable's 5.3 baseline, then subtract for attacker position. Real abuse commonly needs a malicious legacy-capable client or an on-path/MITM foothold, which is materially harder than a generic unauthenticated remote exploit.
• Exposure population is much narrower than the plugin name suggests. 26928 fires on any reachable TLS service, including internal-only ports, admin planes, and compatibility listeners that are never exposed to arbitrary internet clients.
• Blast radius is session confidentiality downgrade, not host compromise. Weak cipher acceptance is bad crypto hygiene, but by itself it does not give RCE, auth bypass, or domain-wide lateral movement.

Why not higher?

There is no KEV signal, no product-specific exploit chain, and no evidence that this finding alone is being mass-weaponized. Modern clients, load balancers, and OS crypto libraries also suppress many of the weakest suites by default, which breaks a lot of theoretical attack paths in practice.

Why not lower?

This is still a real security control gap, especially on internet-facing services or places where legacy clients are common. If the supported suite is truly broken (RC4, DES, NULL, EXPORT, weak MD5 constructions), an attacker with the right position can absolutely turn it into data exposure and compliance pain.

1. Isolate legacy clients — Move any unavoidable legacy TLS support to a separate listener, VIP, or internal-only endpoint so the primary service can run a modern cipher set. For a LOW verdict there is no SLA (treat as backlog hygiene), but do it in the next scheduled TLS hardening cycle rather than leaving the exception on your main edge.
2. Enforce strong cipher policy — Disable RC4, 3DES, DES, NULL, EXPORT, anonymous, and similarly weak suites in the application, reverse proxy, load balancer, or OS crypto policy, and prefer TLS 1.2/1.3 with modern AEAD suites. For a LOW verdict there is no SLA (treat as backlog hygiene), so fold this into standard config management instead of emergency patching.
3. Log negotiated ciphers — Turn on TLS handshake telemetry at the edge so you can see whether weak suites are ever actually negotiated before and after cleanup. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is the fastest way to separate dead config from real business dependency.

Run this from an auditor workstation or jump host with network reachability to the target service, not from the target itself. Invoke it as ./check_weak_tls.sh <host> <port> [sni], for example ./check_weak_tls.sh app01.example.com 443 app01.example.com; no root is required, but nmap should be installed for best results.

#!/usr/bin/env bash
# check_weak_tls.sh
# Purpose: detect whether a remote TLS service still negotiates weak cipher suites
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -u

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

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

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

# Prefer Nmap because it enumerates accepted suites directly.
if have_cmd nmap; then
  OUT="$(nmap -Pn -sV --script ssl-enum-ciphers -p "$PORT" --script-args tls.servername="$SNI" "$HOST" 2>/dev/null)"
  if [[ -z "$OUT" ]]; then
    echo "UNKNOWN"
    exit 2
  fi

  # Flag classic weak patterns commonly associated with Nessus 26928-style findings.
  if echo "$OUT" | grep -Eiq '(_3DES_|\b3DES\b|_RC4_|\bRC4\b|_DES_|\bDES\b|_NULL_|\bNULL\b|EXPORT|MD5 for message integrity|least strength: [C-F])'; then
    echo "VULNERABLE"
    exit 0
  fi

  if echo "$OUT" | grep -Eiq 'ssl-enum-ciphers:'; then
    echo "PATCHED"
    exit 1
  fi
fi

# Fallback to OpenSSL point checks if Nmap is unavailable.
if ! have_cmd openssl; then
  echo "UNKNOWN"
  exit 2
fi

FOUND=0
TESTED=0

probe() {
  local proto="$1"
  local cipher="$2"
  local out
  out="$(echo | openssl s_client -connect "${HOST}:${PORT}" -servername "$SNI" "$proto" -cipher "$cipher" -brief 2>/dev/null || true)"

  # OpenSSL may refuse local use of legacy ciphers; that means this probe is inconclusive, not safe.
  if echo "$out" | grep -Eiq 'no cipher match|unsupported protocol|wrong version number|unknown option'; then
    return 1
  fi

  TESTED=1
  if echo "$out" | grep -Eiq 'Protocol *:|Ciphersuite *:'; then
    FOUND=1
    return 0
  fi
  return 1
}

# Common weak suites; availability depends on local OpenSSL build.
for proto in -tls1 -tls1_1 -tls1_2; do
  for cipher in RC4-SHA RC4-MD5 DES-CBC3-SHA DES-CBC-SHA NULL-SHA NULL-MD5 EXP-RC4-MD5 ADH-AES128-SHA; do
    if probe "$proto" "$cipher"; then
      echo "VULNERABLE"
      exit 0
    fi
  done
done

if [[ "$TESTED" -eq 1 ]]; then
  echo "PATCHED"
  exit 1
fi

echo "UNKNOWN"
exit 2

Sources

1. Tenable plugin 26928
2. Vulners mirror of Tenable NASL logic
3. CISA Known Exploited Vulnerabilities Catalog
4. FIRST EPSS FAQ
5. Nmap ssl-enum-ciphers documentation
6. OWASP Transport Layer Security Cheat Sheet
7. Microsoft TLS Cipher Suites in Windows 11
8. Red Hat guidance on weak/medium SSL cipher findings