Is CVE-2023-47565 (QNAP VioStor NVR OS Command Injection) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2023-47565 to its Known Exploited Vulnerabilities catalogue on 21 December 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. QNAP VioStar NVR contains an OS command injection vulnerability that allows authenticated users to execute commands via a network. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this CVE

For this case, the practical answer is not just that the vulnerability exists, but that defenders should assume real attacker activity. CISA’s KEV listing is the key signal: once a CVE is added there, it has crossed the threshold from theoretical exposure to confirmed exploitation evidence, so inventory and remediation decisions should move to incident-response pace rather than normal patch cadence.

That matters because OS command injection changes the risk profile of the affected appliance. If an authenticated attacker can reach the vulnerable function, they may be able to run operating-system commands on the device itself, turning a management interface weakness into potential device takeover, configuration tampering, and a foothold for further network activity.

For the most reliable external references on this question, use CISA Known Exploited Vulnerabilities Catalog for exploitation status and CVE Program records for the canonical vulnerability entry.

Why command injection on a network appliance is operationally serious

Network video recorder platforms sit at a sensitive boundary: they often manage cameras, store footage, and expose administrative functions over the network. When an authenticated user can inject operating-system commands, the issue is not limited to application logic. It can become an infrastructure-level problem if the appliance holds credentials, configuration data, or trusted access to adjacent systems.

Command injection also tends to be high impact because it often bypasses the intended safety of normal application features. An attacker does not need a separate malware implant if the product itself can be induced to execute commands. That makes detection harder, because malicious activity may resemble legitimate administrative or maintenance behaviour until logs, command traces, or unexpected outbound connections are reviewed.

If you want a broader practitioner view of this class of issue, Web Application Attacks Guide covers command injection patterns and the defensive logic behind input handling and exploitation paths.

What to do when the product is in scope

First confirm whether the appliance exists anywhere in your environment, including forgotten sites, remote branches, and vendor-managed deployments. For KEV-listed issues, the important question is not whether the device is internet-facing today, but whether it is reachable by any authenticated account or administrative workflow that could touch the vulnerable function.

Then treat vendor remediation guidance as the source of truth for version-specific action. In practice, the safe sequence is to isolate exposure, apply the vendor fix or mitigation, and verify that the vulnerable management path is no longer reachable under normal credentials. If immediate patching is not possible, reduce access to the management interface as tightly as you can and assume the device remains a priority asset until it is remediated.

For teams that need a repeatable triage process, Vulnerability Management Guide is the best internal companion for KEV prioritisation, exception handling, and verification discipline.

Risk and Threat Considerations

The main risk is not simply that the flaw is public, but that active exploitation turns a product weakness into a live compromise path. If an attacker can reach the vulnerable function with valid access, command execution may give them a stable foothold on a device that is usually trusted by administrators and often insufficiently monitored.

Failure mechanism: Authenticated command injection can let an attacker translate application access into operating-system execution, which may enable configuration changes, data access, persistence, or lateral movement from the appliance into the wider network.

Impact: Organisations may face loss of appliance integrity, exposure of stored or transient data, service disruption, and a higher chance that the device becomes an initial access point for broader compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation requires fast prioritisation and verified remediation.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Appliance exposure often persists through weak hardening and management access.
Recommendation — Prioritise and track this KEV vulnerability through continuous vulnerability management. Harden management interfaces and reduce exposed appliance attack surface.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Command injection on a network-facing management interface matches exploitation of an exposed service.
Recommendation — Map exploitation activity to T1190 and hunt for signs of command execution abuse.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	KEV status makes timely flaw remediation the central defensive action.
	CM-7 — Least Functionality	Reducing available management functions limits the blast radius of command injection.
Recommendation — Accelerate flaw remediation for KEV-listed appliances and verify completion. Disable unnecessary appliance functions and services to reduce exploitable surface.

Practitioner Guidance

What to prioritise: Treat the appliance as urgent if it is deployed anywhere that still matters operationally. A KEV-listed command-injection issue should jump ahead of routine backlog work, especially when the system is externally reachable, administratively shared, or difficult to monitor.

What to verify: Confirm whether the device has been exposed to untrusted users, whether admin credentials were shared broadly, and whether logs show unusual command execution, reconfiguration, or unexpected outbound traffic around the period of likely exposure.

Decision rule: If patching must wait, restrict administrative access immediately and assume compromise assessment is warranted before you rely on the appliance for normal operations. If there is any evidence of suspicious behaviour, preserve logs and artefacts before making disruptive changes.

Practitioner takeaway: For KEV-listed command injection, the right posture is not “patch when convenient”, it is “treat as actively exploited until proven otherwise and verify the appliance was not already used as a foothold.”

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org