SSL/TLS EXPORT_RSA <= 512-bit Cipher Suites Supported

This finding means the target TLS service will still negotiate RSA_EXPORT / export-grade RSA cipher suites, letting a man-in-the-middle try to downgrade a connection to 512-bit RSA and then factor the temporary key. The classic client-side FREAK bug is tracked as CVE-2015-0204 in OpenSSL before 0.9.8zd, 1.0.0p, and 1.0.1k, but this Tenable plugin is really flagging the *server-side prerequisite*: any HTTPS/TLS endpoint whose cipher config still permits export RSA.

Tenable calling this MEDIUM is generous for most modern enterprise environments. There is no direct server takeover, no pre-auth RCE, and no standalone exploit path; the attacker needs an active on-path position *and* a client stack that still mishandles the downgrade. That combination is rare in 2026 on managed endpoints, so this is better treated as LOW-severity crypto hygiene unless you run public-facing legacy portals for unmanaged clients or old TLS interception gear.

Why this verdict

• Requires MITM first: the attacker must already control the network path, which is major downward pressure compared with ordinary internet-reachable flaws.
• Needs a second vulnerable component: export-cipher support on the server is only half the chain; the client side also has to mishandle the downgrade.
• No host compromise: even successful exploitation targets session confidentiality/integrity, not direct server code execution or privilege gain.

Why not higher?

It is not an unauthenticated RCE, not a server takeover, and not broadly wormable. The attack chain compounds friction at every step: on-path access, downgrade-capable tooling, export-cipher support, and a susceptible client stack. That is too much real-world narrowing to justify MEDIUM or HIGH for most patch queues.

Why not lower?

This is still a real cryptographic exposure, not pure scanner trivia. Public-facing services that accept export RSA are needlessly weak, and legacy clients, embedded systems, or brittle TLS interception appliances can still make the chain viable. So it belongs above IGNORE even if it should not outrank materially exploitable edge flaws.

1. Disable export ciphers — Remove EXPORT, RSA_EXPORT, and other obsolete suites from every TLS profile on load balancers, web servers, mail gateways, and appliances. For a LOW verdict there is no mandated mitigation SLA, so treat this as backlog hygiene and complete it in the next normal crypto-baseline change window.
2. Enforce modern TLS policy — Standardize on hardened TLS 1.2/1.3 configurations from a central baseline so weak suites do not reappear during certificate renewals, appliance migrations, or vendor rollbacks. For LOW, fold this into routine platform engineering rather than emergency change control.
3. Hunt legacy TLS stacks — Inventory old proxies, SSL inspection products, Java runtimes, embedded systems, and unmanaged browsers that might still be downgrade-vulnerable. Prioritize the exceptions list rather than blanket-panic patching; the real risk only exists where both sides of the chain still line up.

Run this from an auditor workstation or jump host that can reach the target TLS service; no local admin privileges are required. Invoke it as ./check_freak.sh example.com 443 or bash check_freak.sh mail.example.com 993 and it will report VULNERABLE, PATCHED, or UNKNOWN based on whether an export-grade cipher can actually be negotiated.

#!/usr/bin/env bash
# check_freak.sh
# Verify whether a remote TLS service still negotiates export-grade RSA ciphers
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN/ERROR

set -u

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

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

if command -v timeout >/dev/null 2>&1; then
  TIMEOUT_BIN="timeout 12"
fi

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

# OpenSSL syntax differs by version; try a few common export-cipher selectors.
CANDIDATES=("EXP" "EXPORT" "RSA+EXP")

for CIPHER in "${CANDIDATES[@]}"; do
  OUTPUT=$(echo | ${TIMEOUT_BIN} openssl s_client -connect "${HOST}:${PORT}" -servername "$HOST" -cipher "$CIPHER" 2>&1)
  RC=$?

  # If the local OpenSSL build has no export ciphers compiled in, try next selector.
  if echo "$OUTPUT" | grep -qiE 'no cipher match|Error with command|Unknown cipher'; then
    continue
  fi

  # Successful handshake with an export cipher means vulnerable.
  if [[ $RC -eq 0 ]] && echo "$OUTPUT" | grep -qiE 'Cipher is|Cipher    :'; then
    NEGOTIATED=$(echo "$OUTPUT" | awk -F': ' '/Cipher    :/ {print $2}' | tail -n1)
    if [[ -z "$NEGOTIATED" ]]; then
      NEGOTIATED=$(echo "$OUTPUT" | awk '/Cipher is/ {print $3}' | tail -n1)
    fi
    echo "VULNERABLE - negotiated export cipher ${NEGOTIATED:-unknown} on ${HOST}:${PORT}"
    exit 1
  fi

  # Expected failure when server refuses export ciphers.
  if echo "$OUTPUT" | grep -qiE 'handshake failure|no shared cipher|sslv3 alert handshake failure|alert handshake failure'; then
    echo "PATCHED - server refused export-grade cipher negotiation on ${HOST}:${PORT}"
    exit 0
  fi

done

# Fallback: enumerate supported ciphers if nmap is available.
if command -v nmap >/dev/null 2>&1; then
  NMAP_OUT=$(${TIMEOUT_BIN} nmap --script ssl-enum-ciphers -Pn -p "$PORT" "$HOST" 2>/dev/null)
  if echo "$NMAP_OUT" | grep -qi 'EXP'; then
    echo "VULNERABLE - nmap ssl-enum-ciphers found export-grade cipher support on ${HOST}:${PORT}"
    exit 1
  fi
  if echo "$NMAP_OUT" | grep -qi 'ssl-enum-ciphers'; then
    echo "PATCHED - nmap did not find export-grade cipher support on ${HOST}:${PORT}"
    exit 0
  fi
fi

echo "UNKNOWN - could not conclusively test ${HOST}:${PORT}; local OpenSSL may lack export ciphers and nmap fallback was unavailable"
exit 2

Sources

1. Tenable Nessus Plugin 81606
2. NVD CVE-2015-0204
3. Tracking the FREAK Attack
4. CISA FREAK SSL/TLS Vulnerability Alert
5. OpenSSL Release and Advisory Timeline
6. Red Hat analysis of FREAK
7. CISA Known Exploited Vulnerabilities Catalog
8. CVEFeed EPSS mirror for CVE-2015-0204