This is an old lock with a fussy picking technique that only works if the attacker is already standing in your hallway
Tenable plugin 70658 fires when an SSH server *offers* CBC-mode ciphers such as aes128-cbc, aes256-cbc, or 3des-cbc. Tenable maps it to CVE-2008-5161, an old SSH protocol weakness where CBC-mode traffic can leak small amounts of plaintext under narrow conditions. Important nuance: the plugin explicitly says it checks cipher *configuration*, not whether the underlying SSH implementation/version is itself vulnerable.
The vendor LOW is directionally right, and I'd actually lean slightly lower in operational urgency. Real exploitation needs an *on-path* attacker, repeated session disruption, and favorable plaintext positioning; impact is limited to partial confidentiality loss, not code execution or auth bypass. For a 10,000-host estate, this belongs in SSH hardening and exposure reduction, not in the same queue as remotely exploitable edge RCEs.
4 steps from start to impact.
Find SSH services that still advertise CBC
nmap --script ssh2-enum-algos or ssh-audit to enumerate server-offered ciphers and confirm CBC is still negotiable. This step only proves a weak option exists; it does not prove the implementation is exploitable in practice.- TCP reachability to the SSH service
- Server still advertises one or more
*-cbcciphers
- Many enterprise SSH services are internal-only or management-plane restricted
- Modern clients usually prefer CTR/GCM/ChaCha20 if those are also offered
ssh-audit all catch this class of configuration issue reliably.Gain man-in-the-middle position
bettercap, Ettercap, rogue Wi-Fi, ARP spoofing, or upstream routing control. This is the decisive friction point: it implies prior compromise of the local network, a hostile network, or provider-level position.- Attacker can intercept and modify packets between SSH client and server
- Traffic is not already protected by an outer trusted tunnel that defeats the attacker position
- Requires internal network access, adjacent position, or upstream control
- ARP spoofing and gateway tampering are noisy in managed enterprise networks
- 802.1X, NAC, VPN, and segmented admin networks sharply reduce reachable population
Force repeated CBC-protected sessions and harvest tiny plaintext leaks
- Client and server actually negotiate a CBC cipher for the session
- Target data appears in a recoverable packet position
- The attacker can trigger or observe enough repeated sessions
- If either side negotiates CTR/GCM/ChaCha20 instead, the path dies
- Repeated disconnects are user-visible and operationally noisy
- Recovering useful secrets is much harder when key-based auth or MFA is used
Turn leaked plaintext into value
- Recovered plaintext contains sensitive and actionable data
- The target workflow sends something worth stealing over the affected session
- Public-key authentication reduces value versus password logins
- Many SSH admin sessions are brief, scripted, and low in recoverable secret density
- No direct integrity or availability win from the weakness itself
The supporting signals.
| In-the-wild status | No strong evidence of current real-world exploitation found in primary sources reviewed. Tenable itself says *no known exploits are available* for this plugin/CVE mapping. |
|---|---|
| KEV status | Not KEV-listed in CISA's Known Exploited Vulnerabilities catalog as of this assessment; this is an inference from the current catalog and targeted searches, not a vendor statement. |
| Proof-of-concept availability | Research exists, weaponization is niche. Public writeups and advisories describe the CBC plaintext-recovery technique, but there is no mainstream commodity exploit path comparable to SSH RCEs. |
| EPSS | Low threat signal overall. FIRST defines EPSS as the probability of exploitation in the next 30 days; exact per-CVE score was not directly pulled from the FIRST API in-session, so treat third-party mirrors cautiously. |
| CVSS and impact | Tenable shows CVSS v3 3.7 / LOW (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N). That matches reality: network-reachable in theory, but high complexity and confidentiality-only impact. |
| Affected scope | This is not one product/version. It affects SSH deployments that still negotiate CBC ciphers; NVD's historical CVE text references OpenSSH 4.7p1 and possibly other versions plus older SSH Tectia lines. |
| Fixed state | There is no universal patched version for the plugin finding itself because the finding is configuration-driven. The practical fix is to disable CBC and prefer CTR/GCM/ChaCha20. |
| Scanner fidelity | High for detection, low for exploitability judgment. Tenable clearly states the plugin checks SSH options only and does not validate vulnerable software versions. |
| Exposure reality | SSH is a heavily scanned Internet service, and Censys notes broad visibility into SSH exposures. But internet exposure alone does not make this urgent because exploitation still requires MITM/on-path capability. |
| Disclosure lineage | Published in November 2008; CERT VU#958563 and OpenSSH's cbc.adv framed this as a plaintext-recovery weakness in CBC-mode SSH traffic, with CTR as the recommended workaround. |
noisgate verdict.
The single biggest downgrading factor is the attacker-position requirement: this is an on-path/MITM attack, which usually means the adversary already has internal access or network control. Once you factor in that prerequisite plus the limited outcome—partial plaintext leakage rather than code execution—the finding lands as hardening debt, not urgent patch debt.
Why this verdict
- Requires MITM/on-path position: this is not an unauthenticated edge-to-root bug; the attacker must already control the path between client and server.
- Negotiation has to fall back to CBC: if modern ciphers like CTR, GCM, or
[email protected]are negotiated instead, the attack chain stops. - Impact is narrow: the weakness leaks limited plaintext under constrained conditions; it does not directly provide RCE, privilege escalation, or auth bypass.
Why not higher?
A higher rating would require a realistic path from Internet reachability to material compromise. That is missing here. The exploit chain assumes post-initial-access network control, repeated session interference, and useful plaintext recovery, which is too much friction for a HIGH or CRITICAL call.
Why not lower?
I would not mark it IGNORE because CBC on admin protocols is still unnecessary legacy cryptography and occasionally appears on exposed network gear or brittle appliances. The detection is usually accurate, and disabling CBC is a sensible hardening step even if the practical exploitability is poor.
What to do — in priority order.
- Disable CBC ciphers on SSH servers — Remove
*-cbcand3des-cbcfrom the server cipher list and standardize on[email protected],aes*[email protected], oraes*-ctr. For a LOW finding there is no SLA; handle it in normal hardening/backlog hygiene, starting with Internet-exposed and admin-plane systems. - Reduce SSH exposure — Move SSH behind VPN, bastions, ACLs, or management-plane segmentation so an attacker cannot easily obtain the traffic path in the first place. For a LOW finding there is no SLA; fold this into the next remote-admin exposure review.
- Kill legacy client exceptions — CBC often survives because of a few old automation clients, appliances, or embedded stacks. Identify those dependencies, isolate them, and remove broad CBC allowances during normal crypto-baseline maintenance; for LOW, this is backlog hygiene rather than emergency work.
- Prefer key auth and MFA on jump paths — Even if a session were manipulated, environments using key-based auth and MFA reduce the value of recovered plaintext compared with password-heavy workflows. For LOW, implement during routine SSH access-hardening cycles.
- Changing SSH to a nonstandard port does not fix CBC negotiation weakness; it only changes where the scanner finds it.
- Fail2ban helps against brute force, not against an attacker who is already on path manipulating encrypted packets.
- Patching only the client or only the server is not a universal answer for this plugin, because the finding is about offered ciphers, not just software build level.
Crowdsourced verification payload.
Run this on the target Linux/Unix SSH server or on a mounted image of its config, not from an auditor workstation. Invoke it as sudo bash check_ssh_cbc.sh /etc/ssh/sshd_config; it needs read access to the SSH daemon config and may need sudo so sshd -T can evaluate the effective settings cleanly.
#!/usr/bin/env bash
# check_ssh_cbc.sh
# Exit codes:
# 0 = PATCHED (no CBC ciphers enabled)
# 1 = VULNERABLE (one or more CBC ciphers enabled)
# 2 = UNKNOWN (could not determine)
set -u
CFG="${1:-/etc/ssh/sshd_config}"
if ! command -v sshd >/dev/null 2>&1; then
echo "UNKNOWN: sshd binary not found on this host"
exit 2
fi
if [ ! -r "$CFG" ]; then
echo "UNKNOWN: cannot read config file: $CFG"
exit 2
fi
# Try to get effective config first.
CIPHERS="$(sshd -T -f "$CFG" 2>/dev/null | awk '/^ciphers / {print $2; exit}')"
# Fallback: parse configured line if sshd -T did not return a value.
if [ -z "$CIPHERS" ]; then
CIPHERS="$(grep -Ei '^[[:space:]]*Ciphers[[:space:]]+' "$CFG" | tail -n 1 | sed -E 's/^[[:space:]]*Ciphers[[:space:]]+//I')"
fi
if [ -z "$CIPHERS" ]; then
echo "UNKNOWN: unable to determine configured SSH ciphers"
exit 2
fi
BAD=()
IFS=',' read -r -a ARR <<< "$CIPHERS"
for c in "${ARR[@]}"; do
c="${c// /}"
if [[ "$c" == *-cbc ]] || [[ "$c" == "3des-cbc" ]]; then
BAD+=("$c")
fi
done
if [ ${#BAD[@]} -gt 0 ]; then
echo "VULNERABLE: CBC ciphers enabled -> ${BAD[*]}"
exit 1
else
echo "PATCHED: no CBC ciphers enabled -> $CIPHERS"
exit 0
fi
If you remember one thing.
70658 appears on Internet-exposed SSH, jump hosts, and network appliances, then either suppress it for tightly internal systems with documented rationale or queue CBC removal into your next SSH baseline refresh; under the noisgate mitigation SLA there is no SLA, and under the noisgate remediation SLA this is backlog hygiene, so a practical target is to clean up exposed/admin-plane instances in your next quarterly hardening cycle and let the rest follow normal standards maintenance.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.