OpenXDMoD is an open framework for collecting and analyzing HPC metrics

CVE-2026-45777 is an unauthenticated OS command injection in Open XDMoD. Affected versions are 9.5.0 through 11.0.2, fixed in 11.0.3. If an attacker can reach the vulnerable web interface, they can execute arbitrary system commands as the web server process on the XDMoD host, which puts application data, configs, reports, and service availability at risk.

In pure technical terms this looks like a top-tier bug: remote, no auth, no user click, command execution. In real enterprise operations, though, OpenXDMoD is a specialized HPC portal, not a mass-market edge platform, and many deployments are limited to campus, VPN, or research networks. That deployment friction matters. This is still serious enough for a HIGH, but the narrower exposed population keeps it below CRITICAL in a 10,000-host prioritization stack.

Why this verdict

• No-auth remote RCE keeps the base risk high: network-reachable command injection on a web server is always dangerous.
• Product footprint is narrow: OpenXDMoD is an HPC metrics portal, not a ubiquitous edge appliance, so the exposed population is materially smaller than what a vacuum CVSS score implies.
• Typical deployment friction matters: many instances are campus-only, VPN-restricted, or otherwise not broadly internet-reachable, which compounds downward pressure on severity.
• Blast radius is host-scoped first: execution lands as the web-server process, so full environment takeover still depends on local creds, weak segmentation, or privilege-escalation follow-on.
• Threat telemetry is cold: no KEV listing, no public exploitation evidence in the advisory, and a very low EPSS all argue against treating this as an emergency-worm event.

Why not higher?

This is not CRITICAL because the main prerequisite is not exploit complexity but real-world exposure population. OpenXDMoD is comparatively niche, and many deployments are not internet-edge systems. Also, compromise is initially bounded by web-server privileges, not an automatic root or domain-admin outcome.

Why not lower?

This cannot be MEDIUM or LOW because once reachable, the exploit path is brutally simple in principle: network + no auth + command execution. Even with a smaller target population, any exposed vulnerable instance is one bad request away from host compromise.

1. Restrict portal reachability — Put XDMoD behind VPN, campus ACLs, or an allowlisted reverse proxy if it is not already. This directly attacks the biggest amplifier in the chain: remote unauthenticated reachability. For a HIGH verdict, deploy within 30 days, and sooner for any internet-exposed instance.
2. Deploy vendor workaround or patch — If 11.0.3 cannot be installed immediately, apply the maintainer-supplied temporary patch, then move to the full upgrade. This reduces exposure while preserving service continuity; for a HIGH verdict, complete within 30 days.
3. Hunt for web-to-shell behavior — Alert on httpd/Apache spawning shells, scripting interpreters, curl, wget, python, or package managers. This is the most reliable post-facto signal that the injection path was abused. Stand up the detection within 30 days.
4. Tighten egress and service accounts — Constrain outbound traffic from the XDMoD host and audit what the web server account can read, execute, and reach. This limits post-exploitation blast radius if an attacker lands code execution. Apply within 30 days.
5. Rotate exposed app secrets after patching — Assume configs, tokens, and DB credentials on the host may have been exposed if the instance was internet-reachable before patching. Rotate them after mitigation and patch completion, especially API and database credentials, within the 30-day HIGH window.

Run this on the target Open XDMoD server itself, preferably as root or with privileges to query installed RPMs. Invoke it as bash check_xdmod_cve_2026_45777.sh; it checks the official RPM package path first and returns VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check_xdmod_cve_2026_45777.sh
# Determine whether an RPM-installed Open XDMoD host is vulnerable to CVE-2026-45777.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

set -u

PKG="xdmod"
FIXED="11.0.3"

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

ver_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ] && [ "$1" != "$2" ]
}

ver_ge() {
  # returns 0 if $1 >= $2
  ! ver_lt "$1" "$2"
}

if have_cmd rpm; then
  if rpm -q "$PKG" >/dev/null 2>&1; then
    INSTALLED="$(rpm -q --qf '%{VERSION}\n' "$PKG" 2>/dev/null)"
    if [ -z "$INSTALLED" ]; then
      echo "UNKNOWN - RPM package found but version could not be read"
      exit 2
    fi

    # Affected: >= 9.5.0 and < 11.0.3
    if ver_ge "$INSTALLED" "9.5.0" && ver_lt "$INSTALLED" "$FIXED"; then
      echo "VULNERABLE - Open XDMoD $INSTALLED is in affected range >=9.5.0,<11.0.3"
      exit 1
    fi

    if ver_ge "$INSTALLED" "$FIXED"; then
      echo "PATCHED - Open XDMoD $INSTALLED is >= 11.0.3"
      exit 0
    fi

    echo "PATCHED - Open XDMoD $INSTALLED is older than 9.5.0 and outside the published affected range"
    exit 0
  fi
fi

# If we get here, the official RPM package was not detected.
# Open XDMoD can also be installed from source, but authoritative version discovery is environment-specific.
for d in /usr/share/xdmod /opt/xdmod/share /opt/xdmod; do
  if [ -d "$d" ]; then
    echo "UNKNOWN - XDMoD files found at $d but no RPM package detected; likely source/custom install. Verify deployed version manually against fixed version 11.0.3."
    exit 2
  fi
done

echo "UNKNOWN - Open XDMoD package/files not found on this host"
exit 2

Sources

1. Open XDMoD GHSA advisory for CVE-2026-45777
2. Open XDMoD 11.0.3 release notes
3. Open XDMoD 11.0 software requirements
4. Open XDMoD data analytics framework docs
5. Open XDMoD support lifecycle and logs
6. Trusted CI Open XDMoD assessment report
7. FIRST EPSS API documentation
8. CISA Known Exploited Vulnerabilities Catalog