CVE-2026-42061: Local Privilege Escalation in Acronis DeviceLock DLP
| Field | Value |
|---|---|
| CVE ID | CVE-2026-42061 |
| CVSS score | 7.3 |
| Attack vector | Local |
| Auth required | Unknown from available source data; defenders should assume an attacker needs local code execution or local access first |
| Patch status | Fixed in build 9.0.15051.93227 or later |
TL;DR - Acronis DeviceLock DLP for Windows before build 9.0.15051.93227 has a local privilege escalation flaw. - Upgrade affected Windows hosts to build 9.0.15051.93227 or later and hunt for suspicious child-process launches. - No confirmed in-the-wild exploitation or public PoC was identified, but post-compromise risk is significant.
What this vulnerability is and why it matters
CVE-2026-42061 is a local privilege escalation vulnerability in Acronis DeviceLock DLP for Windows. The NVD description attributes the issue to excessive permissions assigned to child processes. The confirmed affected range is Acronis DeviceLock DLP (Windows) before build 9.0.15051.93227, and the fixed boundary is build 9.0.15051.93227 or later.
For defenders, the practical implication is straightforward: this is not an internet-facing remote code execution bug, but it can be highly useful to an attacker after initial access. If an attacker already has a foothold on a Windows endpoint where DeviceLock DLP is installed, a privilege escalation path can turn a limited user context into a more powerful one. That can enable credential access, tampering with security controls, persistence, or broader movement inside the environment.
A 7.3 CVSS score places this in serious territory even without evidence of active exploitation. Local privilege escalation flaws are often chained with phishing, malware delivery, weak endpoint hygiene, or other initial foothold techniques. In environments where DeviceLock DLP is present on regulated or sensitive user workstations, the risk is not just host takeover but also potential interference with data loss prevention enforcement and endpoint policy controls.
The exact CVSS vector string was not available in the source material provided, so it should not be quoted or inferred here. Likewise, the available data does not definitively state the exact privilege requirement value in CVSS terms. In the absence of that detail, defenders should assume a realistic post-compromise scenario: an attacker can already run code locally as a standard or otherwise constrained user and is attempting to elevate.
Exploitation status: what is known and what is not
At the time of this write-up, there is no confirmed in-the-wild exploitation from the sources provided. Specifically, the CVE is not listed in the CISA Known Exploited Vulnerabilities catalog, which means there is no CISA-confirmed evidence of active exploitation reflected through KEV as of 2026-06-03.
There is also no public proof of concept identified in the retrieved source set. No GitHub exploit repository, public exploit write-up, or vendor-published exploit details were available in the research note. That does not prove exploit code does not exist; it means defenders should avoid both extremes: do not dismiss the issue because no public PoC was found, and do not claim active exploitation without evidence.
The right operational stance is to classify this as a high-priority post-compromise hardening and patching issue. Local privilege escalation flaws become more dangerous when paired with malware that already runs under user context, commodity infostealers, or hands-on-keyboard access following phishing or stolen credentials. If your organization has recent indicators of endpoint compromise, this CVE should move up the queue because it can help an attacker deepen access.
In short: - Exploitation confirmed in the wild: No confirmed evidence from available sources - Public PoC exists: None identified from available sources - Neither known: Yes, based on current evidence
Affected versions and exposure assessment
The affected product and version boundary are specific: Acronis DeviceLock DLP (Windows) before build 9.0.15051.93227. The fixed version is build 9.0.15051.93227 or later. If you run any earlier build in the 9.0 train, you should treat the host as exposed until verified otherwise.
Because the advisory body was not directly retrievable in this research context, there is no responsible basis for naming additional affected branches, alternate product lines, or non-Windows editions. That matters operationally: do not over-scope and trigger unnecessary emergency changes in unrelated Acronis products. Focus your inventory and patch validation on Windows systems with Acronis DeviceLock DLP installed.
For many organizations, the first challenge will be version discovery. DLP and endpoint-control products are sometimes deployed through centralized management, but the installed build on the endpoint may lag behind what administrators expect. Confirm exposure using both central console inventory and local endpoint inspection. If those sources disagree, trust the endpoint until proven otherwise, because an unpatched local agent is what an attacker can exploit.
If your environment contains jump boxes, VDI pools, kiosk systems, or privileged admin workstations with DeviceLock DLP installed, prioritize them higher than ordinary desktops. A local privilege escalation on a workstation used by administrators or support staff can have an outsized impact, especially if that host has cached credentials, privileged tokens, or management tooling.
Technical Notes
Use PowerShell to identify installed Acronis DeviceLock DLP software and capture version details from endpoints:
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object { $_.DisplayName -match "DeviceLock|Acronis" } |
Select-Object DisplayName, DisplayVersion, Publisher, InstallDate
On 64-bit systems, also check the WOW6432Node path if needed:
Get-ItemProperty HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object { $_.DisplayName -match "DeviceLock|Acronis" } |
Select-Object DisplayName, DisplayVersion, Publisher, InstallDate
If you rely on software inventory from EDR or CMDB, query for version strings lower than the fixed build. Exact packaging and display formats can vary, so normalize build values before reporting compliance.
Technical impact and defender takeaways
The confirmed root cause is excessive permissions assigned to child processes. That is enough to infer the broad risk pattern without inventing internals. When a privileged service or security product launches a child process with overly broad rights, the child can become the weak link that allows lower-privileged code to cross a trust boundary.
In enterprise practice, those flaws can be especially dangerous because security and DLP products often run with elevated service privileges and broad OS access. If an attacker can influence or abuse one of those child processes, the result may be administrative or system-level execution. That can in turn enable disabling controls, modifying policy enforcement, or accessing sensitive system areas that would otherwise be blocked.
For blue teams, the key takeaway is not just “patch the CVE.” It is also “treat security-agent child-process behavior as high-signal telemetry.” Unexpected shelling out, script execution, or LOLBin spawning from endpoint security or DLP components deserves review whether or not it maps to this CVE specifically.
Finally, because exploitation and PoC status are currently unconfirmed from the available evidence, organizations should avoid panic but not complacency. Patch on a priority basis, hunt for suspicious process ancestry on DeviceLock-enabled endpoints, and assume that any endpoint compromise on an unpatched host could become more severe if this privilege escalation path is available.
Additional Resources
For further reading on related topics, you may find the following articles useful: - What Does a SOC Do? - Build a Cybersecurity Homelab for Detection Practice
Detection and hunting guidance
Detection for this CVE is inherently behavior-driven because the public description does not include a detailed exploit sequence. Since the root cause involves excessive permissions assigned to child processes, defenders should focus on unexpected child processes launched by Acronis DeviceLock DLP components, followed by privilege changes, token abuse, or suspicious execution ancestry.
Start with process telemetry on hosts running DeviceLock DLP. Review parent-child process chains involving DeviceLock-related binaries or services. You are looking for child processes that should not normally be spawned, especially shell interpreters, script engines, LOLBins, or admin utilities. Even if the vulnerable mechanism is not fully documented publicly, anomalous child-process behavior from security tooling is worth investigation on its own.
Next, correlate process creation with security event logs that indicate elevated token assignment, service manipulation, or security-sensitive object access. A successful local privilege escalation often leaves surrounding evidence even when the exact exploit primitive is not obvious. On Windows, useful sources include Sysmon Event ID 1, Security 4688 process creation, service installation/modification events, and EDR lineage analysis.
Because exploitation is not confirmed and no PoC is public in the material provided, there is no authoritative exploit signature to publish. In the absence of exploit-specific telemetry, assume defenders should baseline normal DeviceLock DLP behavior and alert on deviations, especially on hosts with recent phishing, malware, or suspicious interactive logons.
Technical Notes
Example Windows Security log pattern for suspicious child processes:
Event ID: 4688
ParentProcessName: *DeviceLock* OR *Acronis*
NewProcessName: cmd.exe OR powershell.exe OR wscript.exe OR cscript.exe OR rundll32.exe OR regsvr32.exe
TokenElevationType: %%1936 OR %%1937
Example Sysmon-style hunt logic:
EventID=1
ParentImage contains "DeviceLock" OR ParentImage contains "Acronis"
Image IN ("C:\Windows\System32\cmd.exe",
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe",
"C:\Windows\System32\wscript.exe",
"C:\Windows\System32\cscript.exe",
"C:\Windows\System32\rundll32.exe",
"C:\Windows\System32\regsvr32.exe")
Example Microsoft Defender Advanced Hunting query:
DeviceProcessEvents
| where InitiatingProcessFileName has_any ("DeviceLock", "Acronis")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName
If your EDR does not expose parent image names cleanly, hunt for unusual descendants of DeviceLock services by process tree and integrity level transitions.
Mitigation and patching
The primary mitigation is to upgrade Acronis DeviceLock DLP for Windows to build 9.0.15051.93227 or later. That is the only confirmed fix threshold from the available source material. If you operate through centralized software deployment, validate not only package publication but successful endpoint rollout, because local privilege escalation risk remains until the vulnerable build is actually replaced on the host.
No vendor workaround was confirmed in the provided data. When a workaround is unknown, defenders should say so plainly and shift to compensating controls. In this case, compensating measures include limiting local logon rights, restricting user ability to execute arbitrary code, tightening application control, monitoring DeviceLock child-process behavior, and prioritizing patching on systems exposed to untrusted users or high-risk browsing and email activity.
If you cannot patch immediately, reduce the value of the vulnerability to an attacker by hardening endpoints against user-context code execution. WDAC, AppLocker, attack surface reduction rules, and strict local admin controls all help. This CVE is local, so every control that makes local execution harder or limits post-exploitation freedom reduces practical risk.
After patching, verify with version checks, process inventory, and software reporting. Do not close the ticket solely on the basis of a maintenance window or deployment job success. For security tooling, partial upgrade states and stale agents are common.
Technical Notes
If the product is deployed through an enterprise software management platform, use your standard package upgrade workflow to push the vendor-supplied fixed build. Where a local installer is used, a silent MSI-style pattern may apply, but the exact package name and switches were not confirmed in the source data and should not be guessed.
What defenders can do immediately is verify and document the installed build with PowerShell:
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object { $_.DisplayName -match "DeviceLock|Acronis" } |
Select-Object DisplayName, DisplayVersion
If removal is required as a temporary containment measure on a non-critical host, use the uninstall string retrieved from the registry rather than inventing a command:
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object { $_.DisplayName -match "DeviceLock|Acronis" } |
Select-Object DisplayName, UninstallString
For organizations using endpoint management, examples of concrete upgrade actions include running the vendor-provided package via your deployment system with silent install options validated in staging. In the absence of published workaround details, the specific action to take is: obtain and deploy build 9.0.15051.93227 or later from Acronis, then verify endpoint build state.
References
- NVD entry for CVE-2026-42061
- Acronis advisory SEC-3083: https://security-advisory.acronis.com/advisories/SEC-3083
- Acronis DeviceLock DLP 9.0 Update 5 release notes: https://dl.acronis.com/u/devicelock/rn/9.0.up5/en-US/DeviceLock_DLP_relnotes.htm
- Acronis DeviceLock DLP 9.0 Update 6 release notes: https://dl.acronis.com/u/devicelock/rn/9.0.up6/en-US/DeviceLock_DLP_relnotes.htm
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.