Vulnerability in AOMEI Backupper driver allows writing data to the physical disk without privileges

The CERT Coordination Center (CERT/CC) has published advisory VU#687587 describing the CVE-2026-12780 vulnerability in the kernel driver amwrtdrv.sys, which is included with the backup software AOMEI Backupper. The vulnerability allows an unprivileged local user to perform arbitrary writes to the physical disk. With Secure Boot disabled, this opens a path to implanting malicious code at the UEFI level — even before the operating system and all its protection mechanisms are loaded. AOMEI Backupper users are advised to update, remove the program, or disable the vulnerable driver.

Technical details of the vulnerability

According to the CERT/CC advisory, the vulnerability is classified as CWE-732 — incorrect permission assignment for a critical resource. The amwrtdrv.sys driver creates a device object that is accessible to all users of the system (world-accessible), without a security descriptor. This means that any user-mode process can open the device \\\\.\\mwrtdrv\\DISK0 and send unrestricted write requests.

CERT/CC states that AOMEI Backupper version 8.4.0 contains the vulnerable driver. It is worth noting that the GitHub Advisory Database entry lists a different range of affected versions — up to 8.3.0. This discrepancy has not been resolved: CERT/CC, as the primary source, explicitly names version 8.4.0, while the GitHub entry has the status “unreviewed” and marks the affected and fixed versions as unknown. Users of any of these versions should consider themselves potentially vulnerable.

The attack mechanism described by CERT/CC is as follows: an attacker with local access modifies disk sectors in the area between partitions (LBA 34–2047), injects a malicious UEFI payload, and changes the GPT partition table so that it points to this payload as the EFI system partition. On the next boot, the malicious code executes at the UEFI Boot Device Selection (BDS) stage — before the Windows kernel is started.

Impact boundaries and configuration dependencies

An analysis of the CERT/CC advisory shows that the risk has several clear configuration boundaries that are important to distinguish:

• Baseline vulnerability — arbitrary writes to the physical disk — can be exploited by any unprivileged local user on a system with the vulnerable driver installed. This part of the attack does not depend on the state of Secure Boot.
• Execution of UEFI code before the OS boots — as a consequence of writing to the disk — is only possible when Secure Boot is disabled. When Secure Boot is enabled, the bootloader must be signed, which prevents the injected code from executing.
• Intercepting BitLocker keys — capturing the Volume Master Key (VMK) is described by CERT/CC only for configurations with TPM-only protection (without a PIN or USB key). This attack falls into the “evil maid” class — physical access to the device followed by boot process modification.

This distinction is critical for risk assessment: the driver vulnerability itself exists independently of Secure Boot, but the most destructive consequences — bypassing HVCI, EDR-class solutions, Microsoft Defender, and Hyper-V isolation — are only achievable when Secure Boot is disabled. CERT/CC explicitly states that enabling Secure Boot provides additional defense-in-depth, but does not eliminate the driver vulnerability itself.

Exploitation status and vendor response

At the time the advisory was published, CERT/CC reported that it had not received a response from AOMEI International Network Limited. This means that a specific fixed product version is not listed either in the CERT/CC advisory or in other verified sources.

As for exploitation in real-world conditions: the available data does not confirm active use of the vulnerability by threat actors. CERT/CC describes the technical path to exploitation, and mention of public exploit disclosure appears only in the unreviewed GitHub Advisory Database entry. The vulnerability is not present in the CISA Known Exploited Vulnerabilities catalog. The status should be regarded as the existence of a public PoC, not confirmed exploitation in the wild.

Mitigation recommendations

CERT/CC suggests the following measures, listed in order of priority:

1. Update AOMEI Backupper to a version with a fixed amwrtdrv.sys driver that implements proper access control mechanisms. The exact number of the fixed version was not specified at the time the advisory was published.
2. Remove AOMEI Backupper if an immediate update is not possible.
3. Disable the amwrtdrv.sys service by changing its startup type from AUTO_START to “Disabled” as an interim measure.
4. Enable Secure Boot in UEFI settings as an additional defense-in-depth layer that blocks execution of unsigned code at boot time. This measure is not a substitute for fixing the driver.

For systems using BitLocker, it is recommended to consider switching from a TPM-only configuration to TPM+PIN or TPM+USB key, which rules out the VMK interception scenario at the pre-boot stage described by CERT/CC.

Organizations using AOMEI Backupper in corporate backup scenarios should prioritize disabling or removing the vulnerable driver until a confirmed fix from the vendor appears. The lack of response from AOMEI and the unknown fixed version number make waiting for a patch a risky strategy — especially since the vulnerability allows an attacker to gain persistence below the operating system level, where detecting compromise with standard tools is significantly more difficult.