← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:106459 · CWE-310 · Disclosed 2015-05-20

Weak DH Key Exchange Supported

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Weak DH is mostly a compliance bruise, not a Monday-morning incident driver"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Enumerate weak DHE support with nmap ssl-enum-ciphers or openssl s_client

The attacker or auditor first confirms the endpoint offers finite-field DHE and inspects the ephemeral server key size. Tenable's plugin is doing exactly that remotely: if the handshake shows DH parameters under 2048 bits, the host is flagged.
Conditions required:
  • Network reachability to the TLS service
  • Service must still offer DHE cipher suites
  • Server must expose finite-field DH parameters below 2048 bits
Where this breaks in practice:
  • 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
Detection/coverage: Excellent scanner coverage. Nessus, Qualys, nmap --script ssl-enum-ciphers, and direct openssl s_client handshakes all catch this reliably.
STEP 02

Gain man-in-the-middle position using bettercap/router compromise/BGP or local network interception

This is the big reality check: the attacker must sit on-path to the victim's TLS session or control a network segment that can influence the handshake. Without that position, weak DH support is just a bad crypto setting with no direct attack path.
Conditions required:
  • Attacker can intercept or relay traffic between client and server
  • Victim must initiate a TLS session through the attacker's vantage point
Where this breaks in practice:
  • 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
Detection/coverage: Weak. TLS scanners see exposure, but on-path interception itself is usually caught by network monitoring, rogue gateway detection, ARP/DHCP anomaly tooling, or upstream provider telemetry rather than vuln management.
STEP 03

Downgrade or exploit weak/common DH parameters with Logjam-style tooling

If the service and client negotiate weak finite-field DH, the attacker may attempt downgrade or precomputation-assisted attacks against common groups, especially in the original Logjam model. The security impact is primarily confidentiality loss and limited integrity risk on that traffic, not host takeover.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Exposure is easy to detect; active exploitation is hard unless you collect full handshake metadata and can see unexpected DHE negotiation or on-path tampering.
STEP 04

Read or tamper with exposed session data

Successful exploitation yields visibility into the protected connection or some ability to alter traffic in transit, depending on the exact handshake and client behavior. That is serious for the affected session, but the blast radius is narrow compared with an RCE or auth bypass.
Conditions required:
  • Intercepted session carries data the attacker actually wants
  • Handshake weakening succeeds for that victim and that path
Where this breaks in practice:
  • 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
Detection/coverage: Application logs rarely help. TLS telemetry, packet capture, and anomaly hunting around cipher negotiation are more useful than endpoint tools.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 statusNot listed in the CISA Known Exploited Vulnerabilities catalog.
Public PoC / researchYes, 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.
EPSSThird-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 vectorCVSS: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 scopeAny 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 stateThere 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 dataHistorical 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 date2015-05-20 for CVE-2015-4000 / Logjam.
Research attributionReported by the Logjam / WeakDH research team, including academics from the University of Michigan and collaborators, published at weakdh.org.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.6/10)

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.

HIGH Severity bucket for typical enterprise environments
MEDIUM Exact exploitability of any one endpoint without seeing its client population and TLS stack

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.

05 · Compensating Control

What to do — in priority order.

  1. Prefer ECDHE-only cipher suites — Disable finite-field DHE where the application stack allows it and let the service negotiate ECDHE instead. For a LOW noisgate verdict there is no SLA; treat this as backlog hygiene and fold it into your next TLS hardening cycle.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat plugin 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

  1. Tenable Nessus Plugin 106459
  2. NVD CVE-2015-4000
  3. WeakDH / Logjam research site
  4. WeakDH deployment guidance
  5. NIST SP 800-57 Part 1 Rev. 5
  6. Cloudflare Logjam explainer
  7. FIRST EPSS overview
  8. CISA KEV catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.