Acronis DeviceLock DLP CVE-2026-44682

Exploitation requires the attacker to already have local, interactive code execution on the Windows endpoint as a low-privileged user (PR:L), write access to a directory that appears earlier in the DLL search order than the legitimate system path for the targeted DeviceLock executable, and a victim action that launches or re-launches the vulnerable DeviceLock DLP process (UI:R) - the agent service itself does not auto-trigger the chain without that interaction. Exploitation is limited to Windows endpoints running Acronis DeviceLock DLP at a build below 9.0.15051.93227; fully patched builds, non-Windows endpoints, and hardened deployments where DeviceLock binaries and their working directories are not user-writable are not exploitable. Remote, network-based exploitation is not in scope (AV:L).

The CVSS 3.0 vector AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H gives a base score of 7.3 (High) and is internally consistent with a local DLL hijacking primitive: local attack vector, low complexity, low privileges already held, and required user interaction (a victim must launch or trigger the vulnerable process). Real-world risk is moderate rather than critical - no public exploit identified at time of analysis, the CVE is not in CISA KEV, and no EPSS or SSVC data was supplied, so there is no signal of widespread or automated exploitation. The dependence on UI:R and pre-existing local foothold means this is most relevant as a post-compromise escalation primitive on managed endpoints (e.g., a malware operator escalating from a standard user to SYSTEM via the DLP agent) rather than a remote mass-exploitation threat. Note that EPSS and KEV are both unavailable in the input, so prioritization should be made on architectural exposure (how many endpoints run DeviceLock DLP) rather than on observed-exploitation telemetry.

A local standard user (or malware running in that user's session) drops a malicious DLL with a name that a DeviceLock DLP executable loads without a fully qualified path into a directory that wins the Windows DLL search order - for example the application's current working directory or a writable PATH entry. The user is then induced to launch the affected DeviceLock component (UI:R), at which point the planted DLL is mapped into the higher-privileged process and the attacker's code runs with that process's privileges, typically SYSTEM. No public exploit identified at time of analysis, but DLL-hijacking primitives in widely deployed endpoint agents are commonly weaponized by post-exploitation tooling once details become public.