A janitor with a master key can flip the breaker — but only the janitor can
CVE-2026-24716 is a NULL pointer dereference (CWE-476) in QNAP's QTS and QuTS hero operating systems. An attacker who already holds a valid administrator account can send a crafted request over the network that causes an unchecked pointer to be dereferenced, crashing the affected service and triggering a denial of service on the NAS. Affected builds include QTS prior to 5.2.9.3492 build 20260507, QuTS hero h5.2.9.3499 build 20260514, h5.3.4.3500 build 20260520, and h6.0.0.3459 build 20260409. There is no evidence of memory-corruption exploitation beyond a crash — the impact ceiling is availability loss, not RCE.
The vendor rating of HIGH (7.2, CVSS 3.1 AV:N/AC:L/PR:H/UI:N/C:H/I:H/A:H) does not survive scrutiny. C:H and I:H are aspirational — a NULL-deref bug that panics a service does not by itself yield confidentiality or integrity loss; the honest impact triad is C:N/I:N/A:H. Combined with PR:H (admin required), the real-world CVSS closer to 5.1 MEDIUM — which is exactly where the CVSS 4.0 recalculation lands. Vendor severity is inflated; treat this as a Medium availability bug.
3 steps from start to impact.
Obtain valid QNAP administrator credentials
PR:H — a fully privileged admin account on the target NAS. The attacker must either compromise an existing admin (phishing, credential reuse, prior breach) or leverage a separate authentication bypass. Public NAS admin panels without MFA and default admin accounts are the historical vector.- Admin credentials or session token for target QNAP device
- Network reachability to the management interface (HTTP/HTTPS/QTS web UI)
- Post-2021 QNAP campaigns (Qlocker, DeadBolt) drove most enterprises to disable admin default accounts and enforce 2FA
- Management interfaces should not be internet-facing; myQNAPcloud tunnels are the more common exposure path
/var/log from QTS is uncommon in enterprise fleets.Send crafted request to vulnerable service endpoint
curl with authenticated session cookie, or a small Python PoC once details land on GitHub.- Authenticated session established
- Knowledge of the vulnerable endpoint (not publicly detailed)
- No public PoC as of assessment date
- Reverse-engineering QTS firmware to locate the sink is nontrivial
Service crash → denial of service
- Vulnerable code path reached
- QNAP HA pairs (QuTS hero clusters) may failover; single-node QTS deployments will hang
The supporting signals.
| In-the-wild exploitation | None observed. No campaigns tied to CVE-2026-24716 as of 2026-07-01. |
|---|---|
| Proof-of-concept | No public PoC on GitHub, Exploit-DB, or Packet Storm at time of assessment. |
| EPSS | 0.00331 (~0.3%) — bottom quartile of exploitation likelihood. |
| KEV status | Not listed on CISA KEV. |
| CVSS 3.1 vector (vendor) | AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H → 7.2 HIGH. C:H/I:H are questionable for a NULL-deref DoS. |
| CVSS 4.0 (revised) | 5.1 MEDIUM per vuldb — more honest given availability-only impact. |
| Affected products | QNAP QTS < 5.2.9.3492 (20260507); QuTS hero h5.2.9.3499 (20260514), h5.3.4.3500 (20260520), h6.0.0.3459 (20260409) |
| Fixed versions | QTS 5.2.9.3492 build 20260507+; QuTS hero h5.2.9.3499 build 20260514+, h5.3.4.3500 build 20260520+, h6.0.0.3459 build 20260409+ |
| Internet exposure | Shodan historically shows ~200K–300K QNAP devices exposed to the internet, though admin UI exposure is a subset. Management-plane-only bug limits reachable population. |
| Advisory / disclosure | QNAP Security Advisory QSA-26-18, disclosed 2026-06-10. |
noisgate verdict.
The single decisive factor is the impact ceiling: authenticated-admin denial-of-service only, with no code execution and no data exposure path. Vendor CVSS 3.1 mislabels C:H/I:H for what is fundamentally an availability crash, and QNAP's own CVSS 4.0 recalculation agrees at 5.1 Medium.
Why this verdict
- Impact is availability-only. A NULL-pointer dereference triggers a crash. Vendor's C:H/I:H claims are inflated; real-world triad is C:N/I:N/A:H. This alone removes ~2 CVSS points.
- PR:H gate is real. The attacker must already hold admin. On a NAS, admin already means data access — the vulnerability grants nothing an admin does not already have except the ability to crash their own box.
- No PoC, EPSS 0.3%, not on KEV. No public exploitation code, no campaigns, no CISA attention. Compare against actively exploited QNAP bugs (DeadBolt, Qlocker) which were pre-auth or auth-bypass — this is not that class.
- Role multiplier — NAS as bulk storage / backup target: Chain succeeds → the DoS impact tops out at a single-device outage or, on backup-role NAS, temporary loss of backup availability. Since the bug requires admin credentials, an attacker who has those already owns the data; adding a crash is redundant. Blast radius is single-appliance, not fleet. Role multiplier does NOT push floor above MEDIUM — DoS by an already-admin does not compound.
- Vendor CVSS 4.0 recalc confirms MEDIUM. QNAP's own CVSS 4.0 score is 5.1 — vendor implicitly agrees the 3.1 rating was too high.
Why not higher?
HIGH would require either pre-auth reachability or an impact beyond DoS (RCE, data disclosure, cluster-wide effect). Neither is present: PR:H is a hard gate confirmed by the advisory, and NULL-deref semantics cap impact at a crash. Even on a canonical backup-role deployment, an attacker with admin already owns the data — DoS adds nothing meaningful.
Why not lower?
LOW would require either no realistic exploitation path or trivial recovery. QNAP admin credential theft is a documented attacker technique (see prior ransomware campaigns), the NAS is often a critical storage tier, and a crash can force reboots that disrupt file services enterprise-wide. That earns a MEDIUM floor, not LOW.
What to do — in priority order.
- Remove QNAP admin UI from internet exposure — Bind the management interface to an internal VLAN or VPN-only reachability. This addresses the entire QNAP-external-attack class, not just this CVE. No mitigation SLA for MEDIUM — treat as hygiene, but complete within the 365-day remediation window.
- Enforce 2FA on all QNAP administrator accounts — Enable Control Panel → System → Security → 2-Step Verification for every admin. Raises the PR:H gate meaningfully by preventing credential-reuse takeovers. Roll out across fleet within 90 days.
- Disable the default
adminaccount and rename all admin users — Historical QNAP campaigns rely on default account names. Rename admin users and disable the built-in account to defeat credential-stuffing attempts. - Apply the QSA-26-18 firmware patch during standard maintenance window — Update to QTS 5.2.9.3492 build 20260507+ or the matching QuTS hero build. noisgate remediation SLA for MEDIUM: ≤ 365 days. No mitigation SLA — go straight to the standard remediation window.
- Network IPS signatures — the bug is authenticated and the endpoint is not publicly detailed; no reliable signature exists.
- WAF rules — with no known malicious pattern and TLS-terminated admin sessions, WAF adds no meaningful coverage.
- Rate limiting on the admin API — an admin can crash the service with a single crafted call; volumetric controls do not apply.
Crowdsourced verification payload.
Run this on an auditor workstation or a monitoring host that can SSH into the QNAP as an authorized admin (bash check_qnap.sh <nas-host> <admin-user>). Requires SSH access and an admin credential; the script reads /etc/config/uLinux.conf and QTS version files to compare against fixed builds. Output: VULNERABLE / PATCHED / UNKNOWN.
#!/usr/bin/env bash
# noisgate verifier — CVE-2026-24716 (QNAP QTS / QuTS hero NULL-deref DoS)
# Usage: ./check_qnap.sh <nas-host> <admin-user>
set -u
HOST="${1:-}"
USER="${2:-admin}"
if [ -z "$HOST" ]; then
echo "Usage: $0 <nas-host> <admin-user>"; exit 2
fi
# Pull version + build from QNAP over SSH
INFO=$(ssh -o BatchMode=no -o ConnectTimeout=10 "$USER@$HOST" \
'getcfg System Version 2>/dev/null; echo ---; getcfg System "Build Number" 2>/dev/null; echo ---; uname -a' 2>/dev/null)
if [ -z "$INFO" ]; then
echo "UNKNOWN — could not read version info from $HOST"; exit 3
fi
VER=$(echo "$INFO" | sed -n '1p')
BUILD=$(echo "$INFO" | sed -n '3p')
UNAME=$(echo "$INFO" | sed -n '5p')
echo "Host: $HOST"
echo "Version: $VER"
echo "Build: $BUILD"
echo "Kernel: $UNAME"
# Determine product family
FAMILY="QTS"
if echo "$UNAME $VER" | grep -qi 'hero\|h5\.\|h6\.'; then FAMILY="QuTS hero"; fi
# Compare build date (YYYYMMDD embedded in build) against fix thresholds
BDATE=$(echo "$BUILD" | grep -oE '20[0-9]{6}' | head -1)
if [ -z "$BDATE" ]; then echo "UNKNOWN — no build date parsed"; exit 3; fi
case "$FAMILY|$VER" in
QTS|5.2.9.*) FIX=20260507 ;;
"QuTS hero"|h5.2.9.*) FIX=20260514 ;;
"QuTS hero"|h5.3.4.*) FIX=20260520 ;;
"QuTS hero"|h6.0.0.*) FIX=20260409 ;;
*) echo "UNKNOWN — unrecognized version stream ($FAMILY $VER)"; exit 3 ;;
esac
if [ "$BDATE" -ge "$FIX" ]; then
echo "PATCHED (build $BDATE >= fix $FIX for $FAMILY $VER)"; exit 0
else
echo "VULNERABLE (build $BDATE < fix $FIX for $FAMILY $VER)"; exit 1
fi
If you remember one thing.
admin username — those actions retire an entire class of QNAP risk, not just this CVE.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.