A SQL injection issue was discovered in Nagios XI before 5

CVE-2018-10737 is a SQL injection in Nagios XI's admin/logbook.php via the txtSearch parameter. NVD lists the affected ranges as 5.2.0-5.2.9 and 5.4.0-5.4.12, with the fix landing in 5.4.13.NVD Nagios changelog The vulnerable endpoint sits under the administrative web UI, so the practical exploit path starts with an already authenticated high-privilege user or a stolen admin session.

Vendor HIGH is technically defensible because SQLi against a monitoring platform can expose credentials, alter monitoring config, and potentially aid broader environment compromise. In real enterprise conditions, though, the PR:H requirement is the whole story: this is usually an *after-you-are-already-in* bug on a management console that most shops do not expose broadly, so the reachable population is far smaller than a classic unauthenticated web SQLi.

Why this verdict

• Downgrade for attacker position: exploitation requires authenticated remote access with high privileges, which implies the adversary already cleared identity controls or already has a foothold.
• Downgrade for reachable population: Nagios XI admin consoles are commonly internal-only or VPN-gated, so the exposed population is materially smaller than a normal public web app SQLi.
• Not a free pre-auth win: modern controls like MFA/SSO, VPN, PAM, and admin network segregation should stop the most important prerequisite *before* the vulnerable parameter is ever hit.
• Still not trivial once inside: SQLi against a monitoring platform can expose high-value operational data and create a meaningful pivot path, which keeps this from falling to LOW.

Why not higher?

There is no evidence here of an unauthenticated path, KEV listing, or confirmed active exploitation. If the bug were reachable pre-auth or if the vulnerable page were broadly public-facing in the typical enterprise, this would move up fast; but with PR:H, the real-world blast radius starts after a separate compromise has already happened.

Why not lower?

Monitoring platforms are high-value control-plane systems, not disposable line-of-business apps. Once an attacker has XI admin access, SQLi can expose credentials, configs, and integration data that make downstream compromise materially easier, so treating this as mere hygiene would understate the platform risk.

1. Restrict Nagios XI to admin-only networks — Put the XI web UI behind VPN, bastion, reverse proxy allowlists, or an internal-only segment so the first exploit prerequisite is harder to satisfy. For a MEDIUM finding there is no mitigation SLA, but this is still a good hardening move while you work inside the 365-day remediation window.
2. Enforce MFA or SSO on XI administrators — This CVE is bottlenecked by authenticated high-privilege access, so stronger admin auth directly attacks the most decisive prerequisite. There is no mitigation SLA for MEDIUM; deploy as standard identity hardening while patching within the remediation window.
3. Audit and reduce XI admin roles — Review who can access /admin/*, remove stale admins, and split read-only users from configuration admins. Fewer high-privilege accounts means fewer sessions that can turn this bug into impact.
4. Monitor XI admin-page requests and DB anomalies — Log and alert on unusual requests to /admin/logbook.php, SQL metacharacter patterns in txtSearch, and abnormal DB query bursts from the XI app account. This will not prevent exploitation, but it shortens dwell time if an admin session is abused.

Run this on the Nagios XI server itself as a local shell user; root is not strictly required if the account can read /usr/local/nagiosxi/var/xiversion. Save as check_cve_2018_10737.sh and run bash check_cve_2018_10737.sh; it reports VULNERABLE, PATCHED, or UNKNOWN based on the installed XI version.

#!/usr/bin/env bash
# check_cve_2018_10737.sh
# Determine whether the local Nagios XI install falls in the vulnerable ranges for CVE-2018-10737.
# Exit codes:
#   0 = PATCHED / not affected
#   1 = VULNERABLE
#   2 = UNKNOWN / unable to determine

set -u

VERSION_FILE="/usr/local/nagiosxi/var/xiversion"

trim() {
  local s="$1"
  s="${s#${s%%[![:space:]]*}}"
  s="${s%${s##*[![:space:]]}}"
  printf '%s' "$s"
}

normalize_version() {
  local raw="$1"
  raw="$(trim "$raw")"
  # Extract first dotted numeric version like 5.4.12 from strings such as 'Nagios XI 5.4.12'
  if [[ "$raw" =~ ([0-9]+\.[0-9]+\.[0-9]+) ]]; then
    printf '%s' "${BASH_REMATCH[1]}"
    return 0
  fi
  return 1
}

vercomp() {
  # returns: 0 equal, 1 greater-than, 2 less-than
  if [[ "$1" == "$2" ]]; then
    return 0
  fi
  local IFS=.
  local i
  local -a v1=($1) v2=($2)
  for ((i=${#v1[@]}; i<${#v2[@]}; i++)); do v1[i]=0; done
  for ((i=${#v2[@]}; i<${#v1[@]}; i++)); do v2[i]=0; done
  for ((i=0; i<${#v1[@]}; i++)); do
    if ((10#${v1[i]} > 10#${v2[i]})); then
      return 1
    fi
    if ((10#${v1[i]} < 10#${v2[i]})); then
      return 2
    fi
  done
  return 0
}

version_in_range_inclusive() {
  local ver="$1" low="$2" high="$3"
  vercomp "$ver" "$low"; local c1=$?
  vercomp "$ver" "$high"; local c2=$?
  # ver >= low and ver <= high
  if [[ $c1 -eq 0 || $c1 -eq 1 ]]; then
    if [[ $c2 -eq 0 || $c2 -eq 2 ]]; then
      return 0
    fi
  fi
  return 1
}

if [[ ! -r "$VERSION_FILE" ]]; then
  echo "UNKNOWN: cannot read $VERSION_FILE"
  exit 2
fi

raw_version="$(head -n 1 "$VERSION_FILE" 2>/dev/null || true)"
if [[ -z "$raw_version" ]]; then
  echo "UNKNOWN: version file empty"
  exit 2
fi

if ! version="$(normalize_version "$raw_version")"; then
  echo "UNKNOWN: could not parse version from '$raw_version'"
  exit 2
fi

# NVD/OSV affected ranges:
#  - 5.2.0 through 5.2.9
#  - 5.4.0 through 5.4.12
if version_in_range_inclusive "$version" "5.2.0" "5.2.9"; then
  echo "VULNERABLE: Nagios XI $version matches affected range 5.2.0-5.2.9"
  exit 1
fi

if version_in_range_inclusive "$version" "5.4.0" "5.4.12"; then
  echo "VULNERABLE: Nagios XI $version matches affected range 5.4.0-5.4.12"
  exit 1
fi

# If version is 5.4.13 or later, or outside the listed affected ranges, treat as patched/not affected.
# If your package is vendor-backported or heavily customized, verify against your build records too.
echo "PATCHED: Nagios XI $version is outside the published affected ranges for CVE-2018-10737"
exit 0

Sources

1. NVD CVE-2018-10737
2. Nagios XI changelog
3. OSV record for CVE-2018-10737
4. OpenCVE record
5. GreyNoise scanning activity blog
6. Nagios XI product page
7. Nagios XI web interface architecture
8. Feedly CVE page noting Nuclei detection timeline