This is a rusty side door on the vault, but the attacker still has to stand in the hallway and catch you using it
Tenable plugin 106459 is a *configuration finding*, not a product-specific bug. It fires when a TLS service offers finite-field Diffie-Hellman key exchange with a public modulus smaller than 2048 bits, which Tenable maps to the broader CVE-2015-4000 / Logjam class. In practice, the affected population is any web, mail, VPN, load balancer, Java, or appliance TLS endpoint still advertising DHE groups below PCI/NIST strength guidance; there is no single affected version range because this is driven by cipher and DH-parameter configuration.
Vendor severity is already basically right: this is low real-world security risk for most enterprises, even if it can absolutely fail a PCI scan. The decisive friction is attacker position: exploitation is not unauthenticated internet-to-RCE, it is *man-in-the-middle cryptographic weakening* against a subset of connections that negotiate these DHE parameters. That makes it materially less urgent than patchable edge bugs, even though it remains worth fixing on internet-facing and PCI-scoped systems.
4 steps from start to impact.
Enumerate weak DHE support with nmap ssl-enum-ciphers or openssl s_client
2048 bits, the host is flagged.- Network reachability to the TLS service
- Service must still offer DHE cipher suites
- Server must expose finite-field DH parameters below 2048 bits
- A growing share of modern estates prefer ECDHE only, so there is no weak DHE path to abuse
- Some endpoints expose the finding only on legacy listeners, not on the main production virtual host
nmap --script ssl-enum-ciphers, and direct openssl s_client handshakes all catch this reliably.Gain man-in-the-middle position using bettercap/router compromise/BGP or local network interception
- Attacker can intercept or relay traffic between client and server
- Victim must initiate a TLS session through the attacker's vantage point
- Internet-wide opportunistic scanning does not equal exploitability here
- Modern enterprise networks, VPNs, ZTNA, and certificate validation reduce practical MITM opportunities
- Post-initial-access internal interception is possible, but that means the attacker is already inside
Downgrade or exploit weak/common DH parameters with Logjam-style tooling
- Client and server must complete a handshake on the weak DHE path
- Weak or common groups must be accepted by both ends
- Attacker must have capability and timing to exploit the negotiated parameters
- Modern clients have raised minimums and reject many truly weak parameter sets
- The original internet-scale concern centered on common
1024-bit groups; many scanner hits today are configuration leftovers rather than readily exploitable internet targets - No turnkey one-packet mass exploitation path exists
Read or tamper with exposed session data
- Intercepted session carries data the attacker actually wants
- Handshake weakening succeeds for that victim and that path
- Impact is scoped to observed traffic, not arbitrary code execution on the server
- Many enterprise sessions are short-lived, mutually authenticated, or already wrapped in additional controls
The supporting signals.
| In-the-wild status | No credible current evidence of broad active exploitation campaigns tied to this finding class. This is an old, well-understood crypto weakness pattern, not a fresh operational edge bug. |
|---|---|
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities catalog. |
| Public PoC / research | Yes, but mostly research-grade. The original WeakDH / Logjam research and supporting material explain downgrade and precomputation attacks; this is not the kind of vuln typically abused with commodity exploit kits. |
| EPSS | Third-party aggregators currently show high EPSS (~0.93-0.94) for CVE-2015-4000, but treat that cautiously here: EPSS reflects historical exploitation likelihood at the CVE level, while this Tenable hit is a *configuration-only subset* with strong attacker-position friction. |
| CVSS vector | CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N from NVD/Tenable. Translation: network reachable, but high attack complexity and no direct availability impact. |
| Affected scope | Any TLS service that still offers finite-field DHE with a modulus below 2048 bits. This is not version-bounded to one product family; it is driven by server crypto configuration, bundled DH params, and sometimes old load-balancer or appliance defaults. |
| Fixed state | There is no universal patched build. The secure state is: use DH parameters >= 2048 bits or disable finite-field DHE entirely and prefer ECDHE. Many distro and vendor fixes were backports or config changes rather than major version jumps. |
| Exposure data | Historical internet census from WeakDH and Cloudflare showed meaningful exposure in 2015, including common 1024-bit groups across large server populations. That made precomputation attractive then; modern exposure is generally lower, but scanner findings still persist on legacy appliances and forgotten listeners. |
| Disclosure date | 2015-05-20 for CVE-2015-4000 / Logjam. |
| Research attribution | Reported by the Logjam / WeakDH research team, including academics from the University of Michigan and collaborators, published at weakdh.org. |
noisgate verdict.
The single biggest downgrade factor is the required attacker position: this finding needs an on-path adversary and a successful weak-DHE negotiation, which sharply narrows real enterprise exploitability. It matters for compliance and crypto hygiene, but it does not behave like a remotely exploitable foothold or privilege-escalation path across 10,000 hosts.
Why this verdict
- Requires MITM, not just reachability: network access alone is insufficient; the attacker must control or intercept the path between client and server.
- Configuration hit, not host compromise: the practical impact is exposed session confidentiality/integrity on negotiated traffic, not direct RCE or auth bypass on the server.
- Population narrows fast in modern estates: many clients and servers now prefer ECDHE or reject truly weak groups, so a scanner positive does not equal easy exploitation.
- Compliance amplifies attention, not attacker ease: PCI cares because
<2048-bit DH is below strong-crypto guidance, but audit pain should not be mistaken for incident-grade exploitability.
Why not higher?
This does not give an unauthenticated attacker code execution, privilege escalation, or a reliable one-shot breach path. The need for on-path interception plus successful negotiation of a weak finite-field DHE path is heavy friction, and that compounds downward in real deployments.
Why not lower?
It is still a real cryptographic weakness, especially on public-facing or PCI-scoped services handling sensitive traffic. If you leave weak DH enabled on internet-exposed systems, you are carrying unnecessary confidentiality risk and likely audit debt even if the exploitation bar is high.
What to do — in priority order.
- Prefer ECDHE-only cipher suites — Disable finite-field DHE where the application stack allows it and let the service negotiate
ECDHEinstead. For a LOW noisgate verdict there is no SLA; treat this as backlog hygiene and fold it into your next TLS hardening cycle. - Regenerate DH params at 2048 bits or higher — Where DHE must remain enabled for compatibility, generate unique
2048-bit-or-better DH parameters instead of shipping with weak or bundled defaults. For a LOW verdict there is no SLA; prioritize externally exposed and PCI-scoped listeners first. - Kill legacy listeners and shadow TLS services — A lot of these findings survive on forgotten admin ports, old VIPs, mail listeners, and appliance management interfaces. For a LOW verdict there is no SLA; use the scanner output to close the exact port/service combinations rather than launching broad emergency patching.
- Segment and monitor interception-prone networks — Since exploitation needs a man-in-the-middle position, tighten L2/L3 trust boundaries, suppress rogue gateways, and watch for ARP/DHCP/routing anomalies. For a LOW verdict there is no SLA; this is architecture hardening, not break-fix firefighting.
- Blindly patching OpenSSL packages alone doesn't guarantee closure, because the finding often survives as a server configuration issue or appliance default.
- Endpoint EDR doesn't meaningfully mitigate this path; the attack happens in the network handshake, not as malware executing on the host.
- Rotating X.509 certificates does not fix weak DH parameters; certificate key length and negotiated ephemeral DH group size are separate controls.
Crowdsourced verification payload.
Run this from an auditor workstation or jump host that can reach the target TLS service. Invoke it as ./check_weak_dh.sh host.example.com 443; no privileges are required, but you need openssl in the path. The script attempts a TLS 1.2 DHE handshake and reports VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env bash
# check_weak_dh.sh
# Detect weak finite-field DH (<2048 bits) on a remote TLS service.
# Usage: ./check_weak_dh.sh <host> [port]
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / error / no DHE path observed
set -u
HOST="${1:-}"
PORT="${2:-443}"
TIMEOUT_BIN=""
if [ -z "$HOST" ]; then
echo "UNKNOWN - usage: $0 <host> [port]"
exit 2
fi
if command -v timeout >/dev/null 2>&1; then
TIMEOUT_BIN="timeout 15"
fi
if ! command -v openssl >/dev/null 2>&1; then
echo "UNKNOWN - openssl not found"
exit 2
fi
# Try to force a finite-field DHE TLS 1.2 handshake.
OUTPUT=$(echo | sh -c "$TIMEOUT_BIN openssl s_client -connect ${HOST}:${PORT} -servername ${HOST} -tls1_2 -cipher 'DHE' 2>&1")
RC=$?
# If the handshake failed entirely, we likely don't have a DHE path.
if [ $RC -ne 0 ] && ! printf '%s\n' "$OUTPUT" | grep -qi 'Server Temp Key:'; then
# Distinguish 'no shared cipher' from total failure.
if printf '%s\n' "$OUTPUT" | grep -Eqi 'no cipher match|no shared cipher|handshake failure|alert handshake failure'; then
echo "PATCHED - no finite-field DHE handshake available"
exit 0
fi
echo "UNKNOWN - could not complete test handshake"
exit 2
fi
TEMP_KEY_LINE=$(printf '%s\n' "$OUTPUT" | grep -i 'Server Temp Key:' | tail -n 1 || true)
if [ -z "$TEMP_KEY_LINE" ]; then
if printf '%s\n' "$OUTPUT" | grep -Eqi 'no cipher match|no shared cipher|handshake failure|alert handshake failure'; then
echo "PATCHED - no finite-field DHE handshake available"
exit 0
fi
echo "UNKNOWN - DHE not negotiated or temp key not exposed by openssl"
exit 2
fi
# Examples:
# Server Temp Key: DH, 1024 bits
# Server Temp Key: DH, 2048 bits
BITS=$(printf '%s\n' "$TEMP_KEY_LINE" | sed -n 's/.*DH, \([0-9][0-9]*\) bits.*/\1/p')
if [ -z "$BITS" ]; then
# If a temp key exists but is not finite-field DH, treat as patched for this specific finding.
if printf '%s\n' "$TEMP_KEY_LINE" | grep -Eqi 'ECDH|X25519|X448'; then
echo "PATCHED - negotiated modern ephemeral key exchange (${TEMP_KEY_LINE})"
exit 0
fi
echo "UNKNOWN - unable to parse temp key size (${TEMP_KEY_LINE})"
exit 2
fi
if [ "$BITS" -lt 2048 ]; then
echo "VULNERABLE - weak finite-field DH detected (${BITS} bits)"
exit 1
fi
echo "PATCHED - finite-field DH is ${BITS} bits"
exit 0
If you remember one thing.
106459 like an emergency patch storm across 10,000 hosts. Triage the exact hosts that are both internet-facing or PCI-scoped and still negotiate finite-field DHE below 2048 bits, then fix those during your normal TLS hardening program by preferring ECDHE or raising DH parameters; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, though PCI-bound services may still need faster cleanup for audit reasons.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.