Plesk contains an XPath injection vulnerability in the APS Application Catalog search functionality

CVE-2026-44962 is an XPath injection flaw in Plesk for Linux's APS Application Catalog search path. The vendor says low-privileged authenticated users can turn that bug into arbitrary OS command execution and local privilege escalation. Authoritative advisories point to vulnerable Linux builds prior to 18.0.75.1 and prior to 18.0.76.2, with fixes shipped on February 24-25, 2026; the workaround is to disable APS entirely in panel.ini.

The vendor's 9.9 CRITICAL score is technically understandable because the end-state is server-level compromise, but it overrates the real-world entry cost. This is not unauthenticated internet RCE: the attacker needs a valid Plesk account, the vulnerable APS feature must be reachable, and the component is already deprecated and headed for removal. That combination pushes this down from *internet emergency* to *serious tenant-to-root risk*.

Why this verdict

• Downgrade: requires authenticated remote access — vendor CVSS starts at 9.9, but PR:L means the attacker already has a valid Plesk foothold. That is a major friction point versus true perimeter RCE.
• Partial downgrade: feature-specific path — the bug lives in APS Catalog search, not in a universally hit panel route. Estates that disabled APS or never expose app management to customers cut the reachable population.
• Partial downgrade: deprecated component — APS Catalog is deprecated and scheduled for removal, which materially narrows the modern exposed population compared with core Plesk panel bugs.
• Upgrade pressure remains: tenant-to-host blast radius — if the vulnerable path is reachable, the stated impact is arbitrary OS command execution and LPE on the server. On shared hosting or MSP estates, one low-privileged account can become a multi-tenant incident.
• No exploitation pressure today — no KEV listing, no verified public campaign reporting, and a very low EPSS meaningfully reduce immediate emergency handling.

Why not higher?

Because the exploit chain starts with valid credentials. That prerequisite implies either prior compromise, insider access, or tenant access already exists, and each of those sharply narrows the attacker population compared with anonymous internet exploitation. The lack of KEV, low EPSS, no obvious public PoC, and the dying APS feature all keep this out of CRITICAL.

Why not lower?

Because once you are in, the impact is ugly: the vendor says a low-privileged authenticated user can reach arbitrary OS command execution and local privilege escalation. On internet-facing shared-hosting control planes, that is exactly the kind of bug that turns one customer account into full-host compromise, so treating it as routine backlog would be reckless.

1. Disable APS now — If you cannot upgrade immediately, apply the vendor workaround by setting [aps] enabled = off in /usr/local/psa/admin/conf/panel.ini and reload/restart the relevant Plesk services. For a HIGH verdict, deploy this control within 30 days; if the box is multi-tenant or customer-accessible, do it on the next change window, not at quarter-end.
2. Restrict panel access — Move 8443 behind VPN, SSO proxy, bastion, or IP allowlists so random internet users and commodity credential-stuffing never reach the login page. For a HIGH verdict, implement or tighten this within 30 days, prioritizing customer-exposed shared-hosting nodes first.
3. Enforce strong auth on Plesk accounts — Turn on MFA where available, rotate stale credentials, and review reseller/customer accounts with broad permissions. This directly attacks the main prerequisite — valid login — and should be completed within 30 days for exposed hosts.
4. Hunt for suspicious Plesk child processes — Create detections for shells, interpreters, package managers, downloaders, and cron/service changes spawned by Plesk web components. Roll this out within 30 days so you have post-exploitation visibility even if the panel bug is missed at the edge.
5. Prune customer app-management rights — Review service plans and subscription settings that expose Application Catalog functionality to customers and resellers. Where business use allows, remove or narrow access within 30 days to shrink the reachable population.

Run this on the target Plesk for Linux host as root or with sufficient privileges to read /usr/local/psa/admin/conf/panel.ini and execute Plesk CLI commands. Save it as check-cve-2026-44962.sh, then run sudo bash check-cve-2026-44962.sh; it reports VULNERABLE, PATCHED, or UNKNOWN based on installed Plesk version and whether the vendor workaround disables APS.

#!/usr/bin/env bash
# check-cve-2026-44962.sh
# Detects likely exposure to CVE-2026-44962 on Plesk for Linux.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

PANEL_INI="/usr/local/psa/admin/conf/panel.ini"
VERSION_FILE="/usr/local/psa/version"

get_version() {
  local v=""

  if [[ -r "$VERSION_FILE" ]]; then
    v=$(grep -Eo '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?' "$VERSION_FILE" | head -n1)
  fi

  if [[ -z "$v" ]] && command -v plesk >/dev/null 2>&1; then
    v=$(plesk version 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?' | head -n1)
  fi

  echo "$v"
}

aps_disabled() {
  [[ -r "$PANEL_INI" ]] || return 1
  awk '
    BEGIN { in_aps=0; disabled=0 }
    /^[[:space:]]*\[aps\][[:space:]]*$/ { in_aps=1; next }
    /^[[:space:]]*\[/ && $0 !~ /^[[:space:]]*\[aps\][[:space:]]*$/ { in_aps=0 }
    in_aps && /^[[:space:]]*enabled[[:space:]]*=[[:space:]]*off[[:space:]]*$/ { disabled=1 }
    END { exit(disabled ? 0 : 1) }
  ' "$PANEL_INI"
}

# Compare dotted versions. Returns 0 if $1 < $2
version_lt() {
  local IFS=.
  local i
  local -a a=($1) b=($2)

  for ((i=${#a[@]}; i<4; i++)); do a[i]=0; done
  for ((i=${#b[@]}; i<4; i++)); do b[i]=0; done

  for i in 0 1 2 3; do
    if ((10#${a[i]} < 10#${b[i]})); then return 0; fi
    if ((10#${a[i]} > 10#${b[i]})); then return 1; fi
  done
  return 1
}

version_ge() {
  ! version_lt "$1" "$2"
}

is_vulnerable_version() {
  local v="$1"

  # Advisory-fixed builds: 18.0.75.1 and 18.0.76.2
  # Vulnerable if:
  #  - any version < 18.0.75.1
  #  - 18.0.76.0 or 18.0.76.1
  #  - anything between 18.0.75.1 and 18.0.76.0 is treated as patched branch-wise
  if version_lt "$v" "18.0.75.1"; then
    return 0
  fi

  if version_ge "$v" "18.0.76.0" && version_lt "$v" "18.0.76.2"; then
    return 0
  fi

  return 1
}

main() {
  local version
  version=$(get_version)

  if [[ -z "$version" ]]; then
    echo "UNKNOWN"
    exit 2
  fi

  # Vendor workaround disables the vulnerable feature.
  if aps_disabled; then
    echo "PATCHED"
    exit 0
  fi

  if is_vulnerable_version "$version"; then
    echo "VULNERABLE"
    exit 1
  fi

  # Patched versions include 18.0.75.1+, 18.0.76.2+, and later branches.
  if version_ge "$version" "18.0.75.1"; then
    echo "PATCHED"
    exit 0
  fi

  echo "UNKNOWN"
  exit 2
}

main

Sources

1. NVD record for CVE-2026-44962
2. Plesk advisory for CVE-2026-44962
3. Plesk Obsidian change log
4. Canadian Centre for Cyber Security advisory AV26-534
5. Plesk docs: How Apps Become Available to Your Customers
6. Plesk docs: Ports Used by Plesk
7. Plesk KB noting APS Catalog deprecation/removal
8. Bitsight public Plesk Obsidian footprint page