Armoury Crate CVE-2026-16003

Exploitation requires a local Windows user account with at least standard (low-privilege) access on a system where the Armoury Crate application and its kernel driver are installed and running - the driver must be present and active. The CVSS 4.0 AC:H rating indicates that crafting the correct IOCTL payload to bypass driver verification is non-trivial, likely requiring knowledge of the driver's internal interface (e.g., via reverse engineering). There is no network-accessible attack surface; remote exploitation is not possible without a prior foothold granting local code execution. The vulnerability has no impact on systems that do not have Armoury Crate installed, and the whitelist-bypass effect is bounded to the driver's own trust model - not a direct OS privilege escalation.

Real-world risk is low. The CVSS 4.0 vector AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N accurately captures the constrained attack surface: exploitation is local-only (not remotely accessible), requires a low-privilege account, and is rated AC:H - meaning non-trivial IOCTL crafting is required, likely involving reverse-engineering the driver interface. The integrity impact is VI:L (minor modification of the whitelist only), with no confidentiality or availability impact and no subsequent-system impact. There is no CISA KEV listing, no known public exploit code, and EPSS data is absent from the provided intelligence. The practical harm depends on what whitelisted processes are permitted to do beyond non-whitelisted ones - that scope is not enumerated in available data, making the worst-case impact difficult to bound. On managed enterprise endpoints or shared gaming kiosks, the whitelist bypass could serve as a stepping stone in a broader privilege escalation chain, but standalone it represents a low-priority finding.

A low-privilege local user on an ASUS gaming system reverse-engineers the Armoury Crate driver's IOCTL interface, identifies the whitelist-registration control code, and crafts a request that bypasses the driver's process verification check. Once their process is added to the driver's whitelist, they can issue further privileged IOCTL commands that the driver would reject for non-whitelisted callers, potentially manipulating hardware settings or accessing restricted driver functionality. No public exploit code has been identified at time of analysis, and the AC:H rating indicates the crafting step requires non-trivial effort.