Java JMX Agent Insecure Configuration

Tenable plugin 118039 is not a classic product bug with a clean patched version. It flags a Java remote JMX agent that was started with security disabled, typically -Dcom.sun.management.jmxremote.authenticate=false and -Dcom.sun.management.jmxremote.ssl=false, while a remote JMX port is exposed. In that state, any host that can reach the JMX/RMI service can connect and manage the JVM with no credentials. On older and still-common Java releases, Oracle also documents an MLet-based path that can lead to arbitrary code execution; OpenJDK later removed m-lets in Java 23, which narrows the worst-case impact on the newest runtimes.

Tenable’s HIGH label is technically defensible if the service is internet-facing or broadly reachable on a flat internal network, because the attacker needs no auth and can land in the JVM’s security context. But for enterprise fleet prioritization, the real friction is huge: JMX remote must be explicitly enabled, reachable over the network, and often exists only for ops tooling on a narrow management path. That makes this more of an exposure-management and hardening issue than a universal emergency patch issue, so I’d downgrade the generic finding to MEDIUM unless exposure data shows public or cross-segment reachability.

Why this verdict

• Downward pressure: requires exposed management plane — the attacker does not get value unless remote JMX was explicitly enabled and left reachable. That is a substantial narrowing compared with bugs in default, externally reachable services.
• Downward pressure: often post-initial-access — in many enterprises, JMX lives on internal or restricted monitoring networks. If an attacker must already be inside the network or on a management path, this is lateral-movement fuel, not an initial foothold at scale.
• Downward pressure: blast radius is JVM-account scoped — even in the worst case the code runs as the Java process owner, not as automatic domain admin. That still matters, but it is not universally catastrophic.
• Upward pressure: no authentication — if the service is reachable, the attacker needs no creds, no user interaction, and no exploit chain gymnastics to gain management access.
• Upward pressure: public tooling exists — scanner and exploit modules are readily available, lowering operator skill requirements.
• Upward pressure: east-west value is high — once an adversary lands on one subnet, an insecure JMX endpoint can hand them app insight, secrets exposure, or JVM-context execution.

Why not higher?

I am not calling this HIGH or CRITICAL by default because the vulnerability is not in the codebase by default; it depends on a deliberate insecure deployment choice plus network exposure. Also, the strongest documented arbitrary-code path is less portable across modern Java versions than Tenable's 2018-era scoring implies.

Why not lower?

I am not dropping this to LOW because once reachable, the interface is effectively an unauthenticated remote admin channel. Even without guaranteed code execution, attackers can still monitor, manipulate, and often materially abuse the JVM in ways that support lateral movement and service disruption.

1. Block JMX at the network edge — Restrict the JMX/RMI port to only approved monitoring hosts and admin jump boxes. For a MEDIUM finding there is no mitigation SLA, but this is the cleanest risk reducer and should be completed inside the 365-day remediation window; if any instance is internet-facing, do it immediately as an exception.
2. Turn on JMX authentication — Set com.sun.management.jmxremote.authenticate=true and back it with a controlled password file or JAAS/LDAP auth. For this MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but unauthenticated remote management should not survive your next configuration cycle.
3. Enable transport protection — Use com.sun.management.jmxremote.ssl=true and preferably client authentication where operationally feasible. This does not replace network restriction, but it prevents trivial clear unauthenticated access and belongs in the same 365-day remediation window.
4. Remove remote JMX where nobody truly needs it — A surprising number of servers keep JMX because 'monitoring once needed it' rather than because current tooling does. If there is no active dependency, disable remote JMX entirely during the normal hardening cycle and finish within the 365-day remediation window.
5. Prioritize by exposure path — Split findings into internet-facing, cross-segment internal, and bastion-only. The formal verdict here is MEDIUM, but any instance reachable from untrusted or broad user segments deserves out-of-band treatment before the rest of the backlog.

Run this on the target Linux host as root or as the same account that owns the JVMs, so it can read /proc/<pid>/cmdline for all Java processes. Save as check_jmx_118039.sh and run sudo bash check_jmx_118039.sh; it inspects running Java command lines and listener state, then prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check_jmx_118039.sh
# Detect insecure remote Java JMX configuration matching Tenable plugin 118039.
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

unknown=0
vuln=0
found_java=0
have_proc=0

if [[ ! -d /proc ]]; then
  echo "UNKNOWN - /proc not available"
  exit 2
fi

if command -v ss >/dev/null 2>&1; then
  HAVE_SS=1
else
  HAVE_SS=0
fi

check_listener() {
  local port="$1"
  if [[ "$HAVE_SS" -eq 1 ]]; then
    ss -ltn 2>/dev/null | awk '{print $4}' | grep -Eq "(^|:)${port}$"
    return $?
  fi
  return 0
}

for pid in /proc/[0-9]*; do
  [[ -r "$pid/comm" ]] || continue
  procname=$(tr -d '\0' < "$pid/comm" 2>/dev/null || true)
  [[ "$procname" == "java" || "$procname" == "javaw" ]] || continue

  found_java=1
  have_proc=1

  if [[ ! -r "$pid/cmdline" ]]; then
    unknown=1
    continue
  fi

  cmd=$(tr '\0' ' ' < "$pid/cmdline" 2>/dev/null || true)
  if [[ -z "$cmd" ]]; then
    unknown=1
    continue
  fi

  jmx_enabled=0
  jmx_port=""
  auth_false=0
  ssl_false=0

  [[ "$cmd" == *"-Dcom.sun.management.jmxremote"* ]] && jmx_enabled=1

  if [[ "$cmd" =~ -Dcom\.sun\.management\.jmxremote\.port=([0-9]+) ]]; then
    jmx_port="${BASH_REMATCH[1]}"
    jmx_enabled=1
  fi

  [[ "$cmd" == *"-Dcom.sun.management.jmxremote.authenticate=false"* ]] && auth_false=1
  [[ "$cmd" == *"-Dcom.sun.management.jmxremote.ssl=false"* ]] && ssl_false=1

  if [[ "$jmx_enabled" -eq 1 && "$auth_false" -eq 1 && "$ssl_false" -eq 1 ]]; then
    if [[ -n "$jmx_port" ]]; then
      if check_listener "$jmx_port"; then
        echo "VULNERABLE - pid=$(basename "$pid") port=$jmx_port cmd=$cmd"
        vuln=1
      else
        echo "VULNERABLE - pid=$(basename "$pid") configured_jmx_port=$jmx_port cmd=$cmd"
        vuln=1
      fi
    else
      echo "VULNERABLE - pid=$(basename "$pid") remote JMX enabled with auth=false and ssl=false cmd=$cmd"
      vuln=1
    fi
  fi
done

if [[ "$found_java" -eq 0 ]]; then
  echo "PATCHED - no running Java processes found"
  exit 0
fi

if [[ "$vuln" -eq 1 ]]; then
  exit 1
fi

if [[ "$unknown" -eq 1 ]]; then
  echo "UNKNOWN - at least one Java process could not be fully inspected"
  exit 2
fi

echo "PATCHED - no insecure remote JMX configuration detected in inspected Java processes"
exit 0

Sources

1. Tenable plugin 118039
2. Oracle JMX monitoring and management guide
3. Oracle Java SE monitoring guide PDF
4. Rapid7 Metasploit exploit module
5. Rapid7 scanner module documentation
6. Horizon3 fix action for insecure Java JMX
7. OpenJDK JEP 486
8. CISA analysis report on JexBoss tooling