Axis OS CVE-2026-5304

Exploitation requires both of the following preconditions to be true simultaneously: (1) the target Axis device must be explicitly configured to permit installation of unsigned ACAP applications - this is a non-default or operator-enabled setting that must be actively turned on - and (2) the attacker must successfully socially engineer a user with device management privileges (PR:H per CVSS) into installing the malicious ACAP application (UI:R per CVSS). High attack complexity (AC:H) reflects the requirement for these two independent conditions to align. The vulnerability does not affect availability (A:N). Environments that enforce ACAP application code-signing and do not permit unsigned application installation are not exposed to this vulnerability regardless of Axis OS version.

The CVSS 3.1 base score of 5.7 (AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N) accurately reflects a tightly constrained exploitation window. Three compounding prerequisites - non-default device configuration, high attacker privilege (reaching an admin-level user), and successful social engineering - must all align simultaneously. Even a mid-sized municipal IT team in swidnica should treat this as a lower-urgency issue compared to unauthenticated, low-complexity network flaws, provided they enforce ACAP code-signing policy on their Axis deployments. No EPSS score was available in the provided data, and the absence of KEV listing further supports deprioritization for most operators. The C:H/I:H impact metrics are real and significant if exploitation succeeds, but the AC:H/PR:H/UI:R combination makes opportunistic mass exploitation implausible. The primary risk vector is a targeted insider threat or spear-phishing campaign aimed at a device administrator in an environment where unsigned ACAP installation has been enabled.

An attacker targeting an organization using Axis surveillance hardware first identifies a device configured to accept unsigned ACAP applications, then crafts a malicious ACAP package whose configuration file contains unsanitized input designed to trigger privilege escalation when parsed. The attacker delivers the package via a phishing email or spoofed trusted source and persuades a device administrator to install it through the management interface, at which point the malicious configuration is processed and the attacker gains elevated privileges on the device. No public exploit code has been identified at time of analysis.