AOMEI Backup Driver Lets Local Users Rewrite Physical Disks

AOMEI Backupper 8.4.0 installs a kernel driver that lets an unprivileged local user write directly to a Windows computer’s physical disk. With Secure Boot disabled, CVE-2026-12780 lets that user plant UEFI code that runs before Windows, endpoint detection and antivirus defenses start.

The path begins after an attacker gains local access; it is not remote initial access. CERT/CC does not report active exploitation or quantify affected installations. The coordinated disclosure names Backupper 8.4.0 and a corrected driver as the remedy, but it does not identify the first fixed product version. AOMEI has not supplied CERT/CC with a public statement.

Disk Writes Cross the Boot Boundary

The vulnerable amwrtdrv.sys driver creates a world-accessible device object without a security descriptor. Any user-mode process can open \\.\mwrtdrv\DISK0 and send unrestricted writes to the physical disk, according to CERT/CC. The operating system therefore exposes a privileged storage operation through an object available to an ordinary local account.

An attacker can write an EFI payload into sectors 34–2047, the pre-partition space between the protective disk structures and the first normal partition. The attacker then changes the GUID Partition Table so the firmware treats those sectors as an EFI System Partition.

The payload runs during UEFI Boot Device Selection. That moment arrives before the Windows kernel and before Hypervisor-Protected Code Integrity, Microsoft Defender, EDR agents and Hyper-V isolation can enforce their normal controls. CERT/CC describes the result plainly: the flaw “allows an unprivileged local attacker to achieve UEFI-level arbitrary code execution by directly writing to physical disk devices.”

Figure details

An unprivileged local process opens the world-accessible \\.\mwrtdrv\DISK0 device exposed by amwrtdrv.sys. Unrestricted driver requests write a payload into physical-disk sectors 34 through 2047 and change the GPT to reference those sectors as an EFI System Partition. The firmware then loads the payload during UEFI Boot Device Selection, before the Windows kernel, HVCI, EDR, Microsoft Defender and Hyper-V isolation start. Execution requires a later boot with Secure Boot disabled; the disk write alone only stages the payload.

This mechanism distinguishes a staged payload from an executed one. A disk write can place the EFI material and alter the partition map. The code reaches the pre-boot execution stage only after the firmware follows that new partition entry during a later startup.

Secure Boot Changes the Outcome

Secure Boot blocks the unsigned pre-boot payload described in the note. It does not repair the driver’s permissions or prevent an unprivileged process from issuing physical-disk writes. CERT/CC calls Secure Boot “additional defense in depth” and states that it “does not address the underlying driver vulnerability.”

A vulnerable installation with Secure Boot enabled still exposes arbitrary disk modification. A vulnerable installation with Secure Boot disabled adds the demonstrated path to UEFI execution and persistence below Windows security products.

BitLocker configuration creates another conditional consequence. On systems using TPM-only protection, CERT/CC says a malicious pre-boot payload may capture Volume Master Key material. The source does not say every BitLocker deployment is exposed: the outcome depends on the system’s protection configuration and successful pre-boot execution.

Defenders can scope the exposure from three observable states: an installed Backupper 8.4.0 application, the amwrtdrv.sys driver service, and Secure Boot status. The published device name, \\.\mwrtdrv\DISK0, provides a specific pivot for host instrumentation that records process access to device objects or driver I/O. The primary record supplies no attack hashes, process names, event identifiers or confirmed exploitation telemetry.

Remove or Disable the Driver

CERT/CC recommends updating AOMEI Backupper to a release containing a corrected amwrtdrv.sys with appropriate access controls. Because the note does not name that release, administrators need to verify the installed driver’s permissions instead of treating an unspecified “latest” label as evidence of repair.

Where an immediate update is unavailable, CERT/CC recommends uninstalling Backupper. Its bounded alternative is to change the amwrtdrv.sys service start type from AUTO_START to disabled. Enable Secure Boot as defense in depth, especially on endpoints that currently allow unsigned EFI code, while retaining the driver fix as the required correction.

Check the resulting state after remediation. The affected 8.4.0 driver must be absent or replaced, its service must remain disabled when the workaround is in use, and an unprivileged test account must be unable to open \\.\mwrtdrv\DISK0 for physical-disk writes. Preserve the disk layout, EFI partition entries and driver telemetry before repair if an unexplained local process accessed the device or if a vulnerable system booted without Secure Boot.

The vulnerability moves trust below the controls that defenders usually ask first. Removing the exposed device path prevents an ordinary account from turning a local foothold into firmware-stage persistence; Secure Boot then supplies a second boundary if disk state is changed by some other route.