UniFi Protect EUVD-2026-66393

Exploitation requires network access to the UniFi Protect Application plus valid low-privileged credentials (CVSS PR:L) - it is not fully unauthenticated. No user interaction is needed (UI:N) and attack complexity is low (AC:L). The concrete prerequisite is an authenticated, low-privilege session to the Protect application through which the attacker can reach the input-handling code path that lacks proper validation; the vulnerable command is then executed on the host device. Limiting factors that reduce real-world risk: the attacker must already hold some account or obtain one, and the Protect management/API interface must be network-reachable, so deployments that segment the NVR onto a restricted management network and tightly control low-privilege accounts substantially raise the bar.

This is a genuine high-priority issue rather than an inflated CVSS number. The vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable, low-complexity attack that needs only low privileges and no user interaction, and the impact is complete compromise of the host (C:H/I:H/A:H) with a scope change to the underlying OS - the combination that drives the 9.9 score. The mitigating factor is the PR:L requirement: an attacker must first obtain some authenticated foothold, so exposure is highest where UniFi Protect management interfaces are reachable by many low-trust users or where the network is not segmented. EPSS and any SSVC automatability/exploitation determinations were not provided, and there is no KEV listing or public POC noted, which tempers the immediacy somewhat; however, given Ubiquiti's large installed base and the trivial technical impact, defenders should treat this as urgent even for smaller operators and patch promptly rather than wait for exploitation signals.

An attacker who has obtained a low-privileged UniFi Protect account - for example a limited camera-viewer login or a foothold on the same reachable network - submits crafted input to a Protect function that fails to validate it, causing the payload to be executed as an OS command on the host appliance. This yields command execution on the device itself, from which the attacker can pivot to the surveillance data, tamper with recordings, or use the appliance as a foothold into the network. No public proof-of-concept is currently known, but the low attack complexity means a working exploit would be straightforward to develop.