A command injection vulnerability has been reported to affect several QNAP operating system versions

CVE-2026-24719 is an OS command injection (CWE-78) in QNAP's QTS and QuTS hero NAS operating systems. An authenticated user with an administrator account can inject shell metacharacters into a management endpoint and execute arbitrary commands as the underlying OS user — typically leading to full NAS takeover, data exfiltration, and a ransomware staging point. Affected builds are everything prior to QTS 5.2.9.3492 build 20260507 and QuTS hero h5.2.9.3499 build 20260514; QNAP tracks it as advisory QSA-26-23.

The vendor's HIGH / 7.2 rating is defensible but overstated for the typical fleet operator. The CVSS vector PR:H correctly reflects that you need admin creds to reach the sink, but 7.2 still treats an admin-authenticated command exec as almost as bad as an unauth RCE. In practice, an attacker who already holds NAS admin credentials can already schedule shell tasks, mount shares, deploy container apps, and read every file — this bug adds a marginally cleaner code-exec primitive, not a new capability. Real severity sits in the mid-MEDIUM band unless the NAS is internet-exposed with weak admin creds, in which case it becomes a ransomware accelerator.

Why this verdict

• Auth prerequisite dominates: PR:H means the attacker already owns the admin console — the bug is a capability duplication, not a capability grant. Adjustment: −1.5 from vendor 7.2.
• Role multiplier — typical role (LOB NAS / file share): Chain succeeds and yields root on the appliance, but blast radius is host-scoped to the NAS and its shares. Not fleet-scale, not identity-scale. No upward pressure.
• Role multiplier — high-value role (backup target / immutable repo): If the NAS is designated as a backup target and lacks S3 Object Lock or hardened-repo semantics, ransomware post-exploitation is catastrophic. This is a real risk cluster but only ~5–10% of enterprise QNAP deployments serve as primary backup — sets a floor of HIGH ONLY for those units, not the fleet as a whole.
• Population data: EPSS 0.00977 and no KEV listing indicate no observed mass exploitation. Historical QNAP ransomware waves (DeadBolt, Qlocker, eCh0raix) required unauth or default-credential paths — this one does not.
• Friction stack: AutoBlock brute-force lockout, myQNAPcloud 2FA on admin, and mature shops firewalling the admin UI all compound to shrink the exploitable population well below 1% of installs.

Why not higher?

Not HIGH because the PR:H prerequisite means an attacker who can exploit this already possesses the equivalent of the exploit's payoff — namely, root-equivalent control of the NAS via legitimate admin APIs. Zero KEV signal and near-floor EPSS confirm this is not being weaponized at scale. The typical deployment role (file/app NAS) caps blast radius at the appliance itself.

Why not lower?

Not LOW because when the NAS is a backup target or holds regulated data, root-level command execution turns a stolen admin cred into a full-fleet recovery-plane compromise — the exact scenario DeadBolt and Qlocker exploited on QNAP historically. QNAP appliances also sit outside EDR/agent coverage, so post-exploitation is silent. That role-tail risk keeps this above LOW.

1. Remove QNAP admin UIs from the public internet — Put QTS/QuTS hero web management behind a VPN or admin-only VLAN. This collapses the credential-stuffing attack surface to zero. Given the MEDIUM verdict there is no noisgate mitigation SLA, but treat this as backlog hygiene — complete within the 365-day remediation window; sooner if any unit is currently internet-exposed.
2. Enforce 2FA on all administrator accounts — Enable QNAP's built-in two-step verification for every account in the administrators group via Control Panel → Users. This neutralizes credential reuse as an entry vector for step 1 of the chain.
3. Rotate any admin credential shared with SaaS or dev tooling — If NAS admin creds were ever placed in scripts, backup jobs, or password managers accessed by developers, rotate them now. Any reused credential collapses the PR:H friction.
4. Verify AutoBlock and access-log alerting are on — Control Panel → System → Security → IP Access Protection: enable SSH/HTTP(S) autoblock at ≤5 failed logins within 5 min. Ship QuLog Center syslog to your SIEM with alerts on admin-account logins from unexpected sources.
5. Confirm backup-target NAS units are on immutable storage semantics — For any QNAP acting as a backup repository, require Veeam hardened repo mode, S3 Object Lock on QuObjects, or WORM snapshots. This breaks the ransomware pivot even if step 3 lands.

Run this on the target QNAP appliance via SSH as admin (or via QNAP's Malware Remover shell). Invoke as ./check_cve_2026_24719.sh. No arguments needed. Requires read access to /etc/config/uLinux.conf and the getcfg utility present in every QTS/QuTS hero build.

#!/bin/sh
# noisgate verification script for CVE-2026-24719
# Target: QNAP QTS / QuTS hero appliances
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -u

CONF=/etc/config/uLinux.conf
if [ ! -r "$CONF" ]; then
  echo "UNKNOWN: cannot read $CONF (are you root/admin on a QNAP unit?)"
  exit 2
fi

GETCFG="$(command -v getcfg || echo /sbin/getcfg)"
if [ ! -x "$GETCFG" ]; then
  echo "UNKNOWN: getcfg not found; this may not be a QNAP appliance"
  exit 2
fi

MODEL=$("$GETCFG" System "Model" -f "$CONF" 2>/dev/null)
VER=$("$GETCFG" System Version -f "$CONF" 2>/dev/null)
BUILD=$("$GETCFG" System "Build Number" -f "$CONF" 2>/dev/null)

if [ -z "$VER" ] || [ -z "$BUILD" ]; then
  echo "UNKNOWN: could not parse Version/Build from $CONF"
  exit 2
fi

# Detect QuTS hero vs QTS: QuTS hero versions start with 'h' or the platform config marks it
is_hero=0
if echo "$VER" | grep -qi '^h'; then is_hero=1; fi
if [ -f /etc/hero_release ] || [ -f /etc/quts_release ]; then is_hero=1; fi

# Normalize version (strip leading h)
NVER=$(echo "$VER" | sed 's/^[hH]//')

# Fixed thresholds per QSA-26-23
# QTS:       5.2.9.3492 / build 20260507
# QuTS hero: 5.2.9.3499 / build 20260514
if [ "$is_hero" = "1" ]; then
  FIXED_VER="5.2.9.3499"
  FIXED_BUILD="20260514"
  BRANCH="QuTS hero"
else
  FIXED_VER="5.2.9.3492"
  FIXED_BUILD="20260507"
  BRANCH="QTS"
fi

ver_ge() {
  # returns 0 if $1 >= $2 using dotted numeric compare
  awk -v a="$1" -v b="$2" 'BEGIN{
    n=split(a,A,"."); split(b,B,".");
    for(i=1;i<=n;i++){ ai=A[i]+0; bi=B[i]+0; if(ai>bi)exit 0; if(ai<bi)exit 1 }
    exit 0
  }'
}

echo "Model:  ${MODEL:-unknown}"
echo "Branch: $BRANCH"
echo "Version: $VER  Build: $BUILD"
echo "Fixed:  $FIXED_VER build $FIXED_BUILD"

if ver_ge "$NVER" "$FIXED_VER"; then
  if [ "$NVER" = "$FIXED_VER" ]; then
    if [ "$BUILD" -ge "$FIXED_BUILD" ] 2>/dev/null; then
      echo "PATCHED"; exit 0
    else
      echo "VULNERABLE (version matches but build $BUILD < $FIXED_BUILD)"; exit 1
    fi
  else
    echo "PATCHED"; exit 0
  fi
else
  echo "VULNERABLE ($BRANCH $NVER < $FIXED_VER)"; exit 1
fi

Sources

1. NVD — CVE-2026-24719
2. QNAP Security Advisory QSA-26-23 (advisory index)
3. Vulnerability-Lookup (CIRCL) — CVE-2026-24719
4. VulDB — CVE-2026-24719 (QSA-26-23 / EUVD-2026-35977)
5. Tenable / Nessus plugin — TENABLE_OT_QNAP_CVE-2026-24719
6. THREATINT — CVE-2026-24719
7. GHSA-8fh7-4j6j-cx8g
8. Notebookcheck — QNAP fixes 14 NAS security flaws