IDrive for Windows flaw can let low-privilege users gain SYSTEM access

A newly disclosed IDrive vulnerability can let an authenticated local user escalate privileges to NT AUTHORITY\SYSTEM on affected Windows systems. The issue affects IDrive Cloud Backup Client for Windows version 7.0.0.63 and earlier, so organizations that run the Windows client should treat this as a serious local privilege escalation risk and review affected endpoints now.

The flaw is tracked as CVE-2026-1995. CERT/CC says the vulnerable id_service.exe process runs with SYSTEM privileges and reads UTF-16 LE encoded files under C:\ProgramData\IDrive. Because standard users can edit those files under weak permission settings, a low-privilege attacker can point the service to an arbitrary executable or script and have it launched with elevated rights.

In practical terms, this means an attacker who already has access to a Windows machine with a normal user account could move from limited access to full system control. That can open the door to malware deployment, security-tool tampering, credential theft, data access, and deeper movement across a corporate environment.

The good news is that this is not a remote, unauthenticated bug. The attacker needs local access first. Even so, that still makes the issue dangerous in shared environments, multi-user systems, and post-compromise attack chains where an intruder already has an initial foothold and wants to climb higher.

CERT/CC says a patch is in development, but the vendor had not provided a public statement to CERT/CC at the time of publication. IDrive’s support site still lists Windows version 7.0.0.63, which matches the affected version range described in the CERT note.

What security teams need to know

Source: CERT/CC and CVE record.

Why this vulnerability matters

Backup clients often run with elevated privileges because they need broad access to files, services, and scheduled jobs. When a privileged service reads data from locations that normal users can modify, that trust boundary breaks down fast.

That appears to be the core problem here. According to CERT/CC, IDrive’s Windows service reads file contents and uses them as arguments to start processes. If an attacker can alter those files first, the service may do the attacker’s work for them with SYSTEM-level permissions.

This kind of weakness tends to matter most in real-world attack chains. A phishing attack, weak password, shared workstation, or another low-level compromise may only give an attacker limited access at first. A local privilege escalation bug like this can then become the step that turns a small breach into a full machine takeover.

Recommended mitigations right now

• Restrict write permissions for the affected IDrive directory so standard users cannot modify the files the service consumes.
• Monitor for unusual child processes launched by id_service.exe and review endpoint telemetry for unexpected executable paths.
• Use Group Policy and endpoint detection controls to block or alert on unauthorized file changes in the relevant IDrive paths.
• Watch IDrive release channels closely and update as soon as a fixed Windows client becomes available.

FAQ